[GRASS-dev] [GRASS-SVN] r65264 - grass/trunk/lib/cairodriver

GRASS GIS GRASS GIS developer
1

On Mon, May 18, 2015 at 5:16 AM, <svn_grass@osgeo.org> wrote:

+

SVG Example


+
+Example: using the driver to generate a SVG vector file with a vector
+map (bash-syntax):
+
+


+export GRASS_RENDER_IMMEDIATE=cairo

+export GRASS_RENDER_FILE=vectormap.svg

+

+g.region vector=roadsmajor

+d.vect map=roadsmajor -c

+

The syntax is not really nice. Is it possible to replace it with something else like d.mon? Or is this the best interface we have?

2

Hi,

2015-05-18 15:36 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:

+<div class="code"><pre>
+export GRASS_RENDER_IMMEDIATE=cairo
+export GRASS_RENDER_FILE=vectormap.svg
+
+g.region vector=roadsmajor
+d.vect map=roadsmajor -c
+</pre></div>

The syntax is not really nice. Is it possible to replace it with something
else like d.mon? Or is this the best interface we have?

I am not sure what you mean, but d.mon syntax could be:

d.mon cairo out=vectormap.svg
g.region vector=roadsmajor
d.vect map=roadsmajor -c
d.mon -r

Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

3

On Mon, May 18, 2015 at 9:40 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2015-05-18 15:36 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:

+



+export GRASS_RENDER_IMMEDIATE=cairo

+export GRASS_RENDER_FILE=vectormap.svg

+

+g.region vector=roadsmajor

+d.vect map=roadsmajor -c

+

The syntax is not really nice. Is it possible to replace it with something
else like d.mon? Or is this the best interface we have?

I am not sure what you mean, but d.mon syntax could be:

d.mon cairo out=vectormap.svg
g.region vector=roadsmajor
d.vect map=roadsmajor -c
d.mon -r

I think this is exactly what I mean. Any reason for using the variables instead of d.mon?

I know the difference is that it d.mon write to session env file thus changing the environment for all. The variables might be better for scripting but still the API is ugly. I don’t have an idea what should go to the documentation.

Martin

–
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

4

2015-05-18 15:46 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:

2015-05-18 15:36 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:
>> +<div class="code"><pre>
>> +export GRASS_RENDER_IMMEDIATE=cairo
>> +export GRASS_RENDER_FILE=vectormap.svg
>> +
>> +g.region vector=roadsmajor
>> +d.vect map=roadsmajor -c
>> +</pre></div>
>
> The syntax is not really nice. Is it possible to replace it with
> something
> else like d.mon? Or is this the best interface we have?

I am not sure what you mean, but d.mon syntax could be:

d.mon cairo out=vectormap.svg
g.region vector=roadsmajor
d.vect map=roadsmajor -c
d.mon -r

I think this is exactly what I mean. Any reason for using the variables
instead of d.mon?

I would say that it make sense to document the both ways
(environmental variables on display driver page and d.mon syntax on
it's own page), probably we could add note about d.mon to cairo driver
manual.

Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

5

Vaclav Petras wrote:

I think this is exactly what I mean. Any reason for using the variables
instead of d.mon?

d.mon isn't something you'd want to use from scripts or other
programs. Ultimately, d.mon is just causing those environment
variables to be set whenever you run a display command, so documenting
the variables themselves is more general than documenting a specific
mechanism used to set them. And if you don't need the convenience of
the d.mon interface, setting the variables directly removes some
complexity from the process.

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

6

On Wed, May 20, 2015 at 7:35 AM, Glynn Clements <glynn@gclements.plus.com> wrote:

Vaclav Petras wrote:

I think this is exactly what I mean. Any reason for using the variables
instead of d.mon?

d.mon isn’t something you’d want to use from scripts or other
programs. Ultimately, d.mon is just causing those environment
variables to be set whenever you run a display command, so documenting
the variables themselves is more general than documenting a specific
mechanism used to set them. And if you don’t need the convenience of
the d.mon interface, setting the variables directly removes some
complexity from the process.

Okay, so just let me rephrase to make sure I understand correctly. Unless you something like scripting of d.mon wx0 or you wish to change resolution as d.mon allows, you should use environmental variables in your scripts. d.mon is meant to be used for direct/manual usage in command line.

Unfortunately knowing that doesn’t change for me that

d.mon cairo output=vectormap.svg width=800 height=800

d.rast elevation

looks nicer then

export GRASS_RENDER_IMMEDIATE=cairo
export GRASS_RENDER_FILE=vectormap.svg
export GRASS_WIDTH=800
export GRASS_HEIGHT=800
d.rast elevation

even for scripting.

Thanks for the response,

Vaclav

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

7

Vaclav Petras wrote:

Unfortunately knowing that doesn't change for me that

d.mon cairo output=vectormap.svg width=800 height=800
d.rast elevation

looks nicer then

export GRASS_RENDER_IMMEDIATE=cairo
export GRASS_RENDER_FILE=vectormap.svg
export GRASS_WIDTH=800
export GRASS_HEIGHT=800
d.rast elevation

even for scripting.

Whether it "looks nicer" isn't the issue. The d.mon example will
overwrite the user's display settings.

Write a d.mon-based example that preserves the user's display
settings, then see which one looks nicer. Bonus marks if it correctly
handles the case where the script aborts if any command fails.

There were two main reasons why GRASS 7 abandoned the "monitor"
concept, and one of them is that its statefulness made it
next-to-impossible to write *robust* scripts involving display
commands.

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