Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#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)

urnepsg4329.xml (1.2 KB) - added by Even Rouault 8 years ago.
ticket4329.patch (10.9 KB) - added by Even Rouault 8 years ago.
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
ticket4329_new.patch (11.5 KB) - added by jpalmer 7 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 8 years ago by Even Rouault

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)

Changed 8 years ago by Even Rouault

Attachment: urnepsg4329.xml added

comment:2 Changed 8 years ago by Jukka Rahkonen

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.

Changed 8 years ago by Even Rouault

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 Changed 8 years ago by Even Rouault

Component: defaultOGR_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 Changed 7 years ago by jpalmer

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?

Changed 7 years ago by jpalmer

Attachment: ticket4329_new.patch added

comment:5 Changed 7 years ago by Even Rouault

Milestone: 1.10.0
Resolution: fixed
Status: newclosed

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.

comment:6 Changed 7 years ago by jpalmer

Thanks Even. WFS 1.1 support is looking very healthy now!

Note: See TracTickets for help on using tickets.