Jpeg2000 Embedded GML Interpretation Bad when Lat/Long (Y,X) Coordinate Order

[bcarpenter]

The way to reproduce the defective behavior is to run gdalinfo on a Jpeg2000 (.JP2) file that has embedded GML with the <gml:Point> and <gml:offsetVector> tags having "srsName" attributes that give an EPSG code from 4000 through 4999. Then, the two <gml:offsetVector> tags should contain nonzero values in the upper left position (generally negative there) and the lower right position. This example demonstrates:

<gml:RectifiedGrid dimension="2">
  <gml:origin>
    <gml:Point gml:id="P0001" srsName="urn:ogc:def:crs:EPSG::4326">
      <gml:pos>33.9962809917355 43.0037190082645</gml:pos>
    </gml:Point>
  </gml:origin>
  <gml:offsetVector srsName="urn:ogc:def:crs:EPSG::4326">-0.00827134986225895 0</gml:offsetVector>
  <gml:offsetVector srsName="urn:ogc:def:crs:EPSG::4326">0 0.00827134986225895</gml:offsetVector>
</gml:RectifiedGrid>

The above example comes from a modified-GML version of this file: http://trac.osgeo.org/gdal/browser/trunk/autotest/gdrivers/data/gmljp2_dtedsm_epsg_4326_axes.jp2 that already existed in the GDAL test environment. The modification consisted of swapping the order of the two <gml:offsetVector> rows.

When gdalinfo is run on a .JP2 file containing the above GML, the following section is clearly "out of whack" given that the "Upper Left" and "Lower Left" coordinates don't agree on the longitude, etc:

Corner Coordinates:
Upper Left  (  42.9995833,  34.0004167) ( 42d59'58.50"E, 34d 0' 1.50"N)
Lower Left  (  44.0004167,  34.0004167) ( 44d 0' 1.50"E, 34d 0' 1.50"N)
Upper Right (  42.9995833,  32.9995833) ( 42d59'58.50"E, 32d59'58.50"N)
Lower Right (  44.0004167,  32.9995833) ( 44d 0' 1.50"E, 32d59'58.50"N)

Searching through the "GML in JPEG 2000" Specification available here: ​http://portal.opengeospatial.org/files/?artifact_id=13252 and looking for the <offsetVector> tags, in every case where the <offsetVector> tags include an "srsName" attribute with an EPSG code, those tags' contained nonzero values are in the upper left and lower right positions. However the current GDAL code does not successfully handle GML where this convention is followed and the coordinate order is "Lat,Long" or "Y,X".

I am attaching the modified-GML .JP2 file to this ticket, and it should be suitable for use in testing the fix for this ticket, because it is almost identical to a file that is already used for testing.

Because it doesn't appear that there's a way to fix this defective behavior without possibly negatively impacting existing users, I plan to make the fix dependent on an added GDAL configuration parameter similar to the existing "GDAL_IGNORE_AXIS_ORIENTATION" one. This new parameter would be called "GDAL_JP2K_ALT_OFFSETVECTOR_ORDER". It could be argued that the option should be used to enable the existing behavior, and that the new behavior should become "the norm", but I don't know how that discussion would go so I'm not assuming that's what will happen.

[bcarpenter]

Jpeg2000 file that demonstrates the defective behavior for #4657

[bcarpenter]

SVN patch file for my code changes - you also need the test .jp2 image already attached here.

[bcarpenter]

A PDF of an earlier email Bryan->Frank describing the behavior.

[bcarpenter]

I don't see that Trac has a way to "officially" relate another ticket, but I'll mention that this issue relates to #2131.

[aboudreault]

The patch looks good. I agree with the current behavior: GDAL_JP2K_ALT_OFFSETVECTOR_ORDER=FALSE by default. Otherwise it will affect a lot of users.

FrankW, Any objection to commit this?

[aboudreault]

Committed in trunk in r24404 (autotest: r24405) and backported in branch 1.9 in r24406 (autotest: r24407). Keeping this ticket open to review if the default behavior should be replaced in the future...

[Jukka Rahkonen]

I hate RectifiedGrid but I think that the offset vectors in the description of this ticket are wrong. Compare with GML in JPEG 2000 (GMLJP2) Encoding Standard Part 1: Core

​http://docs.opengeospatial.org/is/08-085r4/08-085r4.html

<gml:RectifiedGrid gml:id="rg0001_C0002" dimension="2"
            srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
        <gml:limits>
         <gml:GridEnvelope>
           <gml:low>1 1</gml:low>
           <gml:high>3 10</gml:high>
         </gml:GridEnvelope>
        </gml:limits>
        <gml:axisLabels>Lat Long</gml:axisLabels>
        <gml:origin>
         <gml:Point gml:id="P0001"
srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
           <gml:pos>9.9 9.9</gml:pos>
         </gml:Point>
        </gml:origin>
        <gml:offsetVector
srsName="http://www.opengis.net/def/crs/EPSG/0/4326">0 3.71e-005
        </gml:offsetVector>
        <gml:offsetVector
srsName="http://www.opengis.net/def/crs/EPSG/0/4326">-3.71e-005 0
        </gml:offsetVector>
      </gml:RectifiedGrid>

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.