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)

mapserver-gml-encoding-support (2.6 KB ) - added by djay 13 years ago.
Small patch about encoding output for WFS server
mapserver-getfeatureinfo-encoding (946 bytes ) - added by djay 12 years ago.
mapserver-getfeatureinfo-encoding
mapserver-encoding.patch (9.0 KB ) - added by djay 12 years ago.
mapserver-encoding.patch

Download all attachments as: .zip

Change History (6)

by djay, 13 years ago

Small patch about encoding output for WFS server

by djay, 12 years ago

mapserver-getfeatureinfo-encoding

comment:1 by djay, 12 years ago

Cc: gerald.fenoy@… added

Using the same "trick" we can also correct the WMS GetFeatureInfo to support same encoding handling...

comment:2 by tbonfort, 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.

in reply to:  2 comment:3 by djay, 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.

by djay, 12 years ago

Attachment: mapserver-encoding.patch added

mapserver-encoding.patch

Note: See TracTickets for help on using tickets.