[gdal-dev] Is PAM always used before GeoTIFF tags?

[Even Rouault]

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
>
> <SourceGCPs xsi:type="typens:ArrayOfDouble">
>
> <Double>3.3670799903498199</Double>
>
> <Double>14.344873843184562</Double>
>
> 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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220322/55e48153/attachment.html>