[GRASS-dev] Remaining shell scripts

Hamish · June 19, 2009, 9:19am

Glynn wrote:

The following is a list of remaining shell scripts (or files which
"file" thinks are shell scripts), not including those which are
clearly only used for building or testing:

gui/scripts/d.path.sh

wrapper script for d.path so that source vector network map (eg roads) is
drawn in background with d.vect.

d.path only draws the shortest path + start/end points. Not sure how
the wx GUI deals with this-- d.path /was/ an interactive xmon module
but I added a coor= option so now it will run non-interactively if you
specify the start/end coords from the command line. The GUI should collect
those points from two mouse clicks and feed the result to the module
which then generates the render-layer for overlay the Map Display.

    gui/wxpython/scripts/p.cmd
    gui/wxpython/scripts/p.db
    gui/wxpython/scripts/p.mon
    gui/wxpython/scripts/p.rast
    gui/wxpython/scripts/p.vect

IIUC the idea there was to simulate d.* command line tools from the Cmd>
GUI command prompt ???

scripts/d.out.gpsdrive/d.out.gpsdrive

this is very much like d.out.file in GRASS 6, but it forces window size
to 1280x1024 and writes georef info to a tile index file for the GpsDrive
software's backdrop tiles (www.gpsdrive.de). Requires the PNG driver etc
so won't work with GRASS 7 without a complete change of method. No idea
how to do that, but it is a useful module for users of GpsDrive + GRASS,
so if there is a way to get it to work with gr7, I'd be keen to see it
ported.

If a method is found, it would be nice to recreate a d.out.file too, as
that is very useful.

scripts/v.in.garmin/v.in.garmin

probably drop this in favour of v.in.gps(babel)

scripts/v.in.gpsbabel/v.in.gpsbabel

to be compltely rewritten as v.in.gps.py using GpsBabel -> GPX format
then -> the new v.in.ogr GPX driver.

scripts/v.out.gps/v.out.gps

to be ported.

visualization/nviz/scripts/nviz

unused? (or if used, just a 1-liner)
note nviz from File menu in wxGUI on WinGrass currently fails for
unknown reasons. ("process complete: 0 sec")

Hamish

martinl · June 19, 2009, 9:35am

Hi,

2009/6/19 Hamish <hamish_b@yahoo.com>:

gui/wxpython/scripts/p\.cmd
gui/wxpython/scripts/p\.db
gui/wxpython/scripts/p\.mon
gui/wxpython/scripts/p\.rast
gui/wxpython/scripts/p\.vect
IIUC the idea there was to simulate d.* command line tools from the Cmd>
GUI command prompt ???

yes. The idea is to start Map display from cmd, e.g.

d.mon wx0
d.rast elevation
...

Note that these scripts are quite out-dated and not maintained. I
think they can be removed, we just need to implement d.mon for wx
displays.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

Colin_Nielsen_Wren · June 19, 2009, 2:11pm

On Fri, Jun 19, 2009 at 5:19 AM, Hamish<hamish_b@yahoo.com> wrote:

visualization/nviz/scripts/nviz
unused? (or if used, just a 1-liner)
note nviz from File menu in wxGUI on WinGrass currently fails for
unknown reasons. ("process complete: 0 sec")

nviz works from the command line in wingrass though (as does vdigit).
Is that something different from the shell script?

-Colin

Glynn_Clements1 · June 19, 2009, 7:14pm

Hamish wrote:

> scripts/d.out.gpsdrive/d.out.gpsdrive

this is very much like d.out.file in GRASS 6, but it forces window size
to 1280x1024 and writes georef info to a tile index file for the GpsDrive
software's backdrop tiles (www.gpsdrive.de). Requires the PNG driver etc
so won't work with GRASS 7 without a complete change of method. No idea
how to do that, but it is a useful module for users of GpsDrive + GRASS,
so if there is a way to get it to work with gr7, I'd be keen to see it
ported.

If a method is found, it would be nice to recreate a d.out.file too, as
that is very useful.

d.out.file is meaningless in 7.0, as there is no "current monitor" to
get a list of displayed commands from.

If you want to control the rendering process, one option is for
d.out.file etc to accept a command (e.g. the name of a script) as an
argument, and run the command after setting up GRASS_PNGFILE etc.

But this looks more like something which should be built into the GUI.

> scripts/v.out.gps/v.out.gps

to be ported.

I can convert it to Python by rote, but someone will need to test (and
probably fix) the end result.

> visualization/nviz/scripts/nviz

unused? (or if used, just a 1-liner)

Pretty much. The nviz binary is a customised "wish"; it needs to be
passed "-f nviz2.2_script", which is what this script is for (for
Windows, there is nviz.bat, which runs the executable directly rather
than using this script).

--
Glynn Clements <glynn@gclements.plus.com>

neteler · July 5, 2009, 7:16pm

On Fri, Jun 19, 2009 at 11:35 AM, Martin Landa<landa.martin@gmail.com> wrote:

2009/6/19 Hamish <hamish_b@yahoo.com>:
gui/wxpython/scripts/p\.cmd
gui/wxpython/scripts/p\.db
gui/wxpython/scripts/p\.mon
gui/wxpython/scripts/p\.rast
gui/wxpython/scripts/p\.vect
IIUC the idea there was to simulate d.* command line tools from the Cmd>
GUI command prompt ???
yes. The idea is to start Map display from cmd, e.g.

d.mon wx0
d.rast elevation
...

Note that these scripts are quite out-dated and not maintained. I
think they can be removed, we just need to implement d.mon for wx
displays.

The absence of the too-good-to-lose d.mon/d.rast/d.vect/d.zoom/d.what.*
keeps me away from using daily GRASS 7
cmd line control for the wx displays would be cool.

Markus

Helena_Mitasova · August 2, 2009, 2:38am

I very much agree with Markus on this -

Helena

On Jul 5, 2009, at 3:16 PM, Markus Neteler wrote:

On Fri, Jun 19, 2009 at 11:35 AM, Martin Landa<landa.martin@gmail.com> wrote:

2009/6/19 Hamish <hamish_b@yahoo.com>:

    gui/wxpython/scripts/p.cmd
    gui/wxpython/scripts/p.db
    gui/wxpython/scripts/p.mon
    gui/wxpython/scripts/p.rast
    gui/wxpython/scripts/p.vect

IIUC the idea there was to simulate d.* command line tools from the Cmd>
GUI command prompt ???

yes. The idea is to start Map display from cmd, e.g.

d.mon wx0
d.rast elevation
...

Note that these scripts are quite out-dated and not maintained. I
think they can be removed, we just need to implement d.mon for wx
displays.

The absence of the too-good-to-lose d.mon/d.rast/d.vect/d.zoom/d.what.*
keeps me away from using daily GRASS 7
cmd line control for the wx displays would be cool.

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

mlennert · August 3, 2009, 8:25am

On 02/08/09 04:38, Helena Mitasova wrote:

I very much agree with Markus on this -

Helena

On Jul 5, 2009, at 3:16 PM, Markus Neteler wrote:

The absence of the too-good-to-lose d.mon/d.rast/d.vect/d.zoom/d.what.*
keeps me away from using daily GRASS 7
cmd line control for the wx displays would be cool.

