Opened 13 years ago
Last modified 12 years ago
#4028 new defect
WFS encoding output support
Reported by: | djay | Owned by: | mapserverbugs |
---|---|---|---|
Priority: | normal | Milestone: | 6.0.1 release |
Component: | WFS Server | Version: | 6.0 |
Severity: | normal | Keywords: | wfs, encoding, server |
Cc: | gerald.fenoy@… |
Description
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.
Attachments (3)
Change History (6)
by , 13 years ago
Attachment: | mapserver-gml-encoding-support added |
---|
by , 12 years ago
Attachment: | mapserver-getfeatureinfo-encoding added |
---|
mapserver-getfeatureinfo-encoding
comment:1 by , 12 years ago
Cc: | added |
---|
Using the same "trick" we can also correct the WMS GetFeatureInfo to support same encoding handling...
follow-up: 3 comment:2 by , 12 years ago
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.
comment:3 by , 12 years ago
tbonfort, thanks for answering.
My comments inline bellow :
Replying to 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.
Small patch about encoding output for WFS server