[GRASS-dev] Re: [GRASS GIS] #1161: g.region and r.info decimel issue when using grass python libs

[GRASS GIS]

#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>