Opened 8 years ago

Closed 18 months ago

#4657 closed defect (wontfix)

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

Reported by: bcarpenter Owned by: bcarpenter
Priority: normal Milestone: closed_because_of_github_migration
Component: default Version: 1.9.0
Severity: normal Keywords: Jpeg2000 GML
Cc: warmerdam, msavinaud

Description

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.

Attachments (3)

gmljp2_dtedsm_epsg_4326_axes_alt_offsetVector.jp2 (7.3 KB) - added by bcarpenter 8 years ago.
Jpeg2000 file that demonstrates the defective behavior for #4657
gdal_issue4657_patch.txt (5.4 KB) - added by bcarpenter 8 years ago.
SVN patch file for my code changes - you also need the test .jp2 image already attached here.
gdal_issue_4657_earlier_discussion.pdf (719.6 KB) - added by bcarpenter 8 years ago.
A PDF of an earlier email Bryan->Frank describing the behavior.

Download all attachments as: .zip

Change History (9)

Changed 8 years ago by bcarpenter

Jpeg2000 file that demonstrates the defective behavior for #4657

Changed 8 years ago by bcarpenter

Attachment: gdal_issue4657_patch.txt added

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

Changed 8 years ago by bcarpenter

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

comment:1 Changed 8 years ago by 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.

comment:2 Changed 8 years ago by aboudreault

Cc: warmerdam added

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?

comment:3 Changed 8 years ago by 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...

comment:4 Changed 8 years ago by msavinaud

Cc: msavinaud added

comment:5 Changed 5 years ago by 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>

comment:6 Changed 18 months ago by Even Rouault

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.