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 _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
