Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[Glynn Clements]

Vaclav Petras wrote:

> > Could you choose a different prefix for these commands, and leave d.*
> > for display commands?
> >
> > This also came to my mind but I had no better idea than `d` which is
> actually pretty good since d.to.rast and d.out.file are saying the same as
> r.to.vect or r.out.gdal (convert raster to vector, convert display to
> raster, ...).
> 
> If you think that only commands which are doing the actual drawing should
> start with `d`, please be more specific.

Not necessarily drawing, but commands which are in some way connected
to the display system (rather than to e.g. wxGUI). So this would
include e.g. d.info and d.where.

>  What about `d.mon` or > `d.what.rast`? Or what would be the right
>  letter to start with?

These are both related to wxGUI, so probably gui.*.

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[Nikos Alexandris]

Nikos Alexandris 


d.erase:  I would like to do `d.erase black`. Black is a *good*
background color.


Vaclav Petras wrote:


One of the problems with `d.erase` is that it is not clear what it is
supposed to do. Remove maps from display? Set background? Zoom to 
region?
Different people were/are using it with different ideas in mind. This 
is
also one of the reasons why `d.erase` is not implemented in the main 
GUI.


The only reason I use d.erase is for, as per the description, to erase 
contents
of the active display with a user defined color. If erasing could be 
part of d.mon,

then d.erase might be not necessary (any more).

Background color is already in d.mon and in d.rast.
It's the first time, though, I read about d.erase and zoom-to-region 
:-!


Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[Vaclav Petras]

On Fri, Nov 14, 2014 at 7:45 AM, "Peter Löwe"  wrote:

