#1161: g.region and r.info decimel issue when using grass python libs -------------------------+-------------------------------------------------- Reporter: isaacullah | Owner: grass-...@… 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>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev