[GRASS-dev] Re: [GRASS GIS] #352: r.in.gdal region troubles in LL
GRASS GIS
trac at osgeo.org
Sat Nov 1 01:48:57 EDT 2008
#352: r.in.gdal region troubles in LL
--------------------------+-------------------------------------------------
Reporter: neteler | Owner: grass-dev at lists.osgeo.org
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>
More information about the grass-dev
mailing list