[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

Martin Landa wrote:

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)?

Yes, we should use existing library functions whenever possible, in
this case those found in lib/gis/distance.c and lib/gis/geodist.c.

call it m.distance; I know g.* semi-officially stands for "general" but
if you look at the other g.* modules you will see that it could just as
well stand for "GIS management". From a non-interactive standpoint
"measure" doesn't make as much sense to me.

It would be very easy to write in C but from a learning exercise
perspective it seems like a perfect thing to try doing with
SWIG+Python, and perhaps too simple a thing to have as a generic
module??

Hamish

      ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

2

On Mar 2, 2008, at 6:15 PM, Helena Mitasova wrote:

This reminds me - was the patch below submitted to SVN?
Do we have a procedure (dedicated person) for keeping
track of patches submitted through track
and making sure they get submitted if appropriate?

This angle is also needed to derive pre-defined flow (e.g.
ditches or pipes that are not in the DEM) as inputs into simwe -
I used m.cogo for that but d.measure is much more convenient.

Thanks for adding it,

I just tried to check out any updates to d.measure and found that it doesn't run on my Mac. It produces a bus error. I don't need it, but folks should be aware of this.

Michael

3

On Sunday 02 March 2008, Michael Barton wrote:

On Mar 2, 2008, at 6:15 PM, Helena Mitasova wrote:
> This reminds me - was the patch below submitted to SVN?
> Do we have a procedure (dedicated person) for keeping
> track of patches submitted through track
> and making sure they get submitted if appropriate?
>
> This angle is also needed to derive pre-defined flow (e.g.
> ditches or pipes that are not in the DEM) as inputs into simwe -
> I used m.cogo for that but d.measure is much more convenient.
>
> Thanks for adding it,

I just tried to check out any updates to d.measure and found that it
doesn't run on my Mac. It produces a bus error. I don't need it, but
folks should be aware of this.

Michael

I do not have access to a Mac, but the module seems to compile and run fine on
Linux x86.

Could it be the call to atan2() -- perhaps the math library is not accessed
the same way on Mac OS X ?

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

4

On Mar 2, 2008, at 7:40 PM, Dylan Beaudette wrote:

On Sunday 02 March 2008, Michael Barton wrote:

On Mar 2, 2008, at 6:15 PM, Helena Mitasova wrote:

This reminds me - was the patch below submitted to SVN?
Do we have a procedure (dedicated person) for keeping
track of patches submitted through track
and making sure they get submitted if appropriate?

This angle is also needed to derive pre-defined flow (e.g.
ditches or pipes that are not in the DEM) as inputs into simwe -
I used m.cogo for that but d.measure is much more convenient.

Thanks for adding it,

I just tried to check out any updates to d.measure and found that it
doesn't run on my Mac. It produces a bus error. I don't need it, but
folks should be aware of this.

Michael

I do not have access to a Mac, but the module seems to compile and run fine on
Linux x86.

Could it be the call to atan2() -- perhaps the math library is not accessed
the same way on Mac OS X ?

I don't know. It compiled fine. Just won't run.

Michael

5

On Sunday 02 March 2008 08:18:05 pm Michael Barton wrote:

On Mar 2, 2008, at 7:40 PM, Dylan Beaudette wrote:
> On Sunday 02 March 2008, Michael Barton wrote:
>> On Mar 2, 2008, at 6:15 PM, Helena Mitasova wrote:
>>> This reminds me - was the patch below submitted to SVN?
>>> Do we have a procedure (dedicated person) for keeping
>>> track of patches submitted through track
>>> and making sure they get submitted if appropriate?
>>>
>>> This angle is also needed to derive pre-defined flow (e.g.
>>> ditches or pipes that are not in the DEM) as inputs into simwe -
>>> I used m.cogo for that but d.measure is much more convenient.
>>>
>>> Thanks for adding it,
>>
>> I just tried to check out any updates to d.measure and found that it
>> doesn't run on my Mac. It produces a bus error. I don't need it, but
>> folks should be aware of this.
>>
>> Michael
>
> I do not have access to a Mac, but the module seems to compile and
> run fine on
> Linux x86.
>
> Could it be the call to atan2() -- perhaps the math library is not
> accessed
> the same way on Mac OS X ?

