[mapserver-dev] EPSG codes in Mapserver and axis order, again

Nash, Edward E.Nash at dvz-mv.de
Thu Jul 12 01:49:36 PDT 2012


Hi devs,

This was inspired by hacking in the WFS server, but also has impact all through Mapserver (read on...). I know that this topic has come up once or twice before (e.g. https://github.com/mapserver/mapserver/issues/4228 and https://github.com/mapserver/mapserver/pull/4381) but going through there are still multiple, inconsistent, points where CRS-IDs are parsed in the WFS and Filter code and also inconsistencies between Mapserver and GeoServer (which is the WFS reference implementation and so imho is the behavior Mapserver should try to match).

To summarise the WFS specification:
- WFS 1.1.0 *must* support three different types of EPSG-specification (WFS1.1 spec p36), and axis-order should apparently always be respected (i.e. sometimes reversed):
  + EPSG:<EPSG code>
  + http://www.opengis.net/gml/srs/epsg.xml#<EPSG code>
  + urn:EPSG:geographicCRS:<epsg code>

- WFS 1.0 doesn't specify anything, but all examples in the specification use the URI form. Standard practice is to accept at least the EPSG: form, and axis order should apparently always be x,y or lon,lat

GeoServer doesn't quite implement this as it assumes that EPSG: and URI-form CRS are always lon,lat (for backward-compatibility with WFS1.0) and only the URN-form CRS ever has the EPSG-defined axis order.

Some problems in MapServer:

- At least in mapwfs msWFSGetFeatureApplySRS (and in mapfile msLoadProjectionString) then the URI form is not supported, although it is in the filter stuff since that doesn't really look at the prefix. This is a straightforward fix.

- There is some duplication of code: mapogcfilter.c and mapogcfiltercommon.c both parse EPSG codes in filters (https://github.com/mapserver/mapserver/pull/4381 fixes that duplication) and mapwfs.c (msWFSGetFeatureApplySRS) separately parses the EPSG code in the Query srsName. All of these functions have a look at the string, sometimes mash it a bit and then ultimately call msLoadProjectionString or (only from msWFSGetFeatureApplySRS and if version is 1.1.0) msLoadProjectionStringEPSG. To be honest, all of these functions look pretty hacky as they are having to work with the logic in msLoadProjectionString regarding what EPSG forms should have the strict axis order, which is different to the current Mapserver WFS logic.

- Possibly the biggest problem is that the WFS version is not known at the point where the EPSG string in the filter is parsed in FLTParseEpsgString (mapogcfilter.c) and FTLParseEpsgString (mapogcfiltercommon.c), and these functions always assumes x,y/lon,lat axis-order: the result of this is that geometries specified in the filter may well be interpreted with the wrong axis order. Since these functions are called from deep in the filter processing code then slipping an extra parameter through purely to indicate which WFS/FE version is being read and therefore how the EPSG code should be interpreted would not be straightforward as it would have to go through all sorts of functions.

Trying to think of a solution for this problem then the best thing I can think of is a somewhat radical change in the way Mapserver handles parsing EPSG codes and axis orders by anchoring the strategy into the MAP object, as that (or other objects referencing it) are almost universally available: attached is a proposal as an RFC describing my thoughts. Most of the changes described are I think fairly straightforward, but there could be some catches I've not spotted. Please feel free to improve the document, point out why it's all unnecessary, suggest alternative ideas, etc.: this is a there to be shot at! If the RFC finds approval then I would be prepared to hack an initial implementation together, but may need to ask for help on the lexer/parser and SWIG bindings as I'm totally unfamiliar with those.

Best regards,

Edward

--

Edward Nash
E-Lösungen und Geoinformation
E-Mail  E.Nash at dvz-mv.de
Telefon +49 385 4800 527
Mobil +49 170 454 7434
Internet: www.dvz-mv.de
_____________________________________
DVZ Datenverarbeitungszentrum
Mecklenburg-Vorpommern GmbH
Lübecker Str. 283 - 19059 Schwerin
Sitz der Gesellschaft: Schwerin
Eintrag im Handelsregister: HRB 187/ Amtsgericht Schwerin
Geschäftsführer:  Hubert Ludwig -
Aufsichtsratsvorsitzender: Dr. Jost Mediger

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ms-rfc-85-proposal.txt
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20120712/57bf3b16/attachment.txt>


More information about the mapserver-dev mailing list