> Hi Nikos, dear all,
>
> >
> > Isn't it possible to merge d.out.file and d.to.rast?  Maybe instruct
> > "to.rast" with a flag or an explicit output name?
> >
> > Nikos
> >
> I strongly support this. The cumbersome re-import of the monitor content
> to use as a raster layer (d.to.file -> r.in.gdal -> r.composite) could be
> avoided.
>
> Exactly, the import is cumbersome. That's way there is now also d.to.rast
which creates the raster for you (it still needs to do the same procedure
but you don't).

http://grass.osgeo.org/grass71/manuals/d.to.rast.html#example

Peter
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[Vaclav Petras]

On Fri, Nov 14, 2014 at 7:07 AM, Nikos Alexandris 
wrote:

> * Vaclav Petras  [2014-11-12 09:35:32 -0500]:
>
> > I kindly ask command line users of d.* commands, especially those using
> d.*
> > commands in scripts, to test and participate in discussions concerning
> d.*
> > commands in GRASS GIS 7. For example, d.out.file was added (relatively)
> > lately to 7 and there is new command d.to.rast. They are designed to work
> > with wxGUI (including wx monitors).
>
> I quickly ran through most d.* commands (except for the d.vect* stuff).
> Some notes:
>
> d.erase:  I would like to do `d.erase black`. Black is a *good*
> background color.
>
> One of the problems with `d.erase` is that it is not clear what it is
supposed to do. Remove maps from display? Set background? Zoom to region?
Different people were/are using it with different ideas in mind. This is
also one of the reasons why `d.erase` is not implemented in the main GUI.


> d.info -g:  Maybe change the -g's flag description? 's/geographic//' to
> avoid confusion(s) (geographic vs. projected, etc.)?
>
>
This sounds good. Sometimes we are using "map coordinates", I think, but
just coordinates might be enough.

d.rast.edit: let instructions/mouse actions explained inside a
> wx-monitor?
>

This is quite problematic one since it is not integrated with the rest of
the GUI (and it is hard to do that). I'm not sure about future of this
module but what you are saying makes lot of sense.

>
> For the d.what* commands, the icons to perform such queries exist
> already in a wx-Monitor, right?
>
> Right, icons are there and are pretty powerful. Anna recently changed also
the backend to be more robust. She also added the support for d.what.rast
and d.what.vect commands to `d.mon wx*`.


> Isn't it possible to merge d.out.file and d.to.rast?  Maybe instruct
> "to.rast" with a flag or an explicit output name?
>
> I think that from user point of view the export from GRASS is something
else than getting the raster. From implementation point of view, they are
quite similar but this is not much important when designing the interface.
So, it is possible but I don't think that it is a good idea since they are
doing different things. (No strong opinion, however.)

Nikos
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[Vaclav Petras]

On Fri, Nov 14, 2014 at 4:31 AM, Glynn Clements 
wrote:

>
> Vaclav Petras wrote:
>
> > I kindly ask command line users of d.* commands, especially those using
> d.*
> > commands in scripts, to test and participate in discussions concerning
> d.*
> > commands in GRASS GIS 7. For example, d.out.file was added (relatively)
> > lately to 7 and there is new command d.to.rast. They are designed to work
> > with wxGUI (including wx monitors).
>
> Could you choose a different prefix for these commands, and leave d.*
> for display commands?
>
> This also came to my mind but I had no better idea than `d` which is
actually pretty good since d.to.rast and d.out.file are saying the same as
r.to.vect or r.out.gdal (convert raster to vector, convert display to
raster, ...).

If you think that only commands which are doing the actual drawing should
start with `d`, please be more specific. What about `d.mon` or
`d.what.rast`? Or what would be the right letter to start with?

--
> Glynn Clements 
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[Peter Löwe]

Hi Nikos, dear all,

> 
> Isn't it possible to merge d.out.file and d.to.rast?  Maybe instruct
> "to.rast" with a flag or an explicit output name?
> 
> Nikos
> 
I strongly support this. The cumbersome re-import of the monitor content to use 
as a raster layer (d.to.file -> r.in.gdal -> r.composite) could be avoided.

Peter


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[Nikos Alexandris]

* Vaclav Petras  [2014-11-12 09:35:32 -0500]:

> I kindly ask command line users of d.* commands, especially those using d.*
> commands in scripts, to test and participate in discussions concerning d.*
> commands in GRASS GIS 7. For example, d.out.file was added (relatively)
> lately to 7 and there is new command d.to.rast. They are designed to work
> with wxGUI (including wx monitors).

I quickly ran through most d.* commands (except for the d.vect* stuff).
Some notes:

d.erase:  I would like to do `d.erase black`. Black is a *good*
background color.

d.info -g:  Maybe change the -g's flag description? 's/geographic//' to
avoid confusion(s) (geographic vs. projected, etc.)?

d.rast.edit: let instructions/mouse actions explained inside a
wx-monitor?

For the d.what* commands, the icons to perform such queries exist
already in a wx-Monitor, right?

Isn't it possible to merge d.out.file and d.to.rast?  Maybe instruct
"to.rast" with a flag or an explicit output name?

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[Glynn Clements]

Vaclav Petras wrote:

> I kindly ask command line users of d.* commands, especially those using d.*
> commands in scripts, to test and participate in discussions concerning d.*
> commands in GRASS GIS 7. For example, d.out.file was added (relatively)
> lately to 7 and there is new command d.to.rast. They are designed to work
> with wxGUI (including wx monitors).

Could you choose a different prefix for these commands, and leave d.*
for display commands?

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[Vaclav Petras]

I kindly ask command line users of d.* commands, especially those using d.*
commands in scripts, to test and participate in discussions concerning d.*
commands in GRASS GIS 7. For example, d.out.file was added (relatively)
lately to 7 and there is new command d.to.rast. They are designed to work
with wxGUI (including wx monitors).

Thanks,
Vaclav

[GRASS-dev] d.out.file
http://lists.osgeo.org/pipermail/grass-dev/2014-February/067362.html

[GRASS-user] d.out.file - Shell-script use ?
http://lists.osgeo.org/pipermail/grass-user/2014-November/071238.html

wxGUI d.mon and g.gui monitor command line support
http://trac.osgeo.org/grass/ticket/2233

Saves the contents of the active display monitor to a graphics file
http://grass.osgeo.org/grass70/manuals/d.out.file.html

Saves the contents of the active display monitor to a raster map
http://grass.osgeo.org/grass70/manuals/d.to.rast.html

On Wed, Nov 12, 2014 at 4:13 AM, Glynn Clements 
wrote:

>
> César Augusto Ramírez Franco wrote:
>
> > As far as I understand, d.out.file only works with X monitors,
>
> This appears to be the case, although I have no idea why.
>
> The basic operation of d.out.file is to run "d.save" to extract the
> list of commands used to generate the display, then replay those
> commands on a PNG/PS/cairo monitor.
>
> The functionality on which d.save relies isn't specific to a
> particular driver.
>
> --
> Glynn Clements 
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[Glynn Clements]

César Augusto Ramírez Franco wrote:

> As far as I understand, d.out.file only works with X monitors,

This appears to be the case, although I have no idea why.

The basic operation of d.out.file is to run "d.save" to extract the
list of commands used to generate the display, then replay those
commands on a PNG/PS/cairo monitor.

The functionality on which d.save relies isn't specific to a
particular driver.

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[César Augusto Ramírez Franco]

Hi Peter,

As far as I understand, d.out.file only works with X monitors, the workflow
for a PNG monitor would be as follows:

export GRASS_PNGFILE=test.png
export GRASS_WIDTH=800
export GRASS_HEIGHT=600
d.mon start=PNG
d.rast somerastermap
d.vect somevectormap
d.mon stop=PNG

You could do this entirely on the shell or on the script, but you must
specify the PNG Driver variables before starting the PNG monitor.

This is what I tested with the PNG monitor:

d.mon start=PNG
PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file: map.png,
GRASS_WIDTH=640, GRASS_HEIGHT=480
Graphics driver [PNG] started

d.rast somerastermap
d.vect somevectormap

./test.sh
Currently selected monitor: PNG
ERROR: Only X monitors are supported.

d.mon stop=PNG
Monitor 'PNG' terminated

Please let me know if what you're trying to achieve with the PNG monitor
differs from what I tried

El Tue Nov 11 2014 at 4:02:10 p. m., "Peter Löwe" 
escribió:

> Hi César,
>
> thanks for your follow-up work in this issue: That's exactly the workflow
> I was looking for. So the issue got already fixed between GRASS6.4.2 and
> 6.4.4. Could you please verify the behaviour of d.out.file in GRASS6.4.4
> when a PNG monitor is being used ?
>
> Best,
> Peter
>
> 
>   Hello Peter,
>
> I'm sorry for misunderstanding your question, I thought that starting the
> monitor INSIDE the script would be adequate for you, I have tested this and
> couldn't reproduce your problem:
>
> I created a test.sh file on my current directory and made it executable
> with the following contents:
>
>  #!/bin/bash
> d.mon -p
> d.out.file output=test20141110 format=geotiff resolution=1 size=1440,720
>
> Then I started a monitor with some maps: d.mon x0, d.rast somerastermap,
> d.vect somevectormap
>
> Then I executed the script with ./test.sh
>
> I got this output:
>
>  Currently selected monitor: x0
> Saving display from Monitor: [x0] to .
> Image size [1440 x 720]
>  100%
> Screen export complete. (writing the file may take a small amount of time)
> Image crop [720 x 720]
> Waiting for file to write ...
> Translating to GeoTIFF format
> Done.
>
> I'm using GRASS 6.4.4 on Ubuntu 14.04 from ubuntugis PPA, let me now if
> I'm not testing it correctly
>
> El Tue Nov 11 2014 at 11:03:24 a. m., "Peter Löwe" 
> escribió:
>>
>>  Dear César, dear all,
>>
>> thanks for your input, but the core problem remains:
>>
>> When a Shell-script is invoked from the GRASS-shell (GRASS6.4.2 on Suse
>> Linux on a HPC cluster) with a monitor (x0, PNG, etc.) being already
>> activated (d.mon start / d.mon select), a g.gisenv _within_ the script will
>> properly reference the active monitor ("MONITOR=x0"), BUT a "d.save -c"
>> will throw a "WARNING: No socket to connect to for monitor" while
>> "d.out.file" gives an "ERROR: no monitor selected".
>>
>> A feasible workaround would be to store the monitors content with d.save
>> before running the script and recreating the content afterwards, but this
>> is less than elegant.
>>
>> Suggestions, anyone ?
>>
>> Best,
>> Peter
>>
>>
>>
>> 
>>
>>
>> What I use on scripts is the PNG monitor setting the GRASS_PNGFILE,
>> GRASS_HEIGHT and GRASS_WIDTH before starting the monitor.
>>
>> Take a look at the PNG Driver manual pages for more variables:
>> http://grass.osgeo.org/grass64/manuals/pngdriver.html
>>
>> El lun, 10 de noviembre de 2014 17:42, "Peter Löwe" 
>> escribió:
>>>
>>> Hi all,
>>>
>>> I'm trying call up d.out.file from within an add-on Shell-script for
>>> GRASS 6.>=4, but keep getting the following error:
>>> ERROR: No such monitor as 
>>> d.out.file output=test20141110 format=geotiff resolution=1 size=1440,720
>>> ERROR: You must select a display monitor.
>>>
>>> Let's assume that a GRASS monitor has been _started_ and _selected_ (x0,
>>> PNG, or similar) in the current GRASS session and some rasters and vectors
>>> have been drawn on it. Then, the script is invoked which needs to write out
>>> the content of the currently active monitor.
>>>
>>> Up till now neither a simple "export `g.gisenv`" or an explicit
>>> re-selecting the monitor via "d.mon select=$THECURRENTMONITOR" within the
>>> script improved the situation.
>>>
>>> Hints and suggestions would be greatly appreciated.
>>>
>>>
>>
>>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[Peter Löwe]