I don't know. It compiled fine. Just won't run.

Michael

What happens if you replace the atan2() function call with something simpler,
like a simple addition (obviously resulting bogus values).

Just an idea

Dylan

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

6

Helena wrote:

> This reminds me - was the patch below submitted to SVN?

Not yet. AFAICT Dylan has SVN permissions for grass-addons/ but not the
main source tree?

I haven't checked: does the patch "do the right thing" for lat/lon
locations yet? It needs to do that first. FWIW, I haven't looked at the
patch yet but the feature seems useful.

> Do we have a procedure (dedicated person) for keeping
> track of patches submitted through track
> and making sure they get submitted if appropriate?

Interested devels should claim ownership of the bug in the tracker.
As long as it is in the tracker it won't get too lost or forgotten.

Otherwise they sit there until someone takes an interest, which may not
be an entirely bad thing as commiters are obliged to take primary
responsibility for code they check in. Every new part of the code needs
a champion to look after it otherwise bugs go unfixed and there is no
check on bloat.

Michael:

I just tried to check out any updates to d.measure and found that it
doesn't run on my Mac. It produces a bus error. I don't need it, but
folks should be aware of this.

The code hasn't changed in 10 months*. So perhaps something else is
wrong like a build problem? If it persists can you debug it?

[*] http://trac.osgeo.org/grass/browser/grass/trunk/display/d.measure

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

7

Michael:

> I just tried to check out any updates to d.measure and found that
> it doesn't run on my Mac. It produces a bus error. I don't need
> it, but folks should be aware of this.

Hamish:

the code for it hasn't changed in 10 months

Dylan:

I do not have access to a Mac, but the module seems to compile and
run fine on Linux x86.

Could it be the call to atan2() -- perhaps the math library is not
accessed the same way on Mac OS X ?

I have just tested here using William's 6.3 binaries from a few weeks
ago and I too get a Bus error when trying to start d.measure. (Minimac
+ OSX 10.4)

gdb is not installed on the lab Macs and I'm not sure how to set things
to have it produce a core dump to the terminal upon errors.

g.gisenv set="DEBUG=5" doesn't give any additional output.

one thing I forgot to try was a simple 'd.measure --help'

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

8

Michael:
> > I just tried to check out any updates to d.measure and found that
> > it doesn't run on my Mac. It produces a bus error. I don't need
> > it, but folks should be aware of this.

Dylan:
> I do not have access to a Mac, but the module seems to compile and
> run fine on Linux x86.
>
> Could it be the call to atan2() -- perhaps the math library is not
> accessed the same way on Mac OS X ?

Hamish:

I have just tested here using William's 6.3 binaries from a few weeks
ago and I too get a Bus error when trying to start d.measure.

i.e. it's got nothing to do with the bearing patch.

Hamish

      ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

9

Martin Landa wrote:
> 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)?

Hamish wrote:

Yes, we should use existing library functions whenever possible, in
this case those found in lib/gis/distance.c and lib/gis/geodist.c.
call it m.distance;

...

It would be very easy to write in C but from a learning exercise
perspective it seems like a perfect thing to try doing with
SWIG+Python, and perhaps too simple a thing to have as a generic
module??

Python-SWIG m.distance (working) prototype:
  http://grass.gdf-hannover.de/wiki/PythonSwigExamples

Starting from the shell it takes about 0.5 sec to run. ie very slow.
But that includes the overhead of starting #!/usr/bin/python and
importing the required modules. If the same code was called from an
already running python session with all that stuff already loaded, I
expect it would be highly fast. (FWIW unstripped libgis.so is ~900kb,
_python_grass6.so ~1.7mb)

G_area_of_polygon() needs x and y vertices passed to it as memory
address pointers to two double-FP arrays. I really don't know much
about SWIG but a web search turned up a Python module called NumPtr
(Numeric Pointer) for doing that. It seems pretty simple. Instructions
for it are on the wiki link above.

If there isn't already a built-in easier way that I missed, perhaps we
could add that code as a contrib in our swig/python/ dir? It is GPL2,
less than 100kb, and several years without a new version. Hopefully the
lack of upstream activity means that it is mature, and not abandoned.
It is a simple enough thing that it wouldn't surprise me if it was
mature. And because it is so simple and small it seems more trouble
than it would be worth to insist that it be an external dependency, or
a be a significant burden to maintain.

To build the SWIG-Python interface I had to hack the Makefile a little.

I also had to install the "swig" package on my machine to get
/usr/bin/swig, as compiling failed when it couldn't find it. Maybe add
a check for that program in the main './configure --with-python'? (for
one thing it would give --with-python something useful to do which
currently AFAIK it doesn't?)

# the Makefile problem:
cd swig/python/
make

In file included from
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/vect/digit.h:3,
                 from
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/Vect.h:4,
                 from python_grass6_wrap.c:2933:
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/vect/dig_structs.h:22:21:
error: ogr_api.h: No such file or directory
....

local solution:
edit swig/python/Makefile and add -I/usr/include/gdal to CFLAGS.

not sure what the correct fix in swig/python/Makefile.in for that would
be or if the error is really in the vector includes.

Should 'make clean' remove the Makefile or should that only happen with
'make distclean'?

see also my notes on an earlier attempt at building swig/python/:
  http://thread.gmane.org/gmane.comp.gis.grass.devel/20751

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

10

On Mar 3, 2008, at 1:06 AM, Hamish wrote:

Michael:

I just tried to check out any updates to d.measure and found that
it doesn't run on my Mac. It produces a bus error. I don't need
it, but folks should be aware of this.

Dylan:

I do not have access to a Mac, but the module seems to compile and
run fine on Linux x86.

Could it be the call to atan2() -- perhaps the math library is not
accessed the same way on Mac OS X ?

Hamish:

I have just tested here using William's 6.3 binaries from a few weeks
ago and I too get a Bus error when trying to start d.measure.

i.e. it's got nothing to do with the bearing patch.

Hamish

While I use the command line from time to time, I don't use xmons for interactive displays. So this bug could have been there for quite awhile.

Michael

11

On Mar 3, 2008, at 2:30 AM, Hamish wrote:

Martin Landa wrote:

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)?

Hamish wrote:

Yes, we should use existing library functions whenever possible, in
this case those found in lib/gis/distance.c and lib/gis/geodist.c.
call it m.distance;

...

It would be very easy to write in C but from a learning exercise
perspective it seems like a perfect thing to try doing with
SWIG+Python, and perhaps too simple a thing to have as a generic
module??

Python-SWIG m.distance (working) prototype:
http://grass.gdf-hannover.de/wiki/PythonSwigExamples

Starting from the shell it takes about 0.5 sec to run. ie very slow.
But that includes the overhead of starting #!/usr/bin/python and
importing the required modules. If the same code was called from an
already running python session with all that stuff already loaded, I
expect it would be highly fast. (FWIW unstripped libgis.so is ~900kb,
_python_grass6.so ~1.7mb)

G_area_of_polygon() needs x and y vertices passed to it as memory
address pointers to two double-FP arrays. I really don't know much
about SWIG but a web search turned up a Python module called NumPtr
(Numeric Pointer) for doing that. It seems pretty simple. Instructions
for it are on the wiki link above.

If there isn't already a built-in easier way that I missed, perhaps we
could add that code as a contrib in our swig/python/ dir? It is GPL2,
less than 100kb, and several years without a new version. Hopefully the
lack of upstream activity means that it is mature, and not abandoned.
It is a simple enough thing that it wouldn't surprise me if it was
mature. And because it is so simple and small it seems more trouble
than it would be worth to insist that it be an external dependency, or
a be a significant burden to maintain.

