You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
The text was updated successfully, but these errors were encountered: