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.
Once this is done, I think I could maybe implement a module d.path.obstacles with 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?
Tanks,
Maximilian
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
On 4/27/07, Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:
[...]
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.
Another way to look at it, if you feel adventurous, Maximilian: once
you have your base library and your GRASS-wrapped functions, create a
SWIG binding to the latter (ot both) then code the GUI in wxPython.
Your main GRASS module must be controllable exclusively by
command-line switches anyway. So I agree with Paul, leave the GUI work
for later and first concentrate on solid algorithms and user interface
through CLI.
I agree with both Paul and Daniel. Make a vector command-line module
first. By using the GRASS parser, you will get an automatic GUI for
input selection. Visualization of the resultant vector can be done with
standard GRASS vector visualization. I believe that that will give you
more then enough GUI functionality. When this is done, we can then look
into more GUI functionality.
--Wolf
On 27.04.2007 23:59, Daniel Calvelo wrote:
On 4/27/07, Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:
[...]
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.
Another way to look at it, if you feel adventurous, Maximilian: once
you have your base library and your GRASS-wrapped functions, create a
SWIG binding to the latter (ot both) then code the GUI in wxPython.
Your main GRASS module must be controllable exclusively by
command-line switches anyway. So I agree with Paul, leave the GUI work
for later and first concentrate on solid algorithms and user interface
through CLI.