#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 |
Description
When interpreting things like:
<boundedBy> <Envelope srsName="urn:x-ogc:def:crs:EPSG:6.12:4326"> <lowerCorner>20.81565355 -17.15902005</lowerCorner> <upperCorner>21.05228926 -16.90573361</upperCorner> </Envelope> </boundedBy>
and
<rectifiedGridDomain> <RectifiedGrid dimension="2"> <limits> <GridEnvelope> <low>0 0</low> <high>5631 5224</high> </GridEnvelope> </limits> <axisName>x</axisName> <axisName>y</axisName> <origin> <Point> <pos>21.0522666172 -17.1589975596</pos> </Point> </origin> <offsetVector>0.000000000000 0.000044972733</offsetVector> <offsetVector>-0.000045289132 0.000000000000</offsetVector> </RectifiedGrid> </rectifiedGridDomain>
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 by , 16 years ago
Status: | new → assigned |
---|
comment:2 by , 16 years ago
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 jp2kak.py 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 by , 10 years ago
Component: | OGR_SF → GDAL_Raster |
---|---|
Milestone: | → 2.0 |
Resolution: | → fixed |
Status: | assigned → closed |
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)"
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):