Dear all, I am facing a serious problem with Mapserver (both 6.2 and 6.4.1) and data retrieval via WFS 1.1.0. We have a client running which is taking the data as GML and importing it into GRASS. The switched order of axis makes it impossible to overlay and thus process data.
The following request gets back data in yx axis order: http://mapservices-ludwigsburg.tudor.lu/cgi-bin/mapserv?map=/srv/mapserv/ludwigsburg/map_file/LB_MUSIC_OWS.map&; <http://mapservices-ludwigsburg.tudor.lu/cgi-bin/mapserv?map=/srv/mapserv/ludwigsburg/map_file/LB_MUSIC_OWS.map&;> SERVICE=WFS& VERSION=1.1.0& REQUEST=GetFeature& TYPENAME=LB_city_boundary& BBOX=48,9,49,10,urn:x-ogc:def:crs:EPSG::4326& SRSNAME=EPSG:31467 I wonder if this is a bug or feature due to the WFS 1.1.0 axis order specification? If I send the same request to a instance of Geoserver, what I get back is xy axis order: http://geoserver.tudor.lu/geoserver/ludwigsburg/ows?SERVICE=wfs&; <http://geoserver.tudor.lu/geoserver/ludwigsburg/ows?SERVICE=wfs&;> VERSION=1.1.0& REQUEST=GetFeature& TYPENAME=ludwigsburg:lb_city_boundary& BBOX=48,9,49,10,urn:x-ogc:def:crs:EPSG::4326& SRSNAME=EPSG:31467 I also found the master thesis of Weichand [1] where in Section 4.3.5 he is describing this issue as well. But Geoserver has a mechanism to treat EPSG:31467 as xy. The correct order of the CRS (by definition) is yx, but this is not used like that in Germany. Can you give any ideas about the behaviour of Mapserver and how to get around this axis order issue? Thanks, Christian Braun Luxembourg Institute of Science and Technology (LIST) Environmental Research and Innovation (ERIN) Department 41, rue du Brill L-4422 Belvaux Tel: +352 42 59 91 - 6608 Fax : +352 275 885 E-mail : [email protected] <mailto:[email protected]> Web: www.list.lu <http://www.list.lu/>
_______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
