[gdal-dev] geotiff projection not showing up

[Even Rouault]

Le dimanche 10 novembre 2013 00:14:42, Trent Piepho a écrit :
> On Sat, Nov 9, 2013 at 1:07 PM, Norman Goldstein <normvcr at telus.net> wrote:
> > Things are better, now, but not quite there for me.
> > Still not able to transform pixel/line to PCS space.
> > (the listgeo dump is, below)
> > 
> > I think the problem is that there is no definition of the
> > 
> > ModelPixelScaleTag
> > 
> > It seems that this tag, together with the ModelTiepointTag,
> > is how an affine transformation is inferred.  Or by directly
> > setting
> > 
> > ModelTransformationTag
> > 
> > which I could do with GDALDataset's SetGeoTransform()
> > method (for defining 2D affine transformations).
> 
> I've found that unless you call SetGeoTransform() and give an affine
> transform, most apps, including listgeo and gdalsrsinfo, aren't
> entirely happy with the georeferencing.  GDAL has a function that
> computes a transform from GCPs, but it needs to be part of the GDAL
> code for the dataset driver.  GDAL doesn't automatically do it when a
> user of GDAL wants an affine transform from a dataset.

True. This is (I think) a design decision, as generally GDAL tries to expose 
information as close as possible to what is in the dataset. GCPs alone don't 
provide an unambiguous way of transforming image pixel coordinates into real-
world coordinates. You have to specify which extrapolation method you want to 
use : polynomial at which order, thin plate spline, .. 

Of course with 3 points, you can (but not necessarily must) compute an affine 
transform in an unambiguous way, but in that case you'd rather define the 6 
coefficient geotransform directly.

And I've worked with a mapping authority that forbids from implicitly using 
the tiepoints from a GeoTIFF to compute a geotransform.

Depending on the cases, GDAL drivers might choose to compute an approximate 
geotransform from the GCPs, but GDAL core will not make that behind their 
back.

> 
> It seems like most code that tries to find corner coordinates and/or
> the pixel size of a raster expects an affine transform plus a
> projection.  If there are a set of GCPs, then that code won't work.
> The information may well be there, like your three GCP points, but the
> GDAL user needs totally different code make use of it.  It's the same
> reason most of NOAA's nautical charts don't work with apps that use
> GDAL or GDAL created GeoTIFFs.  I've just started looking at the GDAL
> code, but it doesn't seem like GDAL abstracts this enough to have
> broad compatibility.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html