[GRASS-dev] v.path.obstacles

[maximilian maldacker]

>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20070808/e7901839/attachment.html