Opened 10 years ago

Closed 6 years ago

#975 closed enhancement (fixed)

WxGUI should provide area measurement tool

Reported by: marisn Owned by: grass-dev@…
Priority: normal Milestone: 7.0.0
Component: wxGUI Version: unspecified
Keywords: d.measure Cc:
CPU: All Platform: All

Description

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.

Change History (13)

comment:1 Changed 10 years ago by hamish

Component: defaultwxGUI
CPU: UnspecifiedAll
Keywords: d.measure added
Platform: UnspecifiedAll

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

comment:2 Changed 10 years ago by hamish

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

comment:3 Changed 10 years ago by 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

comment:4 in reply to:  3 Changed 10 years ago by 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?

comment:5 Changed 10 years ago by 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

comment:6 in reply to:  5 Changed 10 years ago by 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.

comment:7 Changed 10 years ago by martinl

Milestone: 6.4.06.5.0

comment:8 Changed 10 years ago by 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

comment:9 Changed 10 years ago by 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

comment:10 in reply to:  9 Changed 10 years ago by 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.

comment:11 Changed 7 years ago by annakrat

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

comment:12 in reply to:  11 Changed 6 years ago by 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...

comment:13 Changed 6 years ago by annakrat

Milestone: 6.5.07.0.0
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.