[GRASS-dev] path.obstacles

[Paul Kelly]

Hello Maximilian

On Sun, 22 Apr 2007, maximilian maldacker wrote:

> Hello
> Thank you for your comments on my module proposition and taking your
> propositions in account I was thinking of develop ping the module the
> following way
>
> I will firstly create a library to create visibility graphs from a vector
> space containing obstacles ( polygons ). It will be completely independent
> of GRASS and I will put it in a subfolder of the folder v.path.obstacles. I
> will then create a second layer which will use GRASS vector library and
> directed graph library to construct the visibility graph ( using the
> abstract library ), this will be in several files in the v.path.obstacles.
> Then I will create a main file for the actual module which will be command
> based only with input a vector map and several points ( to compute several
> paths ) and output a vector map.

This sounds like a good plan for getting started anyway I think. The 
details aren't really clear at this stage but they don't need to be, and 
it sounds like it will work out OK. As I think Moritz suggested, I think 
you should include plenty of options for getting input points, e.g. on 
command-line, from standard input, from a vector map (select the points in 
it) to give flexibility in using the module.

> Once this is done, I think I could maybe implement a module
> d.path.obstacleswith a graphical interface similar to
> d.path. It will access the 2nd layer headers in the v.path.obstacles
> folder. Would that be the best way to do? Because otherwise I don't really
> see where to put it, except to add it in the directed graph library.
> So in fact I will create module in a structure similar to v.net.path and
> d.path ( a command line module only, and then a graphical interface ).
> Would that make everyone happy?

I think looking at d.path is the wrong way to go. We are moving away from 
the way modules like that interface with the display drivers directly, and 
more towards implementing interactive point-and-click display type stuff 
through a GUI. The idea being that the GUI detects where the user clicked, 
converts that into easting and northing and passes those co-ordinates 
directly to the command-line program (in this case v.path.obstacles) which 
it runs in the background and then displays the vector map output when 
finished, in another display. If you're not confident with GUI programming 
there are several other people working on it in GRASS now who could 
probably help with this. Have you explored gis.m much? As far as I know 
there are several places where it detects clicks on the Tk GUI canvas, 
converts those locations into eastings and northings and then runs an 
analysis with a command-line module. But I wouldn't worry about that too 
much at this stage - it can be added afterwards - much more important to 
get the command-line module working reliably and flexibly first.

Hope that gives you a few more ideas to think about

Paul