[GRASS5] r.in.gdal - precision problem in lib/gis/adj_cellhd.c

[Markus Neteler]

On Sun, Apr 10, 2005 at 02:44:17PM +1200, Hamish wrote:
> > But the result will be a map with north > 90 in any case.
> > 
> > If we need a short term solution, I suggest to change the error to 
> > warning or maybe a warning for 90 < north < 90.000x and error for
> > north 
> >  > 90.000x?
> 
> 
> Can we establish from that 30" data causing the problem if the top cells
> are centered at 90N or at 89d 59' 45" ? Having a row of (non-uniform)
> data centered at 90N seems like a mistake in the data creation to me.

As far as I know the GDAL software reports cell *corners* including
the C/C++ functions:

gdalinfo  SRTM_GTOPO_u30_n090w020.tif
Driver: GTiff/GeoTIFF
Size is 4800, 6000
...
Origin = (-20.000000,90.000000)
Pixel Size = (0.00833333,-0.00833333)
...
Corner Coordinates:
Upper Left  ( -20.0000000,  90.0000000) ( 20d 0'0.00"W, 90d 0'0.00"N)
Lower Left  ( -20.0000000,  39.9999974) ( 20d 0'0.00"W, 39d59'59.99"N)
Upper Right (  20.0000021,  90.0000000) ( 20d 0'0.01"E, 90d 0'0.00"N)
Lower Right (  20.0000021,  39.9999974) ( 20d 0'0.01"E, 39d59'59.99"N)
Center      (   0.0000010,  64.9999987) (  0d 0'0.00"E, 65d 0'0.00"N)

The number of rows/columns looks ok.
So GRASS north coordinates should be GDAL corners minus 0.5 resolution.
Or not?

Even if the data set was not generated properly, GRASS should somehow
deal with that (as I cannot ask GLCF to redo the file).

What about a subtle fixing up in cases that just the coordinates
exceed the global bounds by some small epsilon?

Markus