[GRASS-dev] d.barb: call for testing

GRASS GRASS developer
1

Hi,

I have added a new C module in the addons svn which will draw wind barbs,
straw plots, and arrow plots from a raster array or sparse vector point
data. It can use either direction + magnitude, or u + v components as the
input, and can produce a legend key.

Some of this functionality is already covered by d.rast.arrow and d.vect,
but I thought I'd bring it together into a dedicated tool and add some
commonly needed options.

It's still a work in progress, and there are still a few things on the
todo list, but I think it's ready to get some testing now.

Once the bugs are out and the design & feature set have been finalized
I'd port it to grass7 and hope to add it to the main distribution + GUI.
(One weird thing I notice is that in the tcl/tk GUI the legend_at=
option appears as a tick box not a text entry field. ?)

  http://grass.osgeo.org/wiki/GRASS_AddOns#d.barb
  http://trac.osgeo.org/grass/browser/grass-addons/display/d.barb

screenshot: (style=arrow)
  http://bambi.otago.ac.nz/hamish/grass/screenshots/narr-a_221_20100629_1800_000_10m_winds.png

maybe g.extension works to install it if you compiled grass yourself?
(I haven't tried installing it that way yet)

comments, wishes, & criticisms welcome. usage follows, see the help
page for more explanation & examples.

Hamish

--------------------------------------

GRASS65> d.barb --help

Description:
Draws flow barbs.

Keywords:

Usage:
d.barb [-r] [direction=name] [magnitude=name] [u=name] [v=name]
   [input=name] [layer=value] [style=string] [color=name] [skip=value]
   [scale=value] [peak=value] [aspect_type=string]
   [legend_at=x,y[,x,y,...]] [legend_velo=value[,value,...]]
   [legend_fontsize=value] [--verbose] [--quiet]

Flags:
  -r Rotate direction 180 degrees
        Useful for switching between atmospheric and oceanographic conventions
--v Verbose module output
--q Quiet module output

Parameters:
        direction Raster map (or attribute column) containing velocity direction
        magnitude Raster map (or attribute column) containing velocity magnitude
                u Raster map (or attribute column) containing u-component of velocity
                v Raster map (or attribute column) containing v-component of velocity
            input Name of input vector map
            layer Layer number
                     A single vector map can be connected to multiple database tables. This number determines which table to use.
                    default: 1
            style Style
                    options: arrow,barb,straw
                    default: arrow
            color Color
                     Either a standard color name or R:G:B triplet
                    default: black
             skip Draw arrow every Nth grid cell
                    default: 10
            scale Scale factor for arrow rendering
                    default: 1.0
             peak Maximum value for scaling (overrides map's maximum)
      aspect_type Direction map aspect type
                    options: cartesian,compass
                    default: cartesian
        legend_at Screen percentage for legend barb ([0,0] is bottom-left)
                     Draws a single barb and exits
                    options: 0-100
                    default: 10.0,10.0
      legend_velo Velocity for legend key arrow
  legend_fontsize Font size used in legend
                    default: 14

2

Nice work!

I had been thinking about using this type of graphic to describe the potential
movement of water/sediment flux along landscape gradients for some time now...
With a little bit of tinkering around, I was able to get a figure that matched
my mental picture:

http://basho.dyndns.org/~dylan/temp/d.barb_terrain_example.jpg

Colors represent mean curvature, contours are every 10 meters, white lines are
from r.flow, arrow direction is from an aspect map, arrow length is scaled by
the compound topographic index.

Thanks!

Dylan

On Wednesday, April 27, 2011, Hamish wrote:

Hi,

I have added a new C module in the addons svn which will draw wind barbs,
straw plots, and arrow plots from a raster array or sparse vector point
data. It can use either direction + magnitude, or u + v components as the
input, and can produce a legend key.

Some of this functionality is already covered by d.rast.arrow and d.vect,
but I thought I'd bring it together into a dedicated tool and add some
commonly needed options.

It's still a work in progress, and there are still a few things on the
todo list, but I think it's ready to get some testing now.

Once the bugs are out and the design & feature set have been finalized
I'd port it to grass7 and hope to add it to the main distribution + GUI.
(One weird thing I notice is that in the tcl/tk GUI the legend_at=
option appears as a tick box not a text entry field. ?)

  http://grass.osgeo.org/wiki/GRASS_AddOns#d.barb
  http://trac.osgeo.org/grass/browser/grass-addons/display/d.barb

screenshot: (style=arrow)
  http://bambi.otago.ac.nz/hamish/grass/screenshots/narr-

a_221_20100629_1800_000_10m_winds.png

maybe g.extension works to install it if you compiled grass yourself?
(I haven't tried installing it that way yet)

comments, wishes, & criticisms welcome. usage follows, see the help
page for more explanation & examples.

Hamish

--------------------------------------

GRASS65> d.barb --help

Description:
Draws flow barbs.

Keywords:

Usage:
d.barb [-r] [direction=name] [magnitude=name] [u=name] [v=name]
   [input=name] [layer=value] [style=string] [color=name] [skip=value]
   [scale=value] [peak=value] [aspect_type=string]
   [legend_at=x,y[,x,y,...]] [legend_velo=value[,value,...]]
   [legend_fontsize=value] [--verbose] [--quiet]

Flags:
  -r Rotate direction 180 degrees
        Useful for switching between atmospheric and oceanographic

conventions

--v Verbose module output
--q Quiet module output

Parameters:
        direction Raster map (or attribute column) containing velocity

direction

        magnitude Raster map (or attribute column) containing velocity

magnitude

                u Raster map (or attribute column) containing u-component

of velocity

                v Raster map (or attribute column) containing v-component

of velocity

            input Name of input vector map
            layer Layer number
                     A single vector map can be connected to multiple

database tables. This number determines which table to use.

                    default: 1
            style Style
                    options: arrow,barb,straw
                    default: arrow
            color Color
                     Either a standard color name or R:G:B triplet
                    default: black
             skip Draw arrow every Nth grid cell
                    default: 10
            scale Scale factor for arrow rendering
                    default: 1.0
             peak Maximum value for scaling (overrides map's maximum)
      aspect_type Direction map aspect type
                    options: cartesian,compass
                    default: cartesian
        legend_at Screen percentage for legend barb ([0,0] is bottom-left)
                     Draws a single barb and exits
                    options: 0-100
                    default: 10.0,10.0
      legend_velo Velocity for legend key arrow
  legend_fontsize Font size used in legend
                    default: 14
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Dylan E. Beaudette
USDA-NRCS Soil Scientist
California Soil Resource Lab
http://casoilresource.lawr.ucdavis.edu/

3

On Wed, Apr 27, 2011 at 5:28 PM, Dylan Beaudette
<debeaudette@ucdavis.edu> wrote:

Nice work!

Yes, very nice.

I had been thinking about using this type of graphic to describe the potential
movement of water/sediment flux along landscape gradients for some time now...
With a little bit of tinkering around, I was able to get a figure that matched
my mental picture:

http://basho.dyndns.org/~dylan/temp/d.barb_terrain_example.jpg

Colors represent mean curvature, contours are every 10 meters, white lines are
from r.flow, arrow direction is from an aspect map, arrow length is scaled by
the compound topographic index.

Nice, too! Could you perhaps make a NVIZ view of the same map?
Would be pretty to have both for the screenshot section...

thanks
Markus

4

Dylan wrote:

Nice work!

cheers

I had been thinking about using this type of graphic to
describe the potential movement of water/sediment flux along
landscape gradients for some time now...
With a little bit of tinkering around, I was able to get a
figure that matched> my mental picture:

http://basho.dyndns.org/~dylan/temp/d.barb_terrain_example.jpg

Colors represent mean curvature, contours are every 10
meters, white lines are from r.flow, arrow direction is from
an aspect map, arrow length is scaled by the compound
topographic index.

for the record, d.rast.arrow has been able to do this for some
time now, see the GRASS raster screenshots page for an example.
(actually for the d.barb Eulerian array fields I just adapted
my earlier scaled arrow code from there)

a tip to get rid of the outer cell-border of garbage values:
r.mapcalc "invert = if(isnull(map), 1, null()"
r.grow in=invert out=invert_buf1
r.mapcalc "MASK = if(isnull(invert_buf1), 1, null()"
r.mapcalc "crop = map"

Hamish

5

On Wednesday, April 27, 2011, Hamish wrote:

Dylan wrote:
> Nice work!

cheers

> I had been thinking about using this type of graphic to
> describe the potential movement of water/sediment flux along
> landscape gradients for some time now...
> With a little bit of tinkering around, I was able to get a
> figure that matched> my mental picture:
>
> http://basho.dyndns.org/~dylan/temp/d.barb_terrain_example.jpg
>
> Colors represent mean curvature, contours are every 10
> meters, white lines are from r.flow, arrow direction is from
> an aspect map, arrow length is scaled by the compound
> topographic index.

for the record, d.rast.arrow has been able to do this for some
time now, see the GRASS raster screenshots page for an example.
(actually for the d.barb Eulerian array fields I just adapted
my earlier scaled arrow code from there)

a tip to get rid of the outer cell-border of garbage values:
r.mapcalc "invert = if(isnull(map), 1, null()"
r.grow in=invert out=invert_buf1
r.mapcalc "MASK = if(isnull(invert_buf1), 1, null()"
r.mapcalc "crop = map"

Hamish

Thanks for the tips, that worked well.

Dylan

--
Dylan E. Beaudette
USDA-NRCS Soil Scientist
California Soil Resource Lab
http://casoilresource.lawr.ucdavis.edu/

6

On 30/04/11 21:50, Rebecca Bennett wrote:

hello there,

Does anyone know the maximum number of points that v.what.rast can handle?
I have a file of 600,000+ points that fails to run (12hrs 100% CPU and
nothing) and I wonder, before I start with trial and error, if anyone
knows the answer?

There is no fixed maximum number of points. My guess would be that the time needed really depends on the database backend and whether there is an index on the category column.

Which backend are you using ? Which process is running during all this time ?

The module executes each individual update query one at a time. Maybe it might be more efficient to group them into a temporary file with the SQL statements and then run that all at once ?

Moritz

7

On 02/05/11 12:44, Rebecca Bennett wrote:

Hi Moritz,

Thanks for responding.

>Which backend are you using ?

Backend is currently dbf (default). Is there a preferred option for
speeding up this type of query?

I don't know if there have been any speed tests of backends, but you could try with PostgreSQL, making sure that the cat column has an index.

>Which process is running during all this time ?

Not sure exactly which process is running. I did --verbose but the chat
stopped after the "excluding x points outside region" message. Any tips
on how to tell which point it is sticking at would be gratefully received!

Depends on which OS you are on. In GNU/Linux just type 'top' in the command line and look at which process is using up CPU time.

>The module executes each individual update query one at a time. Maybe
it might be more efficient >to group them into a temporary file with the
SQL statements and then run that all at once?

Sounds good but I have no idea how to do this - can you point me in the
direction of some more info so that I could try this method?

This is more on the developers' side, as it will have to be programmed in the module.

For now, what you could already try is to work in smaller batches, by reducing the number of points using the where clause and/or the region you work on (using g.region before v.what.rast).

Moritz

8

hello there,

Does anyone know the maximum number of points that v.what.rast can handle?
I have a file of 600,000+ points that fails to run (12hrs 100% CPU and nothing) and I wonder, before I start with trial and error, if anyone knows the answer?

Thanks for reading!
Rebecca

9

Hi Moritz,

Thanks for responding.

Which backend are you using ?

Backend is currently dbf (default). Is there a preferred option for speeding up this type of query?

Which process is running during all this time ?

Not sure exactly which process is running. I did --verbose but the chat stopped after the “excluding x points outside region” message. Any tips on how to tell which point it is sticking at would be gratefully received!

The module executes each individual update query one at a time. Maybe it might be more efficient >to group them into a temporary file with the SQL statements and then run that all at once?

Sounds good but I have no idea how to do this - can you point me in the direction of some more info so that I could try this method?

Many thanks,
Rebecca

From: Moritz Lennert mlennert@club.worldonline.be
To: Rebecca Bennett rabennett@ymail.com
Cc: grass list grass-user@lists.osgeo.org; grass-dev grass-dev@lists.osgeo.org
Sent: Mon, 2 May, 2011 10:00:41
Subject: Re: [GRASS-user] Maximum number of points for v.what.rast

On 30/04/11 21:50, Rebecca Bennett wrote:

hello there,

Does anyone know the maximum number of points that v.what.rast can handle?
I have a file of 600,000+ points that fails to run (12hrs 100% CPU and
nothing) and I wonder, before I start with trial and error, if anyone
knows the answer?

There is no fixed maximum number of points. My guess would be that the time needed really depends on the database backend and whether there is an index on the category column.

Which backend are you using ? Which process is running during all this time ?

Moritz

10

Dear all,

I am currently putting together a script for a colleague to help automate some DTM processing.

Part of this script involves a low pass filter applied using r.mfilter. When I applied this command for my research I used GRASS 7, but my colleague will only have access to GRASS 6.4.

There is a large discrepancy in the quality of the low pass r.mfilter output between the two versions with 6.4 giving a stepped DTM that cannot be used for further processing in this instance.

My questions are, what underlies this discrepancy and can I improve the r.mfilter results from GRASS 6.4 to make them of equal quality to those of GRASS 7?

Thanks as always for your time,

Rebecca Bennett