[GRASS-dev] GRASS performance references

GRASS GIS GRASS GIS developer
1

Hi Peter

Thanks for supplying your info and links, looks very interesting and relevant.

"What kind of quantitative measurements and performance metrics would you consider useful for GRASS GIS ?"
Basically measurements of volume and speed of processing certain image amounts;
E.g. GRASS GIS loaded, processed (e.g. standard classification) and exported an 10 GB RapidEye image mosaic in XX minutes/hours.
Ideally this flow should be compared with identical processed performed in closed source SW, as ENVI, Erdas, ArcGIS and other Open Source SW.

I would also like to identify any bottlenecks/showstoppers with regards to data volume.

I have seen something similar in the CASCADOSS project;
http://www.cascadoss.eu/en/index.php?option=com_content&task=view&id=14&Itemid=14
But not exactly what I wanted to showcase and use for documentation/justification of our setup.

Kind regards,
Rasmus

-----Original Message-----
From: Peter Löwe [mailto:ploewe@gfz-potsdam.de]
Sent: 14 August 2012 17:10
To: Rasmus Lundgaard Borgstrøm
Subject: Re: [GRASS-dev] GRASS performance references

> In this respect, I am trying to identify references about GRASS GIS > performance, that would allow me to state any quantitative measures of the > expected performance (data volume, processing speed etc.). Thus any links to > documented work on handling large and multiple raster files in GRASS GIS > would be appreciated.
>

Hello Rasmus,

regarding your question on GRASS-dev concerning quantitative measures for large and multiple raster processing in GRASS:

Previous work at RapidEye (http://www.rapideye.com/) involved large scale satellite image processing with GRASS, also using multiple scenes.
Until now only bits of this has been published:
http://2010.foss4g.org/presentations_show.php?id=3678
As my current work involves GRASS-based workflows on a HPC cluster, I would also be interested if the topic of quantitative measures would receive more attention.

What kind of quantitative measurements and performance metrics would you consider useful for GRASS GIS ?

Kind regards,
Peter

PS: Here are some links to presentions regarding HPC/GRASS:
http://www.wgug.org/images/stories/materialy/2011/pl_rendering_virtual_globes_presentation.pdf
http://presentations.copernicus.org/EGU2012-4364_presentation.pdf

--
------------------------------
Dr. Peter Löwe
Helmholtz-Zentrum Potsdam
Deutsches GeoForschungsZentrum - GFZ
Telegraphenberg A20
D-14473 Potsdam
Germany
Tel: +49-331-288-2338
Fax: +49-331-288-1703
------------------------------

2

On Fri, Aug 24, 2012 at 10:53 AM, Peter Löwe <ploewe@gfz-potsdam.de> wrote:
...

Maybe this would be a good place to collect such kind of info:
http://grass.osgeo.org/wiki/GRASS_GIS_Performance

FWIW I included a section on the limitation concerning "vectors with LOTS of
attributes". I just ran into that concrete wall the other day.

For the record, I have updated
http://grass.osgeo.org/wiki/GRASS_GIS_Performance#Maximum_Number_of_Attribute_Columns

Note that it is a DB backend limit which subsequently constraints GRASS GIS. You
can use a recompiled SQLite backend to manage *many* columns (see link in
Wiki page above).

best,
Markus

3

in GRASS6.4.3 I noticed that an error message shows up in red with ERROR in the GIS manager output window
while warning just shows the text in blue but the word WARNING is missing (it shows up when running this in shell)
This is causing confusion - students do not know what the message means - is that a problem or can they ignore it?
Would it be possible to add the word WARNING so that the message is consistent with the shell and with the
ERROR message.
here is an example of what I am talking about:

r.average base=zipcodes cover=elevation out=elev_avgzip
ERROR: option <output>: <elev_avgzip> exists.
                                                     
r.average base=zipcodes cover=elevation out=elev_avgzip2
r.stats:
Cats for raster map <elevation@PERMANENT> are either missing or have no explicit labels. Using nsteps=255.
r.recode:
r.recode complete. Raster map <elev_avgzip2> created.

Thank you, Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

On Aug 28, 2012, at 11:28 AM, Markus Neteler wrote:

On Fri, Aug 24, 2012 at 10:53 AM, Peter Löwe <ploewe@gfz-potsdam.de> wrote:
...

Maybe this would be a good place to collect such kind of info:
http://grass.osgeo.org/wiki/GRASS_GIS_Performance

FWIW I included a section on the limitation concerning "vectors with LOTS of
attributes". I just ran into that concrete wall the other day.

For the record, I have updated
http://grass.osgeo.org/wiki/GRASS_GIS_Performance#Maximum_Number_of_Attribute_Columns

Note that it is a DB backend limit which subsequently constraints GRASS GIS. You
can use a recompiled SQLite backend to manage *many* columns (see link in
Wiki page above).

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

4

Hi,

On Mon, Sep 17, 2012 at 4:26 AM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

in GRASS6.4.3 I noticed that an error message shows up in red with ERROR in the GIS manager output window
while warning just shows the text in blue but the word WARNING is missing (it shows up when running this in shell)

It's good you noticed it, it was a typo [1], now it's working.

Anna

[1] http://trac.osgeo.org/grass/changeset/53204

This is causing confusion - students do not know what the message means - is that a problem or can they ignore it?
Would it be possible to add the word WARNING so that the message is consistent with the shell and with the
ERROR message.
here is an example of what I am talking about:

r.average base=zipcodes cover=elevation out=elev_avgzip
ERROR: option <output>: <elev_avgzip> exists.

r.average base=zipcodes cover=elevation out=elev_avgzip2
r.stats:
Cats for raster map <elevation@PERMANENT> are either missing or have no explicit labels. Using nsteps=255.
r.recode:
r.recode complete. Raster map <elev_avgzip2> created.

Thank you, Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

On Aug 28, 2012, at 11:28 AM, Markus Neteler wrote:

On Fri, Aug 24, 2012 at 10:53 AM, Peter Löwe <ploewe@gfz-potsdam.de> wrote:
...

Maybe this would be a good place to collect such kind of info:
http://grass.osgeo.org/wiki/GRASS_GIS_Performance

FWIW I included a section on the limitation concerning "vectors with LOTS of
attributes". I just ran into that concrete wall the other day.

For the record, I have updated
http://grass.osgeo.org/wiki/GRASS_GIS_Performance#Maximum_Number_of_Attribute_Columns

Note that it is a DB backend limit which subsequently constraints GRASS GIS. You
can use a recompiled SQLite backend to manage *many* columns (see link in
Wiki page above).

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

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