[GRASS-dev] Re: [GRASS GIS] #1161: g.region and r.info decimel
issue when using grass python libs
GRASS GIS
trac at osgeo.org
Thu Sep 30 14:07:39 EDT 2010
#1161: g.region and r.info decimel issue when using grass python libs
-------------------------+--------------------------------------------------
Reporter: isaacullah | Owner: grass-dev@…
Type: defect | Status: closed
Priority: normal | Milestone: 6.4.1
Component: Python | Version: 6.4.0
Resolution: invalid | Keywords:
Platform: All | Cpu: All
-------------------------+--------------------------------------------------
Comment(by cmbarton):
Replying to [comment:2 glynn]:
> Replying to [ticket:1161 isaacullah]:
>
> > When running grass.region() and grass.raster_info(), values come out
in double precision, which is NOT what you get if you run g.region or
r.info, where they come out in single precision. This can cause region
misalignments and problems with boolean comparisons in scripts.
>
> These functions simply parse the (decimal) output from g.region and
r.info. Python has printf-like formatting operations if you wish to use
them.
Actually this is not what seems to be happening. g.region and r.info
produce single precision values, as expected. But the python library
functions do not seem to be getting values from these--or are doing
something strange with the values after the fact--in order to come up with
double precision values. The result is that the values in the dictionary
produced by grass.region() and grass.raster_info() are *different* from
the values that come from g.region or r.info. Therein lies the problem.
A region set using g.region is different from a region set using
grass.region(). The difference is not much but it is enough to cause
problems if you are comparing regions in a boolean way or trying to
overlay maps created with a setting in g.region and maps created with a
setting from grass.region().
My only guess is that somehow grass.region() is populating its dictionary
via a swig/ctype call instead of just parsing g.region. If this guess is
wrong, then something else is happening to the values after they are
generated by g.region and before they go into the python dictionary.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1161#comment:3>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list