To build the SWIG-Python interface I had to hack the Makefile a little.

I also had to install the "swig" package on my machine to get
/usr/bin/swig, as compiling failed when it couldn't find it. Maybe add
a check for that program in the main './configure --with-python'? (for
one thing it would give --with-python something useful to do which
currently AFAIK it doesn't?)

# the Makefile problem:
cd swig/python/
make

In file included from
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/vect/digit.h:3,
                from
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/Vect.h:4,
                from python_grass6_wrap.c:2933:
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/vect/dig_structs.h:22:21:
error: ogr_api.h: No such file or directory
....

local solution:
edit swig/python/Makefile and add -I/usr/include/gdal to CFLAGS.

not sure what the correct fix in swig/python/Makefile.in for that would
be or if the error is really in the vector includes.

Should 'make clean' remove the Makefile or should that only happen with
'make distclean'?

see also my notes on an earlier attempt at building swig/python/:
http://thread.gmane.org/gmane.comp.gis.grass.devel/20751

Hamish

Hamish,

Thanks for checking on this. I'll look at your example to see how it is done. In fact, we don't even need to create an independent module. The discussion was over how to implement measurement (and I suppose bearing if it's also supported) in the GUI, and Martin's point was 'why do these calculations in Python when the GRASS libraries can do them?' We should simply be able to incorporate the SWIG calls to the library in the wxPython GUI module. It already can grab xy points.

For a stand alone module--i.e., to be used in non-GUI circumstances too--your Python script could be an example of how to begin to replace bash with Python programming. SWIG would give us more options than we now have with bash.

Michael

12

On Sunday 02 March 2008, Hamish wrote:

Helena wrote:
> > This reminds me - was the patch below submitted to SVN?

Not yet. AFAICT Dylan has SVN permissions for grass-addons/ but not the
main source tree?

I don't think that I have write-access to any tree yet. At some point it would
be nice to setup (with approval from the others) those permissions.

I haven't checked: does the patch "do the right thing" for lat/lon
locations yet? It needs to do that first. FWIW, I haven't looked at the
patch yet but the feature seems useful.

Yes and tested, see:
http://trac.osgeo.org/grass/attachment/ticket/76/d.measure_bearing.patch

> > Do we have a procedure (dedicated person) for keeping
> > track of patches submitted through track
> > and making sure they get submitted if appropriate?

Interested devels should claim ownership of the bug in the tracker.
As long as it is in the tracker it won't get too lost or forgotten.

... It is in the tracker, so that is a start.

Cheers,

Dylan

Otherwise they sit there until someone takes an interest, which may not
be an entirely bad thing as commiters are obliged to take primary
responsibility for code they check in. Every new part of the code needs
a champion to look after it otherwise bugs go unfixed and there is no
check on bloat.

Michael:
> I just tried to check out any updates to d.measure and found that it
> doesn't run on my Mac. It produces a bus error. I don't need it, but
> folks should be aware of this.

The code hasn't changed in 10 months*. So perhaps something else is
wrong like a build problem? If it persists can you debug it?

[*] http://trac.osgeo.org/grass/browser/grass/trunk/display/d.measure

Hamish

___________________________________________________________________________
_________ Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

13

Michael:

Thanks for checking on this. I'll look at your example to see how it
is done.

new updated demo version at the wiki site:
  http://grass.gdf-hannover.de/wiki/PythonSwigExamples

and new full version in the source code:
  http://trac.osgeo.org/grass/browser/grass/trunk/swig/python/examples

Both versions now have fully functional g.parser support!* The full +
cleaned version in SVN has support for multi-segment input either given
from the command line coord= option or piped from stdin, and also
supports parsing DDD:MM:SS.SSSS formatted lat/lon coordinates.

Requires NumPy and NumPtr. As the NumPtr module seems very useful for
us, I will add it in SVN unless there are objections.

* having a slight issue testing for the existance of an enviro
variable, which means it can hang when reading nothing from stdin.
os.getenv() returns None if the variable doesn't exist. But g.parser
seems to create the variable anyway and set it equal to '' if it was
unset. So there is no way easy to test if(option->answer == NULL) from
the script AFAICT. sys.argv is already toast by then. (replaced after
g.parser call)

i.e. this doesn't work as expected:
opt_answer = os.getenv("GIS_OPT_COORD")
if opt_answer is not None:
   # read from command line option
else:
   # read from stdin

In fact, we don't even need to create an independent module.

Agreed, I do not expect to move the (full) module to be an official
module, I think it's too simple for that. It is just meant to be a
fully working example, or could be used as an addon if someone needed a
multi-segment geodesic distance/area calculator.

The discussion was over how to implement measurement (and I suppose
bearing if it's also supported) in the GUI, and Martin's point was
'why do these calculations in Python when the GRASS libraries can do
them?' We should simply be able to incorporate the SWIG calls to the
library in the wxPython GUI module. It already can grab xy points.

I suppose you could say "programming" is not banned in the GUI (e.g. wx
measurement or profile tool), but reimplementing complicated things
like great circle calculations in the GUI when well tested and faster C
versions already exist and are accessible via swig.

For general use we would have to make the decision to make swig a
mandatory dependency for the wxGUI. I think that opens more doors than
it closes, so support the idea.

For a stand alone module--i.e., to be used in non-GUI circumstances
too--your Python script could be an example of how to begin to
replace bash with Python programming. SWIG would give us more options
than we now have with bash.

exactly.

Hamish

      ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

14

On 04/03/08 00:40, Hamish wrote:

Agreed, I do not expect to move the (full) module to be an official
module, I think it's too simple for that. It is just meant to be a
fully working example, or could be used as an addon if someone needed a
multi-segment geodesic distance/area calculator.

[...]

I suppose you could say "programming" is not banned in the GUI (e.g. wx
measurement or profile tool), but reimplementing complicated things
like great circle calculations in the GUI when well tested and faster C
versions already exist and are accessible via swig.

For general use we would have to make the decision to make swig a
mandatory dependency for the wxGUI. I think that opens more doors than
it closes, so support the idea.

I'm not sure I fully agree with the above (and I think Dylan's right in saying that we might need a more explicit discussion of the issue). Besides issues concerning state which Glynn has mentioned often on this list (but obviously I cannot find a reference now) and which might make the direct use of GRASS function by the GUI a bit hazardous, there is a fundamental choice to be made between only using modules or programming directly with GRASS functions.

In my eyes the general rule should be that all functionality should be available via modules from the command line if in any way possible. The GUI should only provide additional help in things like determining coordinates through mouse click and some (very limited) gui-specific issues.

This means that for the specific issue at hand, i.e. d.measure with bearing, I strongly plead for adding the possibility of giving start / end coordinates as parameters to the module. This would then allow other uses beyond the wxgrass gui such as web apps, shell scripts, etc.

As I have mentioned before, I am afraid that slowly but surely the wxgrass gui will multiply functionality which is only available via the gui, but should, in my eyes, also be available from the command line. I'm thinking of things like profiling, measuring, etc.

Moritz

15

This means that for the specific issue at hand, i.e. d.measure with
bearing, I strongly plead for adding the possibility of giving start /
end coordinates as parameters to the module. This would then allow other
uses beyond the wxgrass gui such as web apps, shell scripts, etc.

As I have mentioned before, I am afraid that slowly but surely the
wxgrass gui will multiply functionality which is only available via the
gui, but should, in my eyes, also be available from the command line.
I'm thinking of things like profiling, measuring, etc.

Moritz

I agree; the ability to use and script modules on the command line is a
key feature that I rely on. GUI lock-in of certain features would really
be frustrating.

~ Eric.

16

On Mar 4, 2008, at 4:50 AM, Patton, Eric wrote:

This means that for the specific issue at hand, i.e. d.measure with
bearing, I strongly plead for adding the possibility of giving start /
end coordinates as parameters to the module. This would then allow other
uses beyond the wxgrass gui such as web apps, shell scripts, etc.

As I have mentioned before, I am afraid that slowly but surely the
wxgrass gui will multiply functionality which is only available via the
gui, but should, in my eyes, also be available from the command line.
I'm thinking of things like profiling, measuring, etc.

Moritz

I agree; the ability to use and script modules on the command line is a
key feature that I rely on. GUI lock-in of certain features would really
be frustrating.

~ Eric.

This is why we should have a non-interactive version of d.measure. We've been slowly getting non-interactive versions of key command modules over the past couple years. A command that returns the distance between two xy coordiates would be useful. As I said earlier, modifying d.measure (or as Hamish has suggested, creating a new m.measure) would be desirable.

FWIW, there are already 2 non-interactive profiling commands that can be used in scripts that have existed for a long time, r.transect and r.profile. The GUI (both TclTk and wxPython) simply display the results of running r.profile. As far as I am concerned, this is the ideal model: a GRASS command that can be used in scripting, also used in a GUI script to produce an interactive display.

The issue is not that we are losing functionality to a GUI. It is the difference between a command that returns a new map (or other file, such as a graphic image) or returns information, and a command that has a hard-coded interactive interface built in. When GRASS was first developed, there weren't any widely used, easy ways to control an interactive interface. So a suite of commands were developed in which interfaces were hard-coded into the modules. Because this was done, we are still dealing with 20-year-old interface design and it's headaches (e.d., i.orthophoto). I agree with Glynn that we are better off in terms of current and future flexibility to use a dedicated GUI scripting platform that sits on top of GRASS to create the interactive user interface and handle interactive displays. This is much easier to update as the technology changes (e.g., moving from TclTk to wxPython).

This does not mean getting rid of GRASS commands. It simply means that we need to take the hard-coded interactive interfaces out of GRASS commands so that you can type them on the command line and they run without further intervention on the part of the user. In fact, this makes them much easier to script (e.g., you can't script i.orthophoto or i.points). Tightly coupling command line tools and an interactive interface in the same module limits both ways of manipulating GIS data. There are simply some things you can do in a good GUI that you can't do with commands and vice versa. You can't drag a box to zoom a display on the command line--but you can enter extents into g.region and have the same computational result. For profiling, r.profile returns detailed information on the elevations between a series of xy points. This information can be viewed and manipulated in a variety of ways. You could drop it into a spreadsheet or gnuplot and plot it, for example. The GUI provides a visually appealing, interactive way to access this information. That is what it supposed to do, but doing this does not decrease the functionality or value of the underlying command that produced the information.

Michael

17

hi all,

i need to rectify an image automatically (i assume using i.points and
i.rectify). as far as i've been able to see, i.points is to use in graphical
monitor mode ? so does anyone know how to use it from the command line (and
only from the command line) ?

thanks for helping...

nicolas

18

Michael Barton wrote:

This is why we should have a non-interactive version of d.measure.
We've been slowly getting non-interactive versions of key command
modules over the past couple years. A command that returns the
distance between two xy coordiates would be useful. As I said
earlier, modifying d.measure (or as Hamish has suggested, creating
a new m.measure) would be desirable.

swig/python/examples/m.distance is written and fully functional.
(maybe a few slight glitches remain, I don't know- test it!)

Porting that to C, with bits from d.measure and r.profile would be a
trivial thing to do if there is demand for that. r.profile with a
dummy map and disregarding the '*' null data won't work as the res=
must approach 0 before the segment length becomes accurate. I'm not
sure if r.profile uses great circle distances or not, I assume it
would.

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