Note that you can still use the d.* commands in combination with any image viewer (I've had good experience with gqview, for exemple, but any viewer which refreshes on file changes will do) or with Glynn's ximgview [1] which reacts much faster to changes then gqview, "but" for which you have to create bmp files. None of this allows d.* manipulation of the GUI Map Display, but it mirrors the x-mons. You can even have several such "monitors" by creating different file with export GRASS_PNGFILE and calling several instances of ximgview (or another viewer of your choice) to display the different files.

It should not be too hard to create wrapper scripts which emulate some sort of d.mon behaviour, possibly storing the image files in a temporary, hidden directory to keep things transparent.

Moritz

[1] http://lists.osgeo.org/pipermail/grass-dev/2008-October/040589.html

neteler · August 3, 2009, 1:43pm

On Mon, Aug 3, 2009 at 10:25 AM, Moritz
Lennert<mlennert@club.worldonline.be> wrote:

On 02/08/09 04:38, Helena Mitasova wrote:

I very much agree with Markus on this -

Helena

On Jul 5, 2009, at 3:16 PM, Markus Neteler wrote:

The absence of the too-good-to-lose d.mon/d.rast/d.vect/d.zoom/d.what.*
keeps me away from using daily GRASS 7
cmd line control for the wx displays would be cool.

Note that you can still use the d.* commands in combination with any image
viewer (I've had good experience with gqview, for exemple, but any viewer
which refreshes on file changes will do) or with Glynn's ximgview [1] which
reacts much faster to changes then gqview, "but" for which you have to
create bmp files. None of this allows d.* manipulation of the GUI Map
Display, but it mirrors the x-mons. You can even have several such
"monitors" by creating different file with export GRASS_PNGFILE and calling
several instances of ximgview (or another viewer of your choice) to display
the different files.

To be honest, that's still relatively far from the 6.x d.* tools.
Also zoom & query is part of my daily work

It should not be too hard to create wrapper scripts which emulate some sort
of d.mon behaviour, possibly storing the image files in a temporary, hidden
directory to keep things transparent.

Best would be to control the wx monitor from CMD line (i.e., feed map
names via cmd line to it), the zoom/etc tools on top of the monitor
are just perfect. I just would like to avoid to go through the menus
to load a map since that's slower.

Perhaps we are almost there...?

Markus

Moritz

[1] http://lists.osgeo.org/pipermail/grass-dev/2008-October/040589.html
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

martinl · August 3, 2009, 1:46pm

Hi,

2009/8/3 Markus Neteler <neteler@osgeo.org>:

[...]

Best would be to control the wx monitor from CMD line (i.e., feed map
names via cmd line to it), the zoom/etc tools on top of the monitor
are just perfect. I just would like to avoid to go through the menus
to load a map since that's slower.

I agree, `d.mon wx0` would be good to have in GRASS 7.x. Anyway, it's
possible to type d.rast / d.vect command including options in Layer
Manager cmd. A layer is added to Layer Manager automatically.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

Dylan_Beaudette1 · August 3, 2009, 2:12pm

On Mon, Aug 3, 2009 at 1:25 AM, Moritz
Lennert<mlennert@club.worldonline.be> wrote:

On 02/08/09 04:38, Helena Mitasova wrote:

I very much agree with Markus on this -

Helena

I do too. Although I like where the WX-GRASS GUI is heading, it is
still to cumbersome for (my) daily usage. I am not suggesting that
this GUI is cumbersome to others-- it is probably going to be a major
boon to new GRASS users. However, the lack of d.* commands is also
keeping me from testing out GRASS7.

Nice work on the GUI-- but some d.* command compatibility would be
greatly appreciated!

Cheers,
Dylan

On Jul 5, 2009, at 3:16 PM, Markus Neteler wrote:

The absence of the too-good-to-lose d.mon/d.rast/d.vect/d.zoom/d.what.*
keeps me away from using daily GRASS 7
cmd line control for the wx displays would be cool.

Note that you can still use the d.* commands in combination with any image
viewer (I've had good experience with gqview, for exemple, but any viewer
which refreshes on file changes will do) or with Glynn's ximgview [1] which
reacts much faster to changes then gqview, "but" for which you have to
create bmp files. None of this allows d.* manipulation of the GUI Map
Display, but it mirrors the x-mons. You can even have several such
"monitors" by creating different file with export GRASS_PNGFILE and calling
several instances of ximgview (or another viewer of your choice) to display
the different files.

It should not be too hard to create wrapper scripts which emulate some sort
of d.mon behaviour, possibly storing the image files in a temporary, hidden
directory to keep things transparent.

Moritz

[1] http://lists.osgeo.org/pipermail/grass-dev/2008-October/040589.html
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev