[GRASS-dev] Re: v.path.obstacles
Paul Kelly
paul-grass at stjohnspoint.co.uk
Thu Aug 2 06:26:44 EDT 2007
On Thu, 26 Jul 2007, Wolf Bergenheim wrote:
> v.path.obstacles:
> ~~~~~~~~~~~~~~~~~
> This module creates a visibility graph from non-intersecting lines and
> boundaries. It is actually remarkably fast. This output vector map can
> be used with graph analysis modules like v.net.path to find the shortest
> path between point A and B in free vector space. This project is in a
> testable shape. Not everything works perfectly yet, but Maximilian is
> actively working on it. We could use some feedback so if you are
> interested in this functionality, please try it out, and let us know
> what you think.
> Maximilian also brought up the issue that perhaps this module should be
> renamed to v.net.visibility. Any comments?
Hello Wolf and Maximilian,
As promised I have just had a chance to try this - I too am impressed by
how fast it ran - however, it seems to be lacking a facility for entering
the desired start and finish points that the shortest path should be found
between - as far as I can see these need to also be included in the
visiblity graph for it to work properly? I suppose you could manually add
them to the obstacles map before starting, but people might not want to
have to edit it. Hmmm I'm not sure.
Nice idea it seems actually keeping the visiblity graph generation out as
a separate module - I guess that is just the logical way the idea
developed in the end? And then you could write a shell script to run this
module (v.net.visiblity sounds like a logical name) to generate a
temporary map and then run other v.net.* modules on it to generate the
shortest path. Have you any ideas/scenarios for how you think it might
eventually be used like this?
A couple of comments on the code itself - I think it could do with being
compiled with -Wall being added to the EXTRA_CFLAGS to catch compiler
warnings, of which there are currently quite a lot. It seems to be the
general GRASS style to keep function prototypes for functions that are
not local to one file in a separate local_proto.h. Also the indentation,
in main.c anyway where I was reading, is quite inconsistent and makes it a
bit hard to read. There is a suggested set of commandline switches for the
"indent" command in the GRASS SUBMITTING file (top level directory in CVS)
- I'd suggest using this on the source files before they're committed to
CVS.
But in general, looks good and seems to be quite useful. I would suggest
the example in the man page should show how it can be used in combination
with one of the other v.net.* commands - this wasn't obvious to me at all
at the start.
Best regards
Paul
More information about the grass-dev
mailing list