GML driver doesn't consider that srsName like "http://www.opengis.net/def/crs/EPSG/0/" should respect EPSG axis order
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?
In 35689: