Jukka,
Le 22/03/2022 à 12:56, Rahkonen Jukka (MML) a écrit :
Hi,
See this question
https://gis.stackexchange.com/questions/426418/create-rectified-geotiff-given-aux-xml-produced-from-arcgis?
The GeoTIFF driver documentation
https://gdal.org/drivers/raster/gtiff.html#georeferencing says about
the order in which the georeferencing is searched “By default,
information is fetched in following order (first listed is the most
prioritary): PAM (Persistent Auxiliary metadata) .aux.xml sidecar
file, INTERNAL (GeoTIFF keys and tags), TABFILE (.tab), WORLDFILE
(.tfw, .tifw/.tiffw or .wld).”
However, in this case it seems that GeoTIFF tags are used instead of
PAM if not especially asked with --config GDAL_GEOREF_SOURCES PAM
Yes I can see in the code that for that particular case with standard
TIFF tags expressing a geotransform (which is completely buggy on the
sample file of the stackexchange thread) an this ESRI GeodataXform
.aux.xml stuff, both will be reported. I've just fixed this in
https://github.com/OSGeo/gdal/commit/acbd907896418330315f3e6febf620d4686023ac
Adding -to SRC_METHOD=GCP_POLYNOMIAL or GCP_TPS to gdalwarp will force
the GCPs to be used.
I am also curious to know how the SourceGCP values in this PAM file
gets converted into pixel rows and columns. For example these values
3.3670799903498199
14.344873843184562
seem to turn into (1010.12399710495,3376.53784704463). How does it
happen and where is it documented? I think there must happen some
scaling and offsetting but is this something ESRI specific? I found
this ESRI document but there the columns and rows appear unscaled in
the aux.xml file
https://doc.arcgis.com/en/imagery/workflows/browse-imagery/workflow/workflow-appendices.htm.
I see support for the ESRI GeodataXform .aux.xml stuff was added in
https://github.com/OSGeo/gdal/commit/7025e356c28
The interesting part to explain the difference between the values in the
files and the ones reported by gdalinfo is in:
+ // The origin used is the bottom left corner,
+ // and raw values are in inches !
+ pasGCPList[i].dfGCPPixel = adfSourceGCPs[2*i] *
+ CPLAtof(pszTIFFTagXRes);
+ pasGCPList[i].dfGCPLine = nRasterYSize -
+ adfSourceGCPs[2*i+1] *
CPLAtof(pszTIFFTagYRes);
At least this was found to be necessary on the sample file that was used
to develop this code. And actually trying with the file in the
stackexchange thread, this leads to correct georeferencing.
Even
-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
