Hi,
I used the d.path module in gis.m and found that the map I chose for calculating
the shortest path is not automatically displayed in the background. So I have a
white monitor where I can select my starting and end nodes to display a red
line.
Is this missing or how do I have to use the module correctly in gis.m to display
a vector map in the background? I used a grass cvs snapshot from today and tried
with spearfish roads map.
thanks a lot
Otto
On 30/01/07 08:37, Otto Dassau wrote:
Hi,
I used the d.path module in gis.m and found that the map I chose for calculating
the shortest path is not automatically displayed in the background. So I have a
white monitor where I can select my starting and end nodes to display a red
line.Is this missing or how do I have to use the module correctly in gis.m to display
a vector map in the background? I used a grass cvs snapshot from today and tried
with spearfish roads map.
d.path uses the old monitor system, not the new gis.m display, so when you launch it through the gis.m menu, an x-monitor opens (with something like Monitor: x0 written in the title bar). You can display whatever you want in this monitor by using the command line, e.g.:
d.vect roads
Moritz
Hi Moritz,
On Tue, 30 Jan 2007 10:03:10 +0100
Moritz Lennert <mlennert@club.worldonline.be> wrote:
On 30/01/07 08:37, Otto Dassau wrote:
> Hi,
>
> I used the d.path module in gis.m and found that the map I chose for
calculating
> the shortest path is not automatically displayed in the background. So I
have a
> white monitor where I can select my starting and end nodes to display a red
> line.
>
> Is this missing or how do I have to use the module correctly in gis.m to
display
> a vector map in the background? I used a grass cvs snapshot from today and
tried
> with spearfish roads map.
d.path uses the old monitor system, not the new gis.m display, so when
you launch it through the gis.m menu, an x-monitor opens (with something
like Monitor: x0 written in the title bar). You can display whatever you
want in this monitor by using the command line, e.g.:d.vect roads
thanks for your help,
yes I saw that, but I think that it might be more intuitive for a user to
have the selected map for d.path visualized directly in the new x-monitor, when
when you click on start.
I mean, it is not an error, and of course one can easily type a d.vect roads
command or whatever, but I found it strange that klicking on start you get an
empty x-monitor and a usage desription for the mouse buttons in the Output
monitor, but the map you selected in the d.path popup is not automatically
displayed.
Maybe it is just my impression, so for me there is simply sth. missing. Could
that not be added or is this difficult or not wanted?
maybe I should add a wish to the bugtracker... but I wanted to ask, if there is
a special reason, why the selected map isn't displayed in the new x-monitor.
regards,
otto
Moritz
--
On 30/01/07 10:43, Otto Dassau wrote:
Hi Moritz,
On Tue, 30 Jan 2007 10:03:10 +0100
Moritz Lennert <mlennert@club.worldonline.be> wrote:On 30/01/07 08:37, Otto Dassau wrote:
Hi,
I used the d.path module in gis.m and found that the map I chose for
calculating
the shortest path is not automatically displayed in the background. So I
have a
white monitor where I can select my starting and end nodes to display a red
line.Is this missing or how do I have to use the module correctly in gis.m to
display
a vector map in the background? I used a grass cvs snapshot from today and
tried
with spearfish roads map.
d.path uses the old monitor system, not the new gis.m display, so when you launch it through the gis.m menu, an x-monitor opens (with something like Monitor: x0 written in the title bar). You can display whatever you want in this monitor by using the command line, e.g.:
d.vect roads
thanks for your help,
yes I saw that, but I think that it might be more intuitive for a user to
have the selected map for d.path visualized directly in the new x-monitor, when
when you click on start.I mean, it is not an error, and of course one can easily type a d.vect roads
command or whatever, but I found it strange that klicking on start you get an
empty x-monitor and a usage desription for the mouse buttons in the Output
monitor, but the map you selected in the d.path popup is not automatically
displayed.Maybe it is just my impression, so for me there is simply sth. missing. Could
that not be added or is this difficult or not wanted?maybe I should add a wish to the bugtracker... but I wanted to ask, if there is
a special reason, why the selected map isn't displayed in the new x-monitor.
You are right that this is currently a bit counter-intuitive. The problem is that d.path was developed for the old monitoring system, where you would display your maps and then run d.path on them. Now that users use gis.m, and display their maps in the gis.m display, this obviously causes a problem. This said the man page actually states: " The user needs to display a vector map before using d.path."
d.path could be rewritten to display the chosen vector map automatically, but there might be situations where you don't want this map to be in the background, so imposing this might not be a good idea either...
In any case, I don't think we should invest any more development time into modules which depend on the x-monitors, so in my eyes the best solution would be to start from the non-interactive v.net.path and possibly write an interactive GUI wrapper around it which would allow you to click on start and end points and would then create a temporary vector file for display which it either discards afterwards or saves it to a given filename. I don't think this would be too complicated, maybe something for a python-programmer to try for the wxpython gui.
Moritz
On Tue, 30 Jan 2007 11:19:18 +0100
Moritz Lennert <mlennert@club.worldonline.be> wrote:
On 30/01/07 10:43, Otto Dassau wrote:
> Hi Moritz,
>
> On Tue, 30 Jan 2007 10:03:10 +0100
> Moritz Lennert <mlennert@club.worldonline.be> wrote:
>
>> On 30/01/07 08:37, Otto Dassau wrote:
>>> Hi,
>>>
>>> I used the d.path module in gis.m and found that the map I chose for
> calculating
>>> the shortest path is not automatically displayed in the background. So I
> have a
>>> white monitor where I can select my starting and end nodes to display a
red
>>> line.
>>>
>>> Is this missing or how do I have to use the module correctly in gis.m to
> display
>>> a vector map in the background? I used a grass cvs snapshot from today and
> tried
>>> with spearfish roads map.
>>
>> d.path uses the old monitor system, not the new gis.m display, so when
>> you launch it through the gis.m menu, an x-monitor opens (with something
>> like Monitor: x0 written in the title bar). You can display whatever you
>> want in this monitor by using the command line, e.g.:
>>
>> d.vect roads
>
> thanks for your help,
>
> yes I saw that, but I think that it might be more intuitive for a user to
> have the selected map for d.path visualized directly in the new x-monitor,
when
> when you click on start.
>
> I mean, it is not an error, and of course one can easily type a d.vect roads
> command or whatever, but I found it strange that klicking on start you get
an
> empty x-monitor and a usage desription for the mouse buttons in the Output
> monitor, but the map you selected in the d.path popup is not automatically
> displayed.
>
> Maybe it is just my impression, so for me there is simply sth. missing.
Could
> that not be added or is this difficult or not wanted?
>
> maybe I should add a wish to the bugtracker... but I wanted to ask, if there
is
> a special reason, why the selected map isn't displayed in the new x-monitor.
You are right that this is currently a bit counter-intuitive. The
problem is that d.path was developed for the old monitoring system,
where you would display your maps and then run d.path on them. Now that
users use gis.m, and display their maps in the gis.m display, this
obviously causes a problem. This said the man page actually states: "
The user needs to display a vector map before using d.path."d.path could be rewritten to display the chosen vector map
automatically, but there might be situations where you don't want this
map to be in the background, so imposing this might not be a good idea
either...In any case, I don't think we should invest any more development time
into modules which depend on the x-monitors, so in my eyes the best
solution would be to start from the non-interactive v.net.path and
possibly write an interactive GUI wrapper around it which would allow
you to click on start and end points and would then create a temporary
vector file for display which it either discards afterwards or saves it
to a given filename. I don't think this would be too complicated, maybe
something for a python-programmer to try for the wxpython gui.
ok, now I understand and I totally agree.
thanks for the info, Moritz!
regards,
Otto
Moritz
Otto Dassau wrote:
> > I used the d.path module in gis.m and found that the map I chose for calculating
> > the shortest path is not automatically displayed in the background. So I have a
> > white monitor where I can select my starting and end nodes to display a red
> > line.
> >
> > Is this missing or how do I have to use the module correctly in gis.m to display
> > a vector map in the background? I used a grass cvs snapshot from today and tried
> > with spearfish roads map.
>
>
> d.path uses the old monitor system, not the new gis.m display, so when
> you launch it through the gis.m menu, an x-monitor opens (with something
> like Monitor: x0 written in the title bar). You can display whatever you
> want in this monitor by using the command line, e.g.:
>
> d.vect roadsthanks for your help,
yes I saw that, but I think that it might be more intuitive for a user to
have the selected map for d.path visualized directly in the new x-monitor, when
when you click on start.I mean, it is not an error, and of course one can easily type a d.vect roads
command or whatever, but I found it strange that klicking on start you get an
empty x-monitor and a usage desription for the mouse buttons in the Output
monitor, but the map you selected in the d.path popup is not automatically
displayed.Maybe it is just my impression, so for me there is simply sth. missing. Could
that not be added or is this difficult or not wanted?maybe I should add a wish to the bugtracker... but I wanted to ask, if there is
a special reason, why the selected map isn't displayed in the new x-monitor.
No reason; it's just the result of creating a menu tree for >300
commands without having the time to consider each one individually.
It wouldn't be particularly hard to write a script which accepts
exactly the same arguments as d.path, and which runs d.vect followed
by d.path.
Hmm; it might be useful to have some means of automatically generating
the corresponding g.parser description for a given command. There are
probably quite a few scripts whose options are (almost) identical to
an existing command. I'll look into it.
--
Glynn Clements <glynn@gclements.plus.com>
Hi Otto,
I just took a look at d.path. There is no place in the module to select a
background map, though you can select a background color.
d.path [-g] map=name [type=string[,string,...]] [alayer=value]
[nlayer=value] [afcol=string] [abcol=string] [ncol=string]
[color=string] [hcolor=string] [bgcolor=string] [--verbose] [--quiet]
D.path is one of the older display modules that requires an xterm to run.
For this reason, it won't work in the new display system that does not use
an old xterm. To get complete d.path functionality in the new display
system, it needs to be re-written. To keep it available for people, we've
got the menu set to launch the xterm it needs to run. But there is no way to
specify a background map in the module.
To get a background map, you'll need to use GRASS with an xterm the old way.
D.mon start=x0
D.rast map=[raster map]
D.vect map=[vector map]
D.path map=[vector map]
Note, that all of these modules, if launched from the command line, will
create a TclTk dialog that can help you with their multiple options.
Hope this helps.
Michael
On 1/30/07 2:43 AM, "Otto Dassau" <otto.dassau@gmx.de> wrote:
thanks for your help,
yes I saw that, but I think that it might be more intuitive for a user to
have the selected map for d.path visualized directly in the new x-monitor,
when
when you click on start.I mean, it is not an error, and of course one can easily type a d.vect roads
command or whatever, but I found it strange that klicking on start you get an
empty x-monitor and a usage desription for the mouse buttons in the Output
monitor, but the map you selected in the d.path popup is not automatically
displayed.Maybe it is just my impression, so for me there is simply sth. missing. Could
that not be added or is this difficult or not wanted?maybe I should add a wish to the bugtracker... but I wanted to ask, if there
is
a special reason, why the selected map isn't displayed in the new x-monitor.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Glynn Clements wrote:
Hmm; it might be useful to have some means of automatically generating
the corresponding g.parser description for a given command. There are
probably quite a few scripts whose options are (almost) identical to
an existing command. I'll look into it.
I've extended G_parser() with a --script flag, which writes out a
script with g.parser syntax to mimic the behaviour of the module. This
shoud make it easier to write scripts which mimic an existing command.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote on 01/30/2007 11:04 PM:
Glynn Clements wrote:
Hmm; it might be useful to have some means of automatically generating
the corresponding g.parser description for a given command. There are
probably quite a few scripts whose options are (almost) identical to
an existing command. I'll look into it.
I've extended G_parser() with a --script flag, which writes out a
script with g.parser syntax to mimic the behaviour of the module. This
shoud make it easier to write scripts which mimic an existing command.
Really cool! Thanks, Glynn.
Markus
Glynn,
Could you explain how this works a bit more? It sounds cool, but I don't
quite understand how it might be used.
Michael
On 1/31/07 6:10 AM, "Markus Neteler" <neteler@itc.it> wrote:
Glynn Clements wrote on 01/30/2007 11:04 PM:
Glynn Clements wrote:
Hmm; it might be useful to have some means of automatically generating
the corresponding g.parser description for a given command. There are
probably quite a few scripts whose options are (almost) identical to
an existing command. I'll look into it.
I've extended G_parser() with a --script flag, which writes out a
script with g.parser syntax to mimic the behaviour of the module. This
shoud make it easier to write scripts which mimic an existing command.
Really cool! Thanks, Glynn.
Markus
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote:
>>> Hmm; it might be useful to have some means of automatically generating
>>> the corresponding g.parser description for a given command. There are
>>> probably quite a few scripts whose options are (almost) identical to
>>> an existing command. I'll look into it.
>>>
>>
>> I've extended G_parser() with a --script flag, which writes out a
>> script with g.parser syntax to mimic the behaviour of the module. This
>> shoud make it easier to write scripts which mimic an existing command.
>>
> Really cool! Thanks, Glynn.Could you explain how this works a bit more? It sounds cool, but I don't
quite understand how it might be used.
Taking d.path as an example, you would first run e.g.:
d.path --script > d.path.sh
This will generate a script which contains the g.parser boilerplate
which would be required for a script with the same set of options as
d.path.
To this script, you would append something like the following:
cmd=d.path
if [ "$GIS_FLAG_G" != 0 ] ; then cmd="$cmd -g" ; fi
if [ "$GIS_OPT_MAP" != "" ] ; then cmd="$cmd map=$GIS_OPT_MAP" ; fi
if [ "$GIS_OPT_TYPE" != "" ] ; then cmd="$cmd type=$GIS_OPT_TYPE" ; fi
if [ "$GIS_OPT_ALAYER" != "" ] ; then cmd="$cmd alayer=$GIS_OPT_ALAYER" ; fi
if [ "$GIS_OPT_NLAYER" != "" ] ; then cmd="$cmd nlayer=$GIS_OPT_NLAYER" ; fi
if [ "$GIS_OPT_AFCOL" != "" ] ; then cmd="$cmd afcol=$GIS_OPT_AFCOL" ; fi
if [ "$GIS_OPT_ABCOL" != "" ] ; then cmd="$cmd abcol=$GIS_OPT_ABCOL" ; fi
if [ "$GIS_OPT_NCOL" != "" ] ; then cmd="$cmd ncol=$GIS_OPT_NCOL" ; fi
if [ "$GIS_OPT_COLOR" != "" ] ; then cmd="$cmd color=$GIS_OPT_COLOR" ; fi
if [ "$GIS_OPT_HCOLOR" != "" ] ; then cmd="$cmd hcolor=$GIS_OPT_HCOLOR" ; fi
if [ "$GIS_OPT_BGCOLOR" != "" ] ; then cmd="$cmd bgcolor=$GIS_OPT_BGCOLOR" ; fi
d.vect "$GIS_OPT_MAP"
exec $cmd
This script should run "d.vect <map>", then run d.path with whatever
options were passed to the d.path.sh script.
Essentially, if you want to write a script which behaves like some
existing command, the --script option can be used to avoid having to
type out the g.parser boilerplate by hand.
--
Glynn Clements <glynn@gclements.plus.com>
Thanks for the explanation.
Michael
On 2/1/07 11:08 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
Hmm; it might be useful to have some means of automatically generating
the corresponding g.parser description for a given command. There are
probably quite a few scripts whose options are (almost) identical to
an existing command. I'll look into it.
I've extended G_parser() with a --script flag, which writes out a
script with g.parser syntax to mimic the behaviour of the module. This
shoud make it easier to write scripts which mimic an existing command.
Really cool! Thanks, Glynn.
Could you explain how this works a bit more? It sounds cool, but I don't
quite understand how it might be used.Taking d.path as an example, you would first run e.g.:
d.path --script > d.path.sh
This will generate a script which contains the g.parser boilerplate
which would be required for a script with the same set of options as
d.path.To this script, you would append something like the following:
cmd=d.path
if [ "$GIS_FLAG_G" != 0 ] ; then cmd="$cmd -g" ; fi
if [ "$GIS_OPT_MAP" != "" ] ; then cmd="$cmd map=$GIS_OPT_MAP" ; fi
if [ "$GIS_OPT_TYPE" != "" ] ; then cmd="$cmd type=$GIS_OPT_TYPE" ; fi
if [ "$GIS_OPT_ALAYER" != "" ] ; then cmd="$cmd alayer=$GIS_OPT_ALAYER" ; fi
if [ "$GIS_OPT_NLAYER" != "" ] ; then cmd="$cmd nlayer=$GIS_OPT_NLAYER" ; fi
if [ "$GIS_OPT_AFCOL" != "" ] ; then cmd="$cmd afcol=$GIS_OPT_AFCOL" ; fi
if [ "$GIS_OPT_ABCOL" != "" ] ; then cmd="$cmd abcol=$GIS_OPT_ABCOL" ; fi
if [ "$GIS_OPT_NCOL" != "" ] ; then cmd="$cmd ncol=$GIS_OPT_NCOL" ; fi
if [ "$GIS_OPT_COLOR" != "" ] ; then cmd="$cmd color=$GIS_OPT_COLOR" ; fi
if [ "$GIS_OPT_HCOLOR" != "" ] ; then cmd="$cmd hcolor=$GIS_OPT_HCOLOR" ; fi
if [ "$GIS_OPT_BGCOLOR" != "" ] ; then cmd="$cmd bgcolor=$GIS_OPT_BGCOLOR" ;
fi
d.vect "$GIS_OPT_MAP"
exec $cmdThis script should run "d.vect <map>", then run d.path with whatever
options were passed to the d.path.sh script.Essentially, if you want to write a script which behaves like some
existing command, the --script option can be used to avoid having to
type out the g.parser boilerplate by hand.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton