[GRASSLIST:5720] Re: r.in.gdal problem?

[Frank Warmerdam]

David Orme wrote:
> Hi Frank,
> 
> I've attached a tar.gz file of one the coverages - I've double checked 
> that the behaviour wasn't a Friday afternoon brainstorm and I still get 
> the same problem.

David,

I have confirmed that the AIG driver in GDAL is needlessly offseting
the the corner coordinate by half a pixel.  It seems that the bnd.adf
information is indeed the outer boundary of the raster, and is not
center-of-pixel oriented like some ESRI metadata.

I verified this by loading another grid coverage in ArcView 3.x and zooming
way in so I could explore the coorinates within the top left pixel.

I have corrected the AIG driver in GDAL.  You can either manually fix
your bounds in GRASS, or download and install the latest GDAL source.
If you want a tar file of GDAL source you can wait till tomorrow and
download the daily CVS snapshot which should then include the fixes.
To verify ensuring you get revision 1.19 of gdal/frmts/aig/aigdataset.cpp.

> The coverage is the global distribution of a threatened bird species on 
> a 1 degree grid so it is mostly zeros with a small cluster of 1's. Just 
> as a warning, the original Arc shapefile wraps around in order not to 
> have to split up range maps across the 180E meridian - hence the W and E 
> extents. Incidentally, these are also misaligned, - they should be 226W 
> to 331E.

The coverage does have the -226 to 331 extents within the context of GDAL
where there isn't even any awareness that the coordinates are lat/long.
I don't know much about the handling of "out of bounds" lat/long values
in GRASS.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent