[gdal-dev] Setting the georeferencing priority for GDAL

[Jukka Rahkonen]

Even Rouault <even.rouault <at> mines-paris.org> writes:

> 
> Hi Jukka,
> 
> > I can also see that GDAL does have a config option GMLJP2OVERRIDE but I
> > could not easily find what is is doing.
> 
> /* -------------------------------------------------------------------- */
> /*      This is a backdoor to let us embed a literal gmljp2 chunk       */
> /*      supplied by the user as an external file.  This is mostly       */
> /*      for preparing test files with exotic contents.                  */
> /* -------------------------------------------------------------------- */

Ok, not for mortals.

> > 
> > And finally when I was playing with a "gdal_edit.py" utility I discovered
> > that there are at least 4 ways to georeference a JPEG2000 file:
> > - use worldfile .wld or .j2w
> > - use internal GeoJP2 (GeoTIFF) georeferencing
> > - use internal GML georeferencing
> > - use an external .aux.xlm file
> > 
> > I noticed that command
> >  python gdal_edit.py -a_srs epsg:3067 metajp2test.jp2
> > was creating a file names "metajp2test.jp2.aux" which does contain the
> > right georeferencing data.
> 
> > However, if I run gdalinfo it is looking for
> > the internal GeoJP2 metadata and it reports that my JPEG2000 file is still
> > using an unknown projection.
> 
> Was it with the JP2OPENJPEG driver ? JP2KAK and JP2ECW should return what is 
> found in .aux.xml.

Yes, it was JP2OPENJPEG. I was testing in the average user mode and did not
bother to search Windows binaries with other JPEG2000 drivers and playing
with GDAL_SKIP config option. They are not for mortals either. It would be
good if all the JPEG2000 drivers would behave in a similar way with
georeferencing.
 
> I also agree with Frank that PAM information should override internal 
> information.
> 
> In the case of JPEG2000, I think it might be possible, pending some work, to 
> edit the JP2 boxes to rewrite the GeoJP2 and/or GMLJP2 boxes in place. Well, 
> maybe not in all cases if the size of the new boxes is larger than the old 
> boxes. In which case a utility could rewrite a slightly larger file by
shifting 
> the compressed imagery off a few bytes, but without modifying it at all.

I am remembering that for the JPEG2000 standard it is OK to write the boxes
also after the codestream. I am also remembering that you wrote a script
that did that with GML box about one and a half year ago. I bet that some
JPEG2000 libraries would not find the boxes at the end of the file, though. 

-Jukka-