[TinyOWS-dev] About encoding per layer and other things

[Carlos Ruiz]

Hey Olivier,

I was checking about the per layer encoding.

First, when I've added the encoding attribute in the config.xml file, it was to 
be able to pull data from 

the server with the GetFeature request.

This because I noticed that Quantum GIS wasn't loading my data complete. Doing 
some tests with 

the GetFeature request with a browser, there was a parsing error with no UTF-8 
characters.

That problem was now fixed with the changes I made, you can check at 

    http://sitel.jalisco.gob.mx/cgi-bin/wfst2?SERVICE=WFS&VERSION=1.0.0&REQUEST=
            GetFeature&TYPENAME=sitel:acatic_manzanas

to see that the TinyOWS generated XML response handles the encoding ISO-8859-1 
that I've 

defined into my config.xml file.

Also, if you type ./wfst2 --check it dumps the encoding too:

TinyOWS version:   0.9.0
Config File Path:  /usr/local/tinyows/config.xml
PostGIS dsn:       host=127.0.0.1 ...
Schema dir:        /usr/local/tinyows/schema/
Log file:          /usr/local/tinyows/tinyows.log
Encoding:          ISO-8859-1
Available layers:
 - public.acatic_manzanas  -> 32613 RW
 - public.acatic_cultivos  -> 32613 RW
 - public.acatic_curvas_nivel_maestras  -> 32613 RW

Now, handling encoding per layer needs to specify per table PostgreSQL 
encodings, is not possible
because you can only set the encoding to the whole database.

Also, there's no necessarily match between the XML encoding and the PostgreSQL 
encoding.

Lets say: 

I need to handle the XML responses with an encoding that supports french and 
spanish special 

characters, so I have to choose ISO-8859-1, but, I have my database configured 
as LATIN-1
or WIN1252. It doesn't match.

So I suggest to add into the pg tag an encoding attribute, like this:

<pg host="127.0.0.1" user="postgres" password="postgres" 
    dbname="tinyows_demo" port="5432" encoding="LATIN-1"/>

With this change, I just can call the PQsetClientEncoding function after the 
connection is 

open.

What do you think ?

There's another thing I'm seeing with the transaction code. It will be wise to 
use SELECT ... WITH 

UPDATE specification and also adding LOCKs while update or delete rows, to avoid 
concurrency 

problems.

However, this change might affect a little bit the performance (because the 
locks) but enhancing the 

data consistency.

I'm currently doing some tests with that.

IC Carlos Ruiz


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/tinyows-dev/attachments/20110201/e72538e5/attachment.html