[GRASS-user] Re: r.in.gdal oddity

[Hamish]

Hamish:
> >> AFAIK it is working as intended and without bugs.
Markus:
> > Please check then
> > http://article.gmane.org/gmane.comp.gis.grass.user/41407
> > 
> > Here I don't see that -l works.

I will look into it, but my suspicion is that the dataset in question has
IEEE FP issues like -180.00000000000001 which gdalinfo's printf is hiding.

Also to confirm that there hasn't been a new bug introduced I will retry
to import e.g. the ETOPO5 dataset which exists 180W to 180E, and used to
import without any trouble. (I've tested this a lot in the past because I
cross the dateline a lot in my work, and for the last many years it has
worked fine for rasters)


WRT the -l flag, if you use 'r.in.gdal -l' you _must_ use r.region after
to correct the map bounds+resolution. By definition the flag just makes
something up to fool the system into letting you import it, and it is
no surprise that the resulting bounds+resolution are not correct.
maybe we should make rasters imported with -l scale from 0.0 - 1.0 EW,NS
to make it more obvious that the bounds+res are only placeholders, but
I'd guess that would cause more trouble that it fixes.


either way, r.region is the quick-fix solution.


regards,
Hamish