[gdal-dev] Default GeoTransform for MEM driver

Even Rouault even.rouault at mines-paris.org
Wed Dec 11 10:30:44 PST 2013


Le mercredi 11 décembre 2013 19:23:09, Tim Keitt a écrit :
> On Tue, Dec 10, 2013 at 12:44 PM, Even Rouault
> <even.rouault at mines-paris.org
> 
> > wrote:
> > 
> > Le mardi 10 décembre 2013 16:48:31, Ivan Lucena a écrit :
> > > Hi Even,
> > > 
> > > > From: even.rouault at mines-paris.org
> > > > To: gdal-dev at lists.osgeo.org
> > > > Subject: Re: [gdal-dev] Default GeoTransform for MEM driver
> > > > Date: Mon, 9 Dec 2013 20:54:35 +0100
> > > > CC: lucena_ivan at hotmail.com; tkeitt at utexas.edu;
> > 
> > jukka.rahkonen at mmmtike.fi
> > 
> > > > Le lundi 09 décembre 2013 18:08:19, Ivan Lucena a écrit :
> > > > > The other problem with that documentation is the return code.
> > 
> > CE_Failue
> > 
> > > > > means that the driver does not support it and/or that the dataset
> > > > > doesn't have it.
> > > > 
> > > > The current behaviour of the MEM driver doesn't particularly shock
> > > > me.
> > 
> > It
> > 
> > > > seems OK to return CE_Failure if SetGeoTransform() hasn't been
> > > > explicitely called to define it. And as far as the default
> > 
> > geotransform,
> > 
> > > > it is a matter of taste. [ 0, 1, 0, 0, 0, 1] would be indeed a bit
> > > > more classical for a ungeoreferenced image, but one can consider
> > > > that if GetGeoTransform() returns CE_Failure, the returned
> > > > geotransform is to
> > 
> > be
> > 
> > > > ignored.
> > > 
> > > That is good to know. So it really doesn't matter if the driver support
> > > geotransformation or not.
> > > 
> > > But my concern is when it returns CE_None. What does it really means
> > > because I was checking some driver's implementation of GetGeoTransform
> > 
> > and
> > 
> > > I noticed that some of then always return CE_None no matter what.
> > > So would
> > > that be possible that a dataset is *ungeoreferenced* and a driver
> > > returns CE_None with the default values [0, 1, 0, 0, 0, 1].
> > > Should we trust that
> > > those values [0, 1, 0, 0, 0, 1] are correct or are they just a default
> > > filler?
> > > 
> > > For example, to get [0, 1, 0, 0, 0, 1] we should expect a world-file
> > > that should be something like:
> > > 
> > > 1.0000000000
> > > 0.0000000000
> > > 0.0000000000
> > > 1.0000000000
> > > 0.5000000000
> > > 0.5000000000
> > > 
> > > Not:
> > > 
> > > 1.0000000000
> > > 0.0000000000
> > > 0.0000000000
> > > 1.0000000000
> > > 0.0000000000
> > > 0.0000000000
> > > 
> > > Anyway, I will trust that the CE_None means that the geotransformation
> > > values are correct but should I will also check if the values are equal
> > 
> > to
> > 
> > > [0, 1, 0, 0, 0, 1] just in case? And what to do if they are?
> > 
> > I'm not sure to know the ultimate answer to your questions. My
> > understanding
> > of
> > http://www.gdal.org/classGDALDataset.html#af9593cc241e7d140f5f3c4798a43a6
> > 68 is that when there's no projection space associated to a raster, it
> > should return (0,1,0,0,0,1) and CE_Failure. But they are certainly
> > drivers that return (0,1,0,0,0,1) and CE_None. They should likely be
> > fixed to return CE_Failure instead. But you can also test if the
> > geotransform is (0,1,0,0,0,1)
> > since it isn't a likely real geotransform.
> 
> It would make things easier if all drivers returned the same default: (0,
> 1, 0, 0, 0, -1) for any dataset where the transform has not been assigned.
> (I reworked my test to use the assumption that spatial y and line index y
> are opposite sign and it works correctly.) I think it should be considered
> a bug in the docs and any driver the does not return that default.
> Otherwise users have to add a lot of ugly conditional code.

I don't see where there's a bug in the documentation. (0,1,0,0,0,1) is OK for 
the default geotransform. It means that spatial coordinate space = raster 
coordinate space.
It is the geotransform (0,1,0,0,0,-1) of the MEM driver that is a bit odd.
Patches welcome to unify driver behaviour.

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

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


More information about the gdal-dev mailing list