Hi César,

 

thanks for your follow-up work in this issue: That's exactly the workflow I was looking for. So the issue got already fixed between GRASS6.4.2 and 6.4.4. Could you please verify the behaviour of d.out.file in GRASS6.4.4 when a PNG monitor is being used ?

 

Best,

Peter

 






Hello Peter,

I'm sorry for misunderstanding your question, I thought that starting the monitor INSIDE the script would be adequate for you, I have tested this and couldn't reproduce your problem:
 

I created a test.sh file on my current directory and made it executable with the following contents:

 


#!/bin/bash

d.mon -p

d.out.file output=test20141110 format=geotiff resolution=1 size=1440,720


 

Then I started a monitor with some maps: d.mon x0, d.rast somerastermap, d.vect somevectormap

 

Then I executed the script with ./test.sh

 

I got this output:

 


Currently selected monitor: x0

Saving display from Monitor: [x0] to .

Image size [1440 x 720]

 100%

Screen export complete. (writing the file may take a small amount of time)

Image crop [720 x 720]

Waiting for file to write ...

Translating to GeoTIFF format

Done.


 

I'm using GRASS 6.4.4 on Ubuntu 14.04 from ubuntugis PPA, let me now if I'm not testing it correctly
 

El Tue Nov 11 2014 at 11:03:24 a. m., "Peter Löwe"  escribió:




Dear César, dear all,

 

thanks for your input, but the core problem remains:

 

When a Shell-script is invoked from the GRASS-shell (GRASS6.4.2 on Suse Linux on a HPC cluster) with a monitor (x0, PNG, etc.) being already activated (d.mon start / d.mon select), a g.gisenv _within_ the script will properly reference the active monitor ("MONITOR=x0"), BUT a "d.save -c" will throw a "WARNING: No socket to connect to for monitor" while "d.out.file" gives an "ERROR: no monitor selected".

 

A feasible workaround would be to store the monitors content with d.save before running the script and recreating the content afterwards, but this is less than elegant. 

 

Suggestions, anyone ?

 

Best,

Peter

 

 

 



 
 

What I use on scripts is the PNG monitor setting the GRASS_PNGFILE, GRASS_HEIGHT and GRASS_WIDTH before starting the monitor.

Take a look at the PNG Driver manual pages for more variables: http://grass.osgeo.org/grass64/manuals/pngdriver.html
 
El lun, 10 de noviembre de 2014 17:42, "Peter Löwe"  escribió:

Hi all,

I'm trying call up d.out.file from within an add-on Shell-script for GRASS 6.>=4, but keep getting the following error:
ERROR: No such monitor as 
d.out.file output=test20141110 format=geotiff resolution=1 size=1440,720
ERROR: You must select a display monitor.

Let's assume that a GRASS monitor has been _started_ and _selected_ (x0, PNG, or similar) in the current GRASS session and some rasters and vectors have been drawn on it. Then, the script is invoked which needs to write out the content of the currently active monitor.

Up till now neither a simple "export `g.gisenv`" or an explicit re-selecting the monitor via "d.mon select=$THECURRENTMONITOR" within the script improved the situation.

Hints and suggestions would be greatly appreciated.

 













___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[César Augusto Ramírez Franco]

Hello Peter,

I'm sorry for misunderstanding your question, I thought that starting the
monitor INSIDE the script would be adequate for you, I have tested this and
couldn't reproduce your problem:

I created a test.sh file on my current directory and made it executable
with the following contents:

#!/bin/bash
d.mon -p
d.out.file output=test20141110 format=geotiff resolution=1 size=1440,720

Then I started a monitor with some maps: d.mon x0, d.rast somerastermap,
d.vect somevectormap

Then I executed the script with ./test.sh

I got this output:

