WFS encoding output support

[mapserver-bot]

Reporter: djay
Date: 2011/09/17 - 23:12
Original: http://trac.osgeo.org/mapserver/ticket/4028
When you get datasources encoded in a different encoding system than the output you set for your full mapfile. MapServer is, by now, not able to handle re-encoding of the data.

So you will find here a small patch which can solve this issue.

The way I used to solve this issue was to check for metadata "ows_encoding" at the layer level then to use the

msGetEncodedString
function from the MapServer API to encode the string correctly.

[mapserver-bot]

Author: djay
Date: 2011/12/14 - 16:50
Using the same "trick" we can also correct the WMS GetFeatureInfo to support same encoding handling...

[mapserver-bot]

Author: tbonfort
Date: 2011/12/14 - 18:30
djay,

Supporting differently encoded datasources would be a nice addition.

Two comments on your patch:

• doing a hashtable lookup for each shapeObj is inefficient, maybe the encoding should be copied/stored directly on the layerObj?
• I don't think there's a need to strdup the two temporary strings, msGetEncodedString can work directly on shape->values[i], and it's return value can be directly assigned to itemValue.

[mapserver-bot]

Author: djay
Date: 2011/12/15 - 01:54
tbonfort,
thanks for answering.

My comments inline bellow :

Replying to [comment:2 tbonfort]:

• doing a hashtable lookup for each shapeObj is inefficient, maybe the encoding should be copied/stored directly on the layerObj?

Indeed I fully agree with you on this point and would like to add an "encoding" keyword at the layer level as discussed during last code sprint in Denver. This can be achieved applying the mapserver-encoding.patch provided.

Nevertheless, using the ENCODING keyword at the layer level imply few modifications in !MapScript also. In the patch provided I only modified the Python one.

• I don't think there's a need to strdup the two temporary strings, msGetEncodedString can work directly on shape->values[i], and it's return value can be directly assigned to itemValue.

Thanks for the correction. This should be solved in the new patch.

[Schpidi]

testing