Calculation of bearing between 2 points, using d.measure

[dylan]

Simple patch to add calculation of math-style bearing calculation (N = 90 deg) or compass-style bearing calculation (N = 0) to d.measure.

[dylan]

Has anyone had a chance to review this patch for submission to trunk yet?

[cmbarton]

I haven't seen this patch, but measuring in the wxPython GUI DOES provide bearing information. This is already working and available.

Note that d.measure only works in old xmons, and won't work on Windows.

Michael

[dylan]

updated for GRASS 6.5 (r39462)

[dylan]

I understand that the GUI has this functionality, but there are many of us who do not use the GUI. I have updated the patch to conform to the current (r39462) version of GRASS65. If it seems like a useless patch, then I will maintain my own local version.

[glynn]

Replying to dylan:

Has anyone had a chance to review this patch for submission to trunk yet?

The "trunk" is 7.0, which doesn't have d.measure or the functionality it requires (the ability to query the mouse pointer).

The code is still there, but it doesn't compile due to the absence of R_get_location_with_pointer(). It was retained in case it was felt worthwhile to modify it to take x,y coordinates via command-line options or stdin, rather than via the mouse. As the functionality has been added directly to the GUI, it's likely that d.measure will be removed altogether.

[martinl]

Replying to glynn:

Replying to dylan:

Has anyone had a chance to review this patch for submission to trunk yet?

The code is still there, but it doesn't compile due to the absence of R_get_location_with_pointer(). It was retained in case it was felt worthwhile to modify it to take x,y coordinates via command-line options or stdin, rather than via the mouse. As the functionality has been added directly to the GUI, it's likely that d.measure will be removed altogether.

What about m.measure in GRASS 7? This module could read x,y coordinates from stdin as you suggested. The module could used by GUI.

[glynn]

Replying to martinl:

What about m.measure in GRASS 7? This module could read x,y coordinates from stdin as you suggested. The module could used by GUI.

That possibility was why d.measure was retained.

Whether such a module should be called m.measure (or g.measure) or d.measure depends upon whether the coordinates are cartographic coordinates or display coordinates.

[cmbarton]

Not using a graphical user interface means typing controlling a module via typed commands (i.e. on the command line). Being able to enter screen x and y coordinates and return a bearing and distance could be useful; it might make GUI programming easier in fact. Using the command line is very useful for a variety of GIS functions of course and essential for scripting.

d.measure is a GUI, but a very antiquated one. That is, it allows a user to interact with a graphic display using a mouse or other pointing device. Maintaining this very old, platform specific GUI in C (i.e., it requires an xterm environment that emulates even older graphic hardware displays) is problematic for a variety of other functions, as well as for having a consistent command line behavior in which the user types a command and the module creates a map, a graphic output, or returns text. We now have a GUI that is about 3 generations past the d.measure GUI environment that sits on top of the command line GRASS interface. Users can type all the commands they want without interference from the GUI. When the user wants to interact with the program graphically, the GUI can be used (or invoked if previously closed). Given all this, I can't see the reason to maintain an alternative, very old GUI for xterms only.

Michael

[neteler]

Replying to cmbarton:

Not using a graphical user interface means typing controlling a module via typed commands (i.e. on the command line). Being able to enter screen x and y coordinates and return a bearing and distance could be useful; it might make GUI programming easier in fact. Using the command line is very useful for a variety of GIS functions of course and essential for scripting.

Perhaps m.cogo can be used here (cmd line and GUI backend)? ​http://grass.osgeo.org/grass64/manuals/html64_user/m.cogo.html

Markus

[hamish]

everything is already there for command line use from r.transect, r.profile, as Markus points out m.cogo (although that is primarily designed to mirror US survey definitions), and * swig/python/m.distance.py *.

also there is code in d.geodesic and d.rhumbline to play with.

Hamish

[dylan]

This patch doesn't seem all that useful anymore after the move to wx-based GUI.