Opened 14 years ago

Closed 7 years ago

Last modified 6 years ago

#2131 closed defect (fixed)

GMLJP2 Needs to Honour EPSG Preferred Geographic Axis Ordering

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone: 2.0.0
Component: GDAL_Raster Version: 1.5.0
Severity: normal Keywords: gmljp2 jp2kak jpeg2000
Cc: gaopeng


When interpreting things like:

      <Envelope srsName="urn:x-ogc:def:crs:EPSG:6.12:4326">
        <lowerCorner>20.81565355 -17.15902005</lowerCorner>
        <upperCorner>21.05228926 -16.90573361</upperCorner>


                        <RectifiedGrid dimension="2">
                                    <low>0 0</low>
                                    <high>5631 5224</high>
                                    <pos>21.0522666172 -17.1589975596</pos>
                            <offsetVector>0.000000000000 0.000044972733</offsetVector>
                            <offsetVector>-0.000045289132 0.000000000000</offsetVector>

it is presumed that we must honour the EPSG preferred axis ordering for the geographic coordinate system (lat long for EPSG:4326).

The above should have an origin near 17west, 21north.

Change History (4)

comment:1 Changed 14 years ago by warmerdam

Status: newassigned

I have initiated RFC 20 to address this issue comprehensively.

In the meantime I'm preparing a more limited patch for GDAL 1.5 and 1.4 branches in the GMLJP2 code. In that effort I found some questions with regard to other GMLJP2 products summarized in this email to Michael Gerlek (LizardTech?):


The GDAL autotest suite includes the attached GMLJP2 file georeferenced
in EPSG:4326.  It appears to be created with GeoExpress though it is
likely that I actually inserted a GeoExpress generated GML block into
a much smaller .jp2 file of my own creation.

Some key parts of the coverage are:

    <description>This file conforms to OGC document 05-047r3, the GMLJP2 Encoding Specification version 1.0.0. Created by LizardTech Geo Express.</description>
      <Envelope srsName="urn:x-ogc:def:crs:EPSG:6.12:4326">
        <lowerCorner>42.0000000000 8.0000000000</lowerCorner>
        <upperCorner>50.0000000000 16.0000000000</upperCorner>
                        <RectifiedGrid dimension="2">
                                    <low>0 0</low>
                                    <high>10507 10507</high>
                                    <pos>8.0003806986 49.9996193014</pos>
                            <offsetVector>0.000761397164 0.000000000000</offsetVector>
                            <offsetVector>0.000000000000 -0.000761397164</offsetVector>

Note that:
 1) The envelope uses EPSG:4326.
 2) The RectifiedGrid does not have any SRS definitions (so I default to
    using the SRS from the Envelope).
 3) The axis order appears to be different between the envelope and the
 4) The offsetVectors appear to use long, lat axis ordering.  If they
    were lat, long they would be more like:
        <offsetVector>0.000000000000 0.000761397164</offsetVector>
        <offsetVector>-0.000761397164 0.000000000000</offsetVector>

I'm confused!  Do you think this file represents a properly formatted
GMLJP2 file?  If so, how am I to interpret the coordinate system of
the rectified grid origin and offset vectors?  How do I know this?

I have recently modified my GMLJP2 generator to produce files that
honour EPSG axis conditions for EPSG geographic coordinate systems.
For a DTED cell I now end up producing a GML coverage that looks like:

            <gml:RectifiedGrid dimension="2">
                  <gml:low>0 0</gml:low>
                  <gml:high>1200 1200</gml:high>
                <gml:Point gml:id="P0001" srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>34 43</gml:pos>
              <gml:offsetVector srsName="urn:ogc:def:crs:EPSG::4326">0 0.000833333333333333</gml:offsetVector>
              <gml:offsetVector srsName="urn:ogc:def:crs:EPSG::4326">-0.000833333333333333 0</gml:offsetVector>

Do you consider this a properly formatted description?  I have encountered
other files in the wild handled similarly.  I have placed the GDAL generated
file at:

Please feel free to use this file as demonstration data, and redistribute in
any fashion you see fit.

comment:2 Changed 14 years ago by warmerdam

I have applied a local patch in the gmljp2metadata.cpp code that looks for a 4xxx EPSG urn and when found switches the axes on read. It also flips the axes on write for EPSG:4xxx. The GDAL_IGNORE_AXIS_ORIENTATION configuration option may also be set to YES to disable this new behavior.

The change is in trunk (r13570), 1.5 (r13571), 1.4 (r13572) and 1.4-esri (r13573). I have also updated the script where most gmljp2 testing is done to test this new stuff option in trunk (r13499).

Once RFC 20 is passed, hopefully this can be updated in trunk to use more general rules to identify when axis flipping is needed.

comment:3 Changed 7 years ago by Even Rouault

Component: OGR_SFGDAL_Raster
Milestone: 2.0
Resolution: fixed
Status: assignedclosed
Since a few releases, we used "if( oSRS.EPSGTreatsAsLatLong()
oSRS.EPSGTreatsAsNorthingEasting() )" to determine if axis swapping is needed when reading. But for generation of GMLJP2 it assumes that a GEOGCS implied axis swapping

trunk r27447 "GDALJP2Metadata::CreateGMLJP2(): use EPSGTreatsAsLatLong() and EPSGTreatsAsNorthingEasting() to determine if axis swapping is needed (#2131)"

comment:4 Changed 6 years ago by Even Rouault


Milestone renamed

Note: See TracTickets for help on using tickets.