#4329 closed defect (fixed)
[PATCH] GML3 N-E axis order not handled with projected systems
| Reported by: | Jukka Rahkonen | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.10.0 |
| Component: | OGR_SRS | Version: | unspecified |
| Severity: | normal | Keywords: | srs axis ordering |
| Cc: |
Description
EPSG:3047 is defined to have axis order Northing-Easting. However, ogr2ogr from gdal 1.8.1 handles coordinates as Easting-Northing even if the coordinate system in given as urn-style.
<gml:location> <gml:Point gml:id="p26127610" srsName="urn:ogc:def:crs:EPSG::3047"> <gml:pos>6763247.267 400218.659</gml:pos> </gml:Point> </gml:location>
It would be useful to have a new parameter in ogr2ogr so that user could define the correct axis order. There are several reasons for this. Lots of GML3 files have srsName in plain EPSG:3047 format. Flipping axis with such data automatically could break things with older data and applications. Data errors with wrong axis order are also pretty common but user could solve them easily with the flip axis parameter. It might also be necessary to define also the axis order when overriding the source srs with the -s_srs parameter. Parameter name could be something like -axis_order and it could take values "en" or "ne". Perhaps also "latlon" and "lonlat". Default would be "en".
Attachments (3)
Change History (9)
comment:1 by , 12 years ago
by , 12 years ago
| Attachment: | urnepsg4329.xml added |
|---|
comment:2 by , 12 years ago
Sorry about unclear formulation and incomplete report. I should have mentioned that I tried to convert a GML file into PostGIS and shapefiles with ogr2ogr and the result was always the same with all these srsNames I tried to use inside GML: EPSG:3067, EPSG:3047, or urn:ogc:def:crs:EPSG::3047. The first coordinate in GML was always the Easting coordinate in the target dataset. I was hoping that at least the urn style srsName would have yielded a different result.
by , 12 years ago
| Attachment: | ticket4329.patch added |
|---|
Patch that adds EPSGTreatsAsNorthingEasting() for projected CS, and use it by the GML driver to swap from (northing,easting) to (easting,northing) ordering for GML files that use urn:ogc:def:crs:EPSG::XXXX with XXXX being in (northing, easting) order
comment:3 by , 12 years ago
| Component: | default → OGR_SRS |
|---|---|
| Keywords: | srs axis ordering added |
| Summary: | GML3 N-E axis order not handled with projected systems → [PATCH] GML3 N-E axis order not handled with projected systems |
I've attached a patch that implements my above idea. Need to think about it a bit more before committing it. Perhaps this will require an update of RFC20
comment:4 by , 11 years ago
I've re-tested this patch against trunk r25712 and it fixes problems accessing WFS feature types which have a projection coordinate system that is not defined as east/north.
e.g this query now return data in the correct order for EPSG:2193 from WFS:
ogrinfo -al WFS:"http://geoportal.doc.govt.nz/arcgis/services/GeoportalServices/DOC_Tracks/MapServer/WFSServer?MAXFEATURES=1"
ERROR 1: Server is read-only WFS; no WFS-T feature advertized
Had to open data source read-only.
INFO: Open of `WFS:http://geoportal.doc.govt.nz/arcgis/services/GeoportalServices/DOC_Tracks/MapServer/WFSServer?MAXFEATURES=1'
using driver `WFS' successful.
Layer name: GeoportalServices_DOC_Tracks:DOC_Tracks
Geometry: Multi Line String
Feature Count: 1
Extent: (1100115.393700, 4166343.629200) - (2463511.843700, 6190511.010300)
Layer SRS WKT:
PROJCS["NZGD2000 / New Zealand Transverse Mercator 2000",
GEOGCS["NZGD2000",
DATUM["New_Zealand_Geodetic_Datum_2000",
SPHEROID["GRS 1980",6378137,298.257222101,
AUTHORITY["EPSG","7019"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6167"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4167"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",173],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",1600000],
PARAMETER["false_northing",10000000],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Northing",NORTH],
AXIS["Easting",EAST],
AUTHORITY["EPSG","2193"]]
Geometry Column = Shape
gml_id: String (0.0)
OBJECTID: Integer (0.0)
CAPTURE_ACCURACY: Integer (0.0)
DESCRIPTION: String (40.0)
OBJECT_TYPE_DESCRIPTION: String (40.0)
URL: String (254.0)
Shape.len: Real (0.0)
OGRFeature(GeoportalServices_DOC_Tracks:DOC_Tracks):261253
gml_id (String) = F485__261253
OBJECTID (Integer) = 261253
CAPTURE_ACCURACY (Integer) = 2
DESCRIPTION (String) = KAURI TREE ROUTE
OBJECT_TYPE_DESCRIPTION (String) = Tramping Track
URL (String) = 100045881
Shape.len (Real) = 148.586172787542
MULTILINESTRING ((1814015.415599999949 5991214.493599999696,1814015.5085 5991202.93499999959,1814015.6724 5991187.680499999784,1814017.1224 5991171.167899999768,1814023.6466 5991155.9797,1814033.960699999938 5991143.3748,1814046.7908 5991133.3392,1814059.6078 5991124.574599999934,1814073.6697 5991118.3662,1814091.1118 5991100.1902))
Can this patch please be applied?
by , 11 years ago
| Attachment: | ticket4329_new.patch added |
|---|
comment:5 by , 11 years ago
| Milestone: | → 1.10.0 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Patch commited in trunk in r25727 with a few additions in GML & WFS drivers to strip AXIS nodes from projected SRS when coordinate swapping is done.
I don't agree with your diagnostic (or I'm confused with the way you've formulated it). I've attached a sample GML file with urn:ogc:def:crs:EPSG::3047 and coordinates in northing,easting order as mandated.
Here's the output of ogrinfo :
Layer name: SomeClass Geometry: Line String Feature Count: 1 Extent: (7097308.594000, 394238.295000) - (7099091.225000, 395828.167000) Layer SRS WKT: PROJCS["ETRS89 / TM35", GEOGCS["ETRS89", DATUM["European_Terrestrial_Reference_System_1989", SPHEROID["GRS 1980",6378137,298.257222101, AUTHORITY["EPSG","7019"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6258"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AXIS["Latitude",NORTH], AXIS["Longitude",EAST], AUTHORITY["EPSG","4258"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",27], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",500000], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AXIS["Northing",NORTH], AXIS["Easting",EAST], AUTHORITY["EPSG","3047"]] gml_id: String (0.0) OGRFeature(SomeClass):0 gml_id (String) = SomeClass.1 LINESTRING (7098414.931 394544.207,7099033.772 394238.295,7099091.225 395707.303,7098459.944 395828.167,7098689.957 395283.16,7098330.69 394852.012,7097738.791 395036.493,7097308.594 394577.95,7098119.34 394317.414,7098414.931 394544.207)This output is consistant. The SRS reported has explicitely the AXIS mentionned in Northing/Easting orders and the reported coordinates are consistant with that ordering.
Now, what could/should be improved with modest effort (adding a OGRSpatialReference::TreatsAsNorthingEasting() similarly to TreatsAsLatLong()) is to detect that this is a projected SRS with northing/easting ordering, and automatically do the coordinate swapping (as already done with geographic SRS with latitude/longitude ordering). In that case the reported SRS would have the AXIS nodes stripped (to imply that the usual GIS convention apply...). That way reprojection would work as expected.
The simulated output would be :
Layer name: SomeClass Geometry: Line String Feature Count: 1 Extent: (394238.295000, 7097308.594000) - (395828.167000, 7099091.225000) Layer SRS WKT: PROJCS["ETRS89 / TM35", GEOGCS["ETRS89", DATUM["European_Terrestrial_Reference_System_1989", SPHEROID["GRS 1980",6378137,298.257222101, AUTHORITY["EPSG","7019"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6258"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AXIS["Latitude",NORTH], AXIS["Longitude",EAST], AUTHORITY["EPSG","4258"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",27], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",500000], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AUTHORITY["EPSG","3047"]] gml_id: String (0.0) OGRFeature(SomeClass):0 gml_id (String) = SomeClass.1 LINESTRING (394544.207 7098414.931,394238.295 7099033.772,395707.303 7099091.225,395828.167 7098459.944,395283.16 7098689.957,394852.012 7098330.69,395036.493 7097738.791,394577.95 7097308.594,394317.414 7098119.34,394544.207 7098414.931)