[GRASS-dev] v.path.obstacles

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.

Yes I’ve added this functionality. You can add as many points as you want before computing the visibility graph and you can also add points after the graph has been computed and new edges for those points will be computed. But should those new points and edges be added to a copy of the already computed visibility graph or added directly to the computed visibility graph? For now the input is the original file, the vis the computed graph and output a copy of vis with the new points and edges. It doesn’t work yet as I get an error message when trying to write new points on the copy.

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?

I’ve tried using the other v.net.* modules on the generated graph and it works perfectly. So I guess I’ll write some examples in the description file. The shell script is a good idea, is there a way to use a script like this directly in the grass command line?

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.

Ok, no problem

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.

I’ll add that.

Thanks, Max