Opened 12 years ago

Closed 4 years ago

#76 closed enhancement (wontfix)

Calculation of bearing between 2 points, using d.measure

Reported by: dylan Owned by: grass-dev@…
Priority: minor Milestone: 6.5.0
Component: Display Version: unspecified
Keywords: d.measure Cc:
CPU: All Platform: All

Description

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

Attachments (2)

d.measure_bearing.patch (5.6 KB) - added by dylan 11 years ago.
bearing_patch.patch (5.0 KB) - added by dylan 10 years ago.
updated for GRASS 6.5 (r39462)

Download all attachments as: .zip

Change History (14)

Changed 11 years ago by dylan

Attachment: d.measure_bearing.patch added

comment:1 Changed 11 years ago by dylan

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

comment:2 Changed 11 years ago by cmbarton

CPU: Unspecified
Platform: Unspecified

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

comment:3 Changed 10 years ago by martinl

Milestone: 6.4.06.5.0

Changed 10 years ago by dylan

Attachment: bearing_patch.patch added

updated for GRASS 6.5 (r39462)

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

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

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

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

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

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

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

comment:11 Changed 6 years ago by hamish

Component: DefaultDisplay
CPU: UnspecifiedAll
Platform: UnspecifiedAll

comment:12 Changed 4 years ago by dylan

Resolution: wontfix
Status: newclosed

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

Note: See TracTickets for help on using tickets.