WxGUI should provide area measurement tool

[marisn]

Most of GUI GIS programs provide area measurement tools. Current wxgui version provides only line length measurement (which is cool).

As area calculations can be tricky, it should use some of lib/gis(?) function via some module.

[hamish]

see d.measure which does this for xmons; G_area_of_polygon() is used (lib/gis/area.c). Importantly it works for lat/lon too.

classic case for SWIG style links to libgis, but a new m.area module could take a series of coords and spit out an answer.

does the wxGUI measurement tool use geodetic distance for lat/lon locations?

Hamish

[hamish]

duh, swig/python/examples/m.distance.py

[cmbarton]

Well, if d.measure had the architecture to accept coordinate pairs and return line lengths and areas defined by the coordinate pairs, this would have been easy to implement in the GUI.

BUT, d.measure ran as a persistent process that only accepted input from interactive drawing in an xterm emulation environment.

So, measurement has had to be recreated entirely in Python/wxPython. And as you say, area calculations are tricky.

Michael

[glynn]

Replying to cmbarton:

BUT, d.measure ran as a persistent process that only accepted input from interactive drawing in an xterm emulation environment.

So, measurement has had to be recreated entirely in Python/wxPython. And as you say, area calculations are tricky.

So do you want me to recycle d.measure into g.measure?

[hamish]

can swig/python/examples/m.distance.py (or swig in general) be used by the core wxgui.py? if so, there is very little left to do. if not I guess we need a C version of it.

even if swig errors can not be caught directly, m.distance.py as a separate program probably could be caught when called from wxgui.py. (?)

same question is true for gui/wxpython/gui_modules/units.py and probably a lot of other stuff which should be handled by libgis instead of reimplemented from scratch in the GUI code.

Hamish

[glynn]

Replying to hamish:

can swig/python/examples/m.distance.py (or swig in general) be used by the core wxgui.py? if so, there is very little left to do. if not I guess we need a C version of it.

SWIG is not a mandatory dependency. IMO, it should remain that way, given that SWIG is not particularly well documented and seems to be relatively unstable.

IOW, important functionality must not depend upon the existence of the SWIG bindings in grass.lib.

[hamish]

Glynn:

IOW, important functionality must not depend upon the existence of the SWIG bindings in grass.lib.

so we need to port m.distance.py to C. ok; swigged python -> should be pretty easy.

(fwiw my 2c naming preference is to use g.* for Gis support things (eg g.findfile) and m.* for geoMath things (eg m.cogo, m.proj), and so m.{distance|measure} instead of g.*)

SWIG is not particularly well documented and seems to be relatively unstable.

It occurs to me that we are a bit spoiled by our long-time use of hyper-mature ANSI C and tcl/tk. wx and even python are still evolving very fast by comparison.

Hamish

[cmbarton]

I've been mostly out of the loop--demo-ing GRASS 7 at UCL--but have followed a bit on this. Ideally, for this and some other functions that we've had to recreate in the GUI, it would be better to have a GRASS module. I suppose I agree with the m.* for the name argument (though I don't have especially strong feelings about it). It will take some rewriting to integrate such functions now, but ultimately worthwhile.

I don't remember what all d.measure did, however. The current GUI implementation gives: segment length, segment bearing, total multisegment length, and has a nice (and easily parsable) output format. Does d.measure do that? For area, is it only calculated for closed polygons or for open ones too?

Michael

[glynn]

Replying to cmbarton:

I don't remember what all d.measure did, however. The current GUI implementation gives: segment length, segment bearing, total multisegment length, and has a nice (and easily parsable) output format. Does d.measure do that? For area, is it only calculated for closed polygons or for open ones too?

d.measure (now m.measure in 7.0) calculates the cumulative length obtained from passing each pair of adjacent points to G_distance() and, if 3 or more points are given, the area from G_area_of_polygon().

There should probably be an option to include the distance between the last and first points, i.e. calculate the perimeter. Currently, for N points it calculates the length for N-1 segments; if you want the perimeter, you have to duplicate the first point as the last point.

[annakrat]

Area measurement tool is now available in GRASS 7 (r58611). It uses m.measure module.

[marisn]

Replying to annakrat:

Area measurement tool is now available in GRASS 7 (r58611). It uses m.measure module.

Nice work, Anna. I tested and it works almost excellent. I opened a new bug for event handling #2204.

I have no strong opinion about necessity to backport to 6.x. I would vote to NOT do it - otherwise there is small motivation to release 7...