Opened 17 years ago

Closed 17 years ago

#1501 closed defect (invalid)

JP2ECW, creation options PROJ and DATUM ineffective

Reported by: quickstuff@… Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: 1.4.0
Severity: normal Keywords:
Cc:

Description (last modified by warmerdam)

When trying to assign a specific ERMapper projection/datum string to a JP2ECW file, the PROJ= and DATUM= creation options are ineffective. The resulting jp2 file appears to have no projection info embedded.

E.g. (src.tif being any baseline tiff + tfw file):
"gdal_translate -of JP2ECW -co PROJ=GEODETIC -co DATUM=WGS84 src.tif dest.jp2"

"gdalinfo dest.jp2" does not report any projection. Close examination of the binary/hex contents of the file suggests that none gets written.

Of course I could rely on '-a_srs' to let GDAL internally assign the projection... but for backwards-compatibility with some applications, the ErMapper way of assigning a precise projection string is required. By the way, the same creation options do work like a charm for ECW. I use the last FWTools 1.2.3 under WinXP.

~Quentin S.

Change History (5)

comment:1 by quickstuff@…, 17 years ago

By the way, I realized that the mechanism devoted to correspondance between EPSG codes and ERMapper strings is sometimes faulty (GetGDTProjDat).

For instance 'EPSG:27582' gets translated to 'LM1FRE2D/NTFPARIS' which is obviously wrong (should be either LM1FRA2D/NTFPARIS or, better, LM2FRANC/NTFPARIS). EPSG:27592 suffers the same issue (inverted).

It results in major inconsistencies between projections stored as GMLJP2, ER string, and GeoJP2 - different libraries/applications would return different projections, sometimes wrong.


comment:2 by warmerdam, 17 years ago

Whoops - closed the wrong one.

comment:3 by quickstuff@…, 17 years ago

Please discard my previous comment about interverted projection: it appears the issue is not GDAL-related but actually exists with all current ER's software (e.g. ERMapper Jpeg2000 Compressor).

Anyway a fix for the first issue (discarded creation options) would allow overriding this buggy behavior.

comment:4 by warmerdam, 17 years ago

Description: modified (diff)
Priority: highestnormal

Quentin,

I appologise for the delay in addressing this. There is an undocumented option called GEODATA_USAGE which by default I set to NONE to suppress all the ECW SDK code to write coordinate systems. I do this because I prefer my own coordinate system writer for jpeg2000.

But if you set this to GML, the ECW SDK will be used to write ECW SDK style GML headers.

eg.
 gdal_translate -of JP2ECW -co PROJ=GEODETIC -co DATUM=WGS84 1.tif out.jp2 -co GEODATA_USAGE=GML

In some cases you might even find you have to use the GEOJP2=OFF and GMLJP2=OFF creation options to supress GDAL's own coordinate system writers.

I'm hesitant to document this special option though as I think any documentation I prepare is going to be confusing to many users. I suppose though, I should remove the PROJ and DATUM creation options from the JP2ECW driver then.

comment:5 by warmerdam, 17 years ago

Resolution: invalid
Status: reopenedclosed

I don't think there are any remaining issues. Please feel free to re-open if you think there is.

Note: See TracTickets for help on using tickets.