[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):

 Thanks for the explanation. The difference between the g.region
 representation to the shell and the information in the python dictionary
 does seem a result of lossy conversion (e.g., 4.9998993900000004).

 The reason we have run into to this is due to using GRASS outside the
 normal (and now pythonized) GRASS environment. Our Java-based ABM of
 farming households is running GRASS modules like g.region to get and
 change region settings. However, it is also running Python-based GRASS
 scripts that run surface process models and related routines. The latter
 use the GRASS Python library functions.

 Maybe there is no solution to this, but it seems that g.region and
 grass.region() *ought* to be returning exactly the same values. At least,
 without knowing what you have explained, the normal assumption is that
 these would match.

 If we have Java (or perhaps our Python scripts) round grass.region()
 values to the maximum number of significant digits output to the shell, do
 you think we could be assured that the values would match exactly? If so,
 what about making this an optional argument (i.e, match g.region shell
 output) for grass.region(), grass.raster_info(), and other Python library
 functions that return region boundaries?

 Michael

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1161#comment:5>
GRASS GIS <http://grass.osgeo.org>