Le mercredi 11 décembre 2013 19:23:09, Tim Keitt a écrit : > On Tue, Dec 10, 2013 at 12:44 PM, Even Rouault > <[email protected] > > > wrote: > > > > Le mardi 10 décembre 2013 16:48:31, Ivan Lucena a écrit : > > > Hi Even, > > > > > > > From: [email protected] > > > > To: [email protected] > > > > Subject: Re: [gdal-dev] Default GeoTransform for MEM driver > > > > Date: Mon, 9 Dec 2013 20:54:35 +0100 > > > > CC: [email protected]; [email protected]; > > > > [email protected] > > > > > > 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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
