#352: r.in.gdal region troubles in LL --------------------------+------------------------------------------------- Reporter: neteler | Owner: [email protected] Type: defect | Status: new Priority: major | Milestone: 6.4.0 Component: default | Version: unspecified Resolution: | Keywords: Platform: Unspecified | Cpu: Unspecified --------------------------+------------------------------------------------- Comment (by glynn):
Replying to [comment:2 neteler]: > The user took this map > and passed it to R, and then redefined: > and then he wrote b as npp.tif using the QGIS plugin manageR. > Maybe there is a precision issue before, somwhere in the R or QGIS part? It appears so. The inaccuracy is present in the TIFF file; it isn't being introduced by libtiff, GDAL or GRASS. I'm not quite sure where it would come from; 1/4 is exactly representable in single-precision floating-point. My first guess would be something calculating 360*(1/1440) rather than 360/1440 (1/1440 isn't exactly representable). This can occur if code is compiled with -funsafe-math- optimizations or similar. In any case, there's still the issue that GRASS takes a lat/lon region which is actually 360.000000000288 degrees across and treats it as if it's 0.000000000288 degrees across. Wrapping coordinates is one thing; wrapping intervals is something else entirely. Ultimately, you can't take algorithms which work for Euclidian geometry and make them work for spherical geometry with nothing more than a couple of quick hacks. On a related note, I still haven't got anywhere with the "r.resamp.stats: nulls along western boundary" issue reported by Hamish (this should probably be added as a ticket). -- Ticket URL: <http://trac.osgeo.org/grass/ticket/352#comment:3> GRASS GIS <http://grass.osgeo.org>
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
