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

[Olivier Courtin]

On Feb 1, 2011, at 11:27 PM, Carlos Ruiz wrote:

Hi Carlos,

First sorry for the delay...

> 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.

Yeap that's a good point, you're right !

> 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"/>

It could be,
But the global location in OWS also seems fine to me.

> With this change, I just can call the PQsetClientEncoding function  
> after the connection is
> open.
>
> What do you think ?

+1

I've took your last patch,
and made few modification before commit in trunk.

Thanks a lot ! :)

I let you check that everything is fine on your own,

Few little things from previous patch:
- Buffer struct is not directly a char * , but you could use buffer- 
 >buf if needed
- I didn't keep author comment inside the code (svn log and NEWS files  
are dedicaded for that)


> 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.

WFS-T specification already have a way to handle explicitly locks
But i didn't implemented them in TinyOWS for now.

If you have to explore this way, you should also have a look in  
PostGIS Long Transaction features.
A patch for WFS-T lock implementation is welcome (since it's strictly  
conform to OGC WFS-T spec)

But there's some problem IMHO in this OGC lock architecture,
as the client have to release himself each lock he already tooks.
(And sometime client will just forget too, or could exploit this  
feature as
a security hole, kind of quick DoS)

So GeoServer for instance also provide via administration backoffice,
a way for administrator to list each lock and a way to release them if  
needed.

And on the final point, i'm not sure that there's available WFS-T  
client apps
able to deal with WFS lock handle...


--
Olivier