Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WFS encoding output support #4028

Closed
mapserver-bot opened this issue Apr 4, 2012 · 8 comments
Closed

WFS encoding output support #4028

mapserver-bot opened this issue Apr 4, 2012 · 8 comments

Comments

@mapserver-bot
Copy link

Reporter: djay
Date: 2011/09/17 - 23:12
Trac URL: 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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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.

@mapserver-bot
Copy link
Author

attachment http://trac.osgeo.org/mapserver/attachment/ticket/4028/mapserver-gml-encoding-support :

   Small patch about encoding output for WFS server

@mapserver-bot
Copy link
Author

attachment http://trac.osgeo.org/mapserver/attachment/ticket/4028/mapserver-getfeatureinfo-encoding :

   mapserver-getfeatureinfo-encoding

@mapserver-bot
Copy link
Author

attachment http://trac.osgeo.org/mapserver/attachment/ticket/4028/mapserver-encoding.patch :

   mapserver-encoding.patch

@tbonfort
Copy link
Member

see also #3297 #3307 #3148

@mapserver-bot
Copy link
Author

This is an automated comment

This issue has been closed due to lack of activity. This doesn't mean the issue is invalid, it simply got no attention within the last year. Please reopen with missing/relevant information if still valid.

Typically, issues fall in this state for one of the following reasons:

  • Hard, impossible or not enough information to reproduce
  • Missing test case
  • Lack of a champion with interest and/or funding to address the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants