[gdal-dev] Setting the georeferencing priority for GDAL
Hi, Sometimes an image can have several and ambiguous metadata for georeferencing. Mapserver has a method to deal with ambiguous internal geotiff metadata and world files and user can override the internal metadata by using PROCESSING EXTENT_PRIORITY=WORLD in the mapfile. http://www.mapserver.org/input/raster.html#special-processing-directives. I thought it was PROCESSING EXTENT_PRIORITY=WORLDFILE but perhaps both keywords are supported. I wonder if GDAL supports this same worldfile override with some secret config option. At least it is not listed on page http://trac.osgeo.org/gdal/wiki/ConfigOptions. I can also see that GDAL does have a config option GMLJP2OVERRIDE but I could not easily find what is is doing. 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. This feels a bit messy. Perhaps there is a need to have a GDAL wide config option for what metadata to search and use for georeferencing. In my case I would like to set it to use external GDAL aux.xml. In addition, I think that this setting should be made safe so that if aux.xml file is not found then the image is considered to be without georeferencing. Or perhaps the config option could take a list like auxiliary_xml,GeoJP2 with all the acceptable alternatives in priority order. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Setting the georeferencing priority for GDAL
Jukka, Part of why behavior is inconsistent now is that the logic is in each driver. Some might give precidence to a world file over something internal, or to .aux.xml. I think it would be *desirable* for .aux.xml to take precedence over internal information when it is available as it is normally only in the .aux.xml file because it was updated or accurate information could not be written within the file itself. I'm not sure how we would go about updating all drivers to have consistent behavior. I do like the idea that drivers can control this. I just think it would be good to have a suggested behavior we aim for. I'm not too keen on a configuration option as those are always a sort of hack, though it is possible. I will note you can always gdal_translate to VRT and then hand edit or alter it with gdal_edit.py to get a wrapped dataset with the desired georeferencing and other metadata. Best regards, Frank On Sun, Oct 27, 2013 at 4:02 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fiwrote: Hi, Sometimes an image can have several and ambiguous metadata for georeferencing. Mapserver has a method to deal with ambiguous internal geotiff metadata and world files and user can override the internal metadata by using PROCESSING EXTENT_PRIORITY=WORLD in the mapfile. http://www.mapserver.org/input/raster.html#special-processing-directives. I thought it was PROCESSING EXTENT_PRIORITY=WORLDFILE but perhaps both keywords are supported. I wonder if GDAL supports this same worldfile override with some secret config option. At least it is not listed on page http://trac.osgeo.org/gdal/wiki/ConfigOptions. I can also see that GDAL does have a config option GMLJP2OVERRIDE but I could not easily find what is is doing. 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. This feels a bit messy. Perhaps there is a need to have a GDAL wide config option for what metadata to search and use for georeferencing. In my case I would like to set it to use external GDAL aux.xml. In addition, I think that this setting should be made safe so that if aux.xml file is not found then the image is considered to be without georeferencing. Or perhaps the config option could take a list like auxiliary_xml,GeoJP2 with all the acceptable alternatives in priority order. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GPKG Driver
Hey all, I'm preparing to do up a GeoPkg driver. In searching the mail history and the web, the only references I see so far are suggestions as a summer of code project (which weren't taken up?) which included the recommendation of wrapping it into the existing sqlite driver. Couple questions: - Did anything happen on the summer of code suggestion, or any other independent development front? - On the wrap it into the existing driver recommendation, how strong is that? If am doing the driver, I'm loath to try and wrap it in, particularly since the current SQLite driver already includes so much optionality and different behaviour. My last experience trying that kind of thing, on a much simpler driver in PDAL (trying to add pgpointcloud support into a generic soci oracle/pg driver) resulted in a lot of time spent and eventually writing a new native driver that was vastly easier to write and understand. Which is a long, whiny way of saying: I'd like to implement GPKG as a separate driver, not as part of SQLite, if that's acceptable (or, not completely unacceptable). Thanks! Paul ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
