id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc 4657,"Jpeg2000 Embedded GML Interpretation Bad when Lat/Long (Y,X) Coordinate Order",bcarpenter,bcarpenter,"The way to reproduce the defective behavior is to run gdalinfo on a Jpeg2000 (.JP2) file that has embedded GML with the and tags having ""srsName"" attributes that give an EPSG code from 4000 through 4999. Then, the two tags should contain nonzero values in the upper left position (generally negative there) and the lower right position. This example demonstrates: {{{ 33.9962809917355 43.0037190082645 -0.00827134986225895 0 0 0.00827134986225895 }}} 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 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 tags, in every case where the 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.",defect,closed,normal,closed_because_of_github_migration,default,1.9.0,normal,wontfix,Jpeg2000 GML,warmerdam msavinaud