GML driver doesn't consider that srsName like "http://www.opengis.net/def/crs/EPSG/0/" should respect EPSG axis order
|Reported by:||rouault||Owned by:||rouault|
Reported on QGIS mailing list:
We are experiencing an unwanted flipping of coordinate order interpretation when adding GML 3.2 files as new vector layers in QGIS 2.2 Valmiera. The GML data is has been encoded as a wfs:featureCollection with EU INSPIRE ProtectedSite 4.0 features as collection members (XML Schema: http://inspire.ec.europa.eu/schemas/ps/4.0/ProtectedSites.xsd). When using the URI-type srsName "http://www.opengis.net/def/crs/EPSG/0/3035" the coordinates seem to be interpreted (by GDAL?) in order (easting, northing), while the official axis order (according to the EPSG-registry) is (northing, easting). If we change the srsName to the URN-type format "urn:ogc:def:crs:EPSG::3035" in the GML file, the import seems to use the correct coordinate order. To comply with the INSPIRE requirements, we have to use the URI format srsNames, but this is likely to cause a lot of confusion for the QGIS & GDAL users of the data if the coordinates are interpreted in the wrong order. I'm fully aware of the massively confusing lat/lon (x/y) coordinate order interpretation misalignment between the geographers and the (GIS) software implementors, but was not aware that this issues also shows it's ugly head for other CRSes than CRS 84/EPSG:4326. Question 1: Is this an intentional feature or a bug? Question 2: Is it possible to force GDAL from the QGIS UI to interpret the coordinate order of these GML files in the official order?
Change History (4)
Note: See TracTickets for help on using tickets.