[GRASS-dev] Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

GRASS GIS GRASS GIS developer
1

On Mar 1, 2008, at 1:47 AM, Martin Landa wrote:

Micheal,

2008/3/1, Michael Barton <michael.barton@asu.edu>:

2008/2/29, Dylan Beaudette <dylan.beaudette@gmail.com>:
[snip]

Thanks for the update. I don't regularly use either of the GUI and
did
not know about this feature. Does the patch that I submitted
interfere
with this functionality? I think that it would be useful to have
this
functionality in the old style monitors as well.

d.measure is not used in wxGUI. Display windows are not registered as
GRASS displays (d.mon -L) [TODO, not sure how to implemented], I think
it would be good to use d.measure or something like g.measure in wxGUI
too instead of using Python-based function for distance calculation
(at least it would make sense for LL projections)? Please correct me
if I am wrong.

Michael,

What's wrong with the Python one?

duplication of the code, and in this particular case ignoring geodetic
distance for LL projections.

Well, my understanding of the direction of GRASS is that by v7, we'll lose all the interactive xterm-specific d.* modules. Interactive use will all be shifted to whatever GUI we design, rather than being hard-coded into a module. Simple, interactive measurement between 2 points on a display screen seems to me something to be handled by a GUI.

d.measure will go away OR change to a module in which you enter a start and end point and it returns the distance between the points. In the latter case, it could then be 'plugged into' a GUI as a function to calculate distance between points interactively 'grabbed' by the GUI.

Ignoring geodetic distance for LL projections is simply ignorance (on my part here) of the equations needed to do it. It's easy to determine if a location is LL. In that case, it should calculate geodetic distance rather than (or perhaps in addition to) displaying distance in map units. Just need to have the functions to do this added to the measurement methods.

Michael

2

Hi,

2008/3/1, Michael Barton <michael.barton@asu.edu>:

Well, my understanding of the direction of GRASS is that by v7, we'll
lose all the interactive xterm-specific d.* modules. Interactive use
will all be shifted to whatever GUI we design, rather than being hard-
coded into a module. Simple, interactive measurement between 2 points
on a display screen seems to me something to be handled by a GUI.

d.measure will go away OR change to a module in which you enter a
start and end point and it returns the distance between the points.
In the latter case, it could then be 'plugged into' a GUI as a
function to calculate distance between points interactively 'grabbed'
by the GUI.

In that case I would vote for `g.measure coords=` or something
similar. Then this module could be used in GUI (not matter which one)
or directly from CLI. Or in wxPython to use Python SWIG interface
(need to be improved) to use gislib for distance calculation and
similar.

Ignoring geodetic distance for LL projections is simply ignorance (on
my part here) of the equations needed to do it. It's easy to
determine if a location is LL. In that case, it should calculate
geodetic distance rather than (or perhaps in addition to) displaying
distance in map units. Just need to have the functions to do this
added to the measurement methods.

why to code it in Python when it is already available in gislib? We
should avoid code duplication.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

3

On Mar 1, 2008, at 8:41 AM, Martin Landa wrote:

Hi,

2008/3/1, Michael Barton <michael.barton@asu.edu>:

Well, my understanding of the direction of GRASS is that by v7, we'll
lose all the interactive xterm-specific d.* modules. Interactive use
will all be shifted to whatever GUI we design, rather than being hard-
coded into a module. Simple, interactive measurement between 2 points
on a display screen seems to me something to be handled by a GUI.

d.measure will go away OR change to a module in which you enter a
start and end point and it returns the distance between the points.
In the latter case, it could then be 'plugged into' a GUI as a
function to calculate distance between points interactively 'grabbed'
by the GUI.

In that case I would vote for `g.measure coords=` or something
similar. Then this module could be used in GUI (not matter which one)
or directly from CLI. Or in wxPython to use Python SWIG interface
(need to be improved) to use gislib for distance calculation and
similar.

Ignoring geodetic distance for LL projections is simply ignorance (on
my part here) of the equations needed to do it. It's easy to
determine if a location is LL. In that case, it should calculate
geodetic distance rather than (or perhaps in addition to) displaying
distance in map units. Just need to have the functions to do this
added to the measurement methods.

why to code it in Python when it is already available in gislib? We
should avoid code duplication.

Certainly. If a new version of d.measure or a hypothetical g.measure could be created, we could use that. Until that happens, we'll need to do it in Python (which is not all that bad). Is there anyway to access gislib directly from Python? This could be an alternative to creating a new module or changing an existing one.

Michael

4

Hi,

2008/3/1, Michael Barton <michael.barton@asu.edu>:
[snip]

>> Ignoring geodetic distance for LL projections is simply ignorance
>> (on
>> my part here) of the equations needed to do it. It's easy to
>> determine if a location is LL. In that case, it should calculate
>> geodetic distance rather than (or perhaps in addition to) displaying
>> distance in map units. Just need to have the functions to do this
>> added to the measurement methods.
>
> why to code it in Python when it is already available in gislib? We
> should avoid code duplication.

Certainly. If a new version of d.measure or a hypothetical g.measure
could be created, we could use that. Until that happens, we'll need
to do it in Python (which is not all that bad). Is there anyway to
access gislib directly from Python? This could be an alternative to
creating a new module or changing an existing one.

yes, via SWIG interface, see ./swig/python. Anyway the SWIG-Python
interface for GRASS is a bit limited, need to be improved.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

5

On Sat, Mar 1, 2008 at 7:18 AM, Michael Barton <michael.barton@asu.edu> wrote:

On Mar 1, 2008, at 1:47 AM, Martin Landa wrote:

> Micheal,
>
> 2008/3/1, Michael Barton <michael.barton@asu.edu>:
>>> 2008/2/29, Dylan Beaudette <dylan.beaudette@gmail.com>:
>>> [snip]
>>>> Thanks for the update. I don't regularly use either of the GUI and
>>>> did
>>>> not know about this feature. Does the patch that I submitted
>>>> interfere
>>>> with this functionality? I think that it would be useful to have
>>>> this
>>>> functionality in the old style monitors as well.
>>>
>>> d.measure is not used in wxGUI. Display windows are not
>>> registered as
>>> GRASS displays (d.mon -L) [TODO, not sure how to implemented], I
>>> think
>>> it would be good to use d.measure or something like g.measure in
>>> wxGUI
>>> too instead of using Python-based function for distance calculation
>>> (at least it would make sense for LL projections)? Please correct me
>>> if I am wrong.
>>
> Michael,
>> What's wrong with the Python one?
>
> duplication of the code, and in this particular case ignoring geodetic
> distance for LL projections.

Well, my understanding of the direction of GRASS is that by v7, we'll
lose all the interactive xterm-specific d.* modules. Interactive use
will all be shifted to whatever GUI we design, rather than being hard-
coded into a module. Simple, interactive measurement between 2 points
on a display screen seems to me something to be handled by a GUI.

I agree completely-- despite the fact that I prefer the d.* commands
for now, an integrated approach would be nice. That said, it would be
nice to retain something like the current d.* commands. Nothing is
faster when working with a couple raster/vector files.

d.measure will go away OR change to a module in which you enter a
start and end point and it returns the distance between the points.
In the latter case, it could then be 'plugged into' a GUI as a
function to calculate distance between points interactively 'grabbed'
by the GUI.

Sure. Until then it would be nice to have something that works, and
provides some missing functionality.

Ignoring geodetic distance for LL projections is simply ignorance (on
my part here) of the equations needed to do it. It's easy to
determine if a location is LL. In that case, it should calculate
geodetic distance rather than (or perhaps in addition to) displaying
distance in map units. Just need to have the functions to do this
added to the measurement methods.

Michael

I see quite a bit of disconnect between the GUI development and core
GRASS development (I am not helping this either). It would be a good
idea to spend some careful thought, with lots of input from everyone
involved to nail down the general plan for GRASS 7. I can see a lot of
potential for hurt feelings (= lost developers) if a slow and methodic
approach is not taken.

Cheers,

Dylan

6

On Mar 3, 2008, at 8:53 AM, Dylan Beaudette wrote:

I see quite a bit of disconnect between the GUI development and core
GRASS development (I am not helping this either). It would be a good
idea to spend some careful thought, with lots of input from everyone
involved to nail down the general plan for GRASS 7. I can see a lot of
potential for hurt feelings (= lost developers) if a slow and methodic
approach is not taken.

Cheers,

Dylan

Actually, I don't think that there is that much of a disconnect. There is a lot of communication between the folks writing a lot of the C-code and those of us working on the GUI. I think we're all lurching along in more or less the same general direction. But it's a very big and very complicated project and coordination can always be improved. Regular discussions about new display architecture and the move away from C-modules with hard-coded interactivity limited to an aging xmon interface have been going on for nearly 2 years.

The whole impetus for the current TclTk GUI was to demonstrate that we could have an interactive display architecture that did not need to rely on interactive d.* modules in which it was hard-coded--and to provide an environment which could encourage C programmers to expand modules to work better with this approach. This has been largely successful especially because of good coordination between GUI development and core C-module development. The current Windows native version of GRASS would not have been possible without this work.

The move toward Python as a scripting platform seems very exciting for GUI development, but even more so for expanded core functionality. After working with it for a year and a half, I'm sold. We are slowly beginning to switch our scripting in my lab from bash to Python--with much better and easier to read and maintain code. The python GUI also has opened a lot of new possibilities that I think many will benefit from (e.g., the new attribute data management modules).

We need to keep talking about this and issues like 'where' to put different functions in the new architecture. Sometimes it's clear, but other times it's fuzzy. I hope I haven't hurt anyone's feelings. Mine are OK.

Michael

7

Martin Landa wrote:

> >> Ignoring geodetic distance for LL projections is simply ignorance
> >> (on
> >> my part here) of the equations needed to do it. It's easy to
> >> determine if a location is LL. In that case, it should calculate
> >> geodetic distance rather than (or perhaps in addition to) displaying
> >> distance in map units. Just need to have the functions to do this
> >> added to the measurement methods.
> >
> > why to code it in Python when it is already available in gislib? We
> > should avoid code duplication.
>
>
> Certainly. If a new version of d.measure or a hypothetical g.measure
> could be created, we could use that. Until that happens, we'll need
> to do it in Python (which is not all that bad). Is there anyway to
> access gislib directly from Python? This could be an alternative to
> creating a new module or changing an existing one.

yes, via SWIG interface, see ./swig/python. Anyway the SWIG-Python
interface for GRASS is a bit limited, need to be improved.

The GUI should avoid using the GRASS libraries.

One reason is that anything which calls G_fatal_error() will end up
terminating the GUI (even if you add a handler to recover, you can't
safely use library functions afterwards). Similarly, any segfault or
abort() will kill the entire GUI.

Another reason is that the libraries maintain a lot of state, much of
which is initialised upon first use and cannot be reset easily (or at
all) thereafter. This creates problems for changing the current
location/mapset or even the current region.

For components such as the digitiser, not using the libraries isn't
really an option. Such components should be run as distinct processes,
rather than being "import"ed into the GUI process. That way, a fatal
error will only the digitiser (etc).

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