Currently selected monitor: x0
Saving display from Monitor: [x0] to .
Image size [1440 x 720]
 100%
Screen export complete. (writing the file may take a small amount of time)
Image crop [720 x 720]
Waiting for file to write ...
Translating to GeoTIFF format
Done.

I'm using GRASS 6.4.4 on Ubuntu 14.04 from ubuntugis PPA, let me now if I'm
not testing it correctly

El Tue Nov 11 2014 at 11:03:24 a. m., "Peter Löwe" 
escribió:

> Dear César, dear all,
>
> thanks for your input, but the core problem remains:
>
> When a Shell-script is invoked from the GRASS-shell (GRASS6.4.2 on Suse
> Linux on a HPC cluster) with a monitor (x0, PNG, etc.) being already
> activated (d.mon start / d.mon select), a g.gisenv _within_ the script will
> properly reference the active monitor ("MONITOR=x0"), BUT a "d.save -c"
> will throw a "WARNING: No socket to connect to for monitor" while
> "d.out.file" gives an "ERROR: no monitor selected".
>
> A feasible workaround would be to store the monitors content with d.save
> before running the script and recreating the content afterwards, but this
> is less than elegant.
>
> Suggestions, anyone ?
>
> Best,
> Peter
>
>
>
> 
>
>
> What I use on scripts is the PNG monitor setting the GRASS_PNGFILE,
> GRASS_HEIGHT and GRASS_WIDTH before starting the monitor.
>
> Take a look at the PNG Driver manual pages for more variables:
> http://grass.osgeo.org/grass64/manuals/pngdriver.html
>
> El lun, 10 de noviembre de 2014 17:42, "Peter Löwe" 
> escribió:
>>
>> Hi all,
>>
>> I'm trying call up d.out.file from within an add-on Shell-script for
>> GRASS 6.>=4, but keep getting the following error:
>> ERROR: No such monitor as 
>> d.out.file output=test20141110 format=geotiff resolution=1 size=1440,720
>> ERROR: You must select a display monitor.
>>
>> Let's assume that a GRASS monitor has been _started_ and _selected_ (x0,
>> PNG, or similar) in the current GRASS session and some rasters and vectors
>> have been drawn on it. Then, the script is invoked which needs to write out
>> the content of the currently active monitor.
>>
>> Up till now neither a simple "export `g.gisenv`" or an explicit
>> re-selecting the monitor via "d.mon select=$THECURRENTMONITOR" within the
>> script improved the situation.
>>
>> Hints and suggestions would be greatly appreciated.
>>
>>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] d.out.file / d.save - Shell-script use issues

[Peter Löwe]

Dear César, dear all,

 

thanks for your input, but the core problem remains:

 

When a Shell-script is invoked from the GRASS-shell (GRASS6.4.2 on Suse Linux on a HPC cluster) with a monitor (x0, PNG, etc.) being already activated (d.mon start / d.mon select), a g.gisenv _within_ the script will properly reference the active monitor ("MONITOR=x0"), BUT a "d.save -c" will throw a "WARNING: No socket to connect to for monitor" while "d.out.file" gives an "ERROR: no monitor selected".

 

A feasible workaround would be to store the monitors content with d.save before running the script and recreating the content afterwards, but this is less than elegant. 

 

Suggestions, anyone ?

 

Best,

Peter

 

 

 



 
 

What I use on scripts is the PNG monitor setting the GRASS_PNGFILE, GRASS_HEIGHT and GRASS_WIDTH before starting the monitor.

Take a look at the PNG Driver manual pages for more variables: http://grass.osgeo.org/grass64/manuals/pngdriver.html
 
El lun, 10 de noviembre de 2014 17:42, "Peter Löwe"  escribió:

Hi all,

I'm trying call up d.out.file from within an add-on Shell-script for GRASS 6.>=4, but keep getting the following error:
ERROR: No such monitor as 
d.out.file output=test20141110 format=geotiff resolution=1 size=1440,720
ERROR: You must select a display monitor.

Let's assume that a GRASS monitor has been _started_ and _selected_ (x0, PNG, or similar) in the current GRASS session and some rasters and vectors have been drawn on it. Then, the script is invoked which needs to write out the content of the currently active monitor.

Up till now neither a simple "export `g.gisenv`" or an explicit re-selecting the monitor via "d.mon select=$THECURRENTMONITOR" within the script improved the situation.

Hints and suggestions would be greatly appreciated.

 





___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user