[mapserver-dev] EPSG codes in Mapserver and axis order, again
Edward Nash
edward.nash at gmx.de
Thu Aug 8 23:03:02 PDT 2013
Hi Mathieu,
you're right that #4720 was really about the WFS client axis order, and
sending the CRS to the server.
For 6.4 then I think it's now too late to deal with WFS server axis
order, but for 6.6 I think the axis order issues in general really
should be sorted out.
Given that the response to the e-mail you dug out was precisely zero, I
haven't been highly motivated to work on this. One or two of the points
have been addressed in the interim, but I think the main problem still
stands. Re-reading the attached document then then some of the ideas
look sound, some a little shaky.
If you or anyone else would like to contribute on this, then be my guest
- it will probably mean something happening quicker. Otherwise I will
try and work on it as a side project the next few weeks/months and when
there is something which looks feasible propose it as "real" RFC.
Regards,
Edward
Am 08.08.2013 11:50, schrieb Mathieu Coudert:
> Hi Edward and all,
>
> As #4228 and #4720 were closed those days, I would like to know the
> status of these devs and the associated RFC?
> It seems that all works related to that topic are focused on WFS client,
> isn't it? Do you plan to work on WFS server and axis order also?
>
> Thanks,
>
> Cheers,
> Mathieu
>
> https://github.com/mapserver/mapserver/issues/4228
> https://github.com/mapserver/mapserver/pull/4720
>
>
> On Thu, Jul 12, 2012 at 10:49 AM, Nash, Edward <E.Nash at dvz-mv.de
> <mailto:E.Nash at dvz-mv.de>> wrote:
>
> 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 <mailto:E.Nash at dvz-mv.de>
> Telefon +49 385 4800 527 <tel:%2B49%20385%204800%20527>
> Mobil +49 170 454 7434 <tel:%2B49%20170%20454%207434>
> Internet: www.dvz-mv.de <http://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
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org <mailto:mapserver-dev at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
More information about the mapserver-dev
mailing list