[GRASS-dev] v.rast.stats wxPython GUI input reading error

GRASS GRASS developer
1

Hello,

the following error happens with actual SVN. (Debian Lenny system)

v.rast.stats vector=irrigation@PERMANENT raster=neth_freq@PERMANENT colprefix=freq
Traceback (most recent call last):
File “/usr/local/grass-7.0.svn/scripts/v.rast.stats”, line
275, in
main()
File “/usr/local/grass-7.0.svn/scripts/v.rast.stats”, line
130, in main
kv = grass.raster_info(map = raster)
File “/home/yann/tmp/grass/dist.i686-pc-linux-
gnu/etc/python/grass.py”, line 568, in raster_info
kv[k] = float(kv[k])
ValueError: invalid literal for float(): 0:00:07.81346
Raster map <irrigation_6733.0> not found
<irrigation_6733.0> nothing removed
(Mon Feb 2 16:44:56 2009) Command finished (0 sec)

–
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
YiKingDo: http://yikingdo.unblog.fr/

2

Yann Chemin wrote:

the following error happens with actual SVN. (Debian Lenny system)

  File "/home/yann/tmp/grass/dist.i686-pc-linux-gnu/etc/python/grass.py", line 568, in raster_info
    kv[k] = float(kv[k])
ValueError: invalid literal for float(): 0:00:07.81346

"r.info -s" outputs DMS, when it should probably use decimal (-g uses
decimal for n/s/e/w).

--
Glynn Clements <glynn@gclements.plus.com>

3

Glynn wrote:

"r.info -s" outputs DMS, when it should probably
use decimal (-g uses decimal for n/s/e/w).

g.region and libgis accept res=DD:MM:SS, so why should it use decimal?
Usually for lat/lon resolutions (e.g. 2 minutes or 30 seconds) it is
much better & more precisely+understandably represented by DD:MM:SS than
some endless 0.00833333333333... number. So IMO the GUI should be
enhanced to accommodate DMS instead of the user being inconvenienced
because it is simpler for the programmer.

as to conformity with 'r.info -g' using decimal, I guess you could say that
it matches 'g.region -g' which prefers decimal as it is used more with e.g.
awk math, while r.info is more for the user's eyes..? maybe add decimal
resolution to 'r.info -g' so user has access to both ways if they use
it with awk scripts.

We would definitely need to work on bug #335 to improve resolution
precision, as for lat/lon %.6f does not keep preserve precision over
output-input round trip for real-case resolutions.
  https://trac.osgeo.org/grass/ticket/335
(for meter based projections it is sub-millimeter so rarely noticed there)

Hamish

4

Hamish wrote:

> "r.info -s" outputs DMS, when it should probably
> use decimal (-g uses decimal for n/s/e/w).

g.region and libgis accept res=DD:MM:SS, so why should it use decimal?

So that everything which uses it doesn't have to explicitly convert it
to decimal.

Usually for lat/lon resolutions (e.g. 2 minutes or 30 seconds) it is
much better & more precisely+understandably represented by DD:MM:SS than
some endless 0.00833333333333... number. So IMO the GUI should be
enhanced to accommodate DMS instead of the user being inconvenienced
because it is simpler for the programmer.

This has nothing to do with the GUI.

as to conformity with 'r.info -g' using decimal, I guess you could say that
it matches 'g.region -g' which prefers decimal as it is used more with e.g.
awk math, while r.info is more for the user's eyes..?

r.info with no flags is intended for the user. I'm not convinced that
the same is true of "r.info -s":

  $ r.info -s nations
  nsres=0:04:48
  ewres=0:04:48

Is it coincidence that the output uses shell syntax?

maybe add decimal
resolution to 'r.info -g' so user has access to both ways if they use
it with awk scripts.

It isn't just awk. v.rast.stats is using Python's float() function,
which doesn't understand DMS either. In fact, very few generic
string-to-number conversion functions understand DMS.

The attached patch should solve this in grass.py, but needs testing,
but it still means that everything else needs to handle both DMS and
decimal for the output from "r.info -s". Chances are that anything
using r.info -s will make the same mistake.

--
Glynn Clements <glynn@gclements.plus.com>

(attachments)

python_dms.patch (947 Bytes)