[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