[GRASSLIST:10346] Re: recent experiences

[Maciek Sieczka]

On Thu, 16 Feb 2006 14:52:14 +0100
Bernhard Reimar Hoefle <Bernhard.Hoefle at uibk.ac.at> wrote:

> Hi!
> 
> I encountered 3 problems during my recent work with GRASS.

What version exactly? Precompiled, built from source, downloaded from
where?

> (1) NVIZ is stucking after loading the data (99%...)
> 
> I have a NVIDIA graphic card. My default Fedora Core 4 driver for
> NVIDIA (nv) couldn't support the NVIZ module. After installing the
> NVIDIA driver for Linux, NVIZ worked properly. So it's a
> hardware/driver problem and not a GRASS problem!

Please be more specific: what command exactly (copy/paste), your
region settings and r.info/v.info for data you are trying to display.
 
> (2) Point vector display accuracy
> 
> Is it a bug or a feature that the position of point vectors varies
> with the region resolution? Are the coordinates for display rounded
> in respect of the current resolution setting?
> The attached screenshots show 1m resolution
> (vector_display_error1.jpg) and 0.1m resolution
> vector_display_error2.jpg. The points should lie in the green pixels
> which they do with 0.1m resolution. The raster resolution is 1m.


Vectors are always displayed accurately according to my experience. I
expect the trouble maker is your raster layer. Depending on raster
resolution and extents the raster might be resampled during display so
that it looks different in different region settings, and this cannot
be avoided. Post the r.info output and the current region for both
cases (g.region -p).

Moreover, please note that if you are using d.zoom to set up your
region, it always alligns the region to current resolution, which is
not always a desired behaviour:
https://intevation.de/rt/webrt?serial_num=3961

> (3) r.fillnulls crashes
> 
> r.fillnulls crashes after a large amount of NODATA cells.

Post the exact command, error message, r.info and g.region -p output.

> It is a
> similar problem with vector import (> 4 Mio. vector points). I think
> that the dbf write process needs all the memory.

This might be true. Currently the DBF driver and Grass 6 vector engine
are pretty memory consuming which might lead to a freeze or slowdown
your system beyond usability. However, if you give it enough time to
complete (days maybe) it should make it. There've been few discussions
about this in grass user and grass devel lists. Browse the archives.

But - you mention a crash. Do you really mean it, or where actually
reffering to a severe slowdown?

Please note that using sqlite or postgres DB backends instead of dbf
might help you to reduce memory usage. Although sqlite looks promising
(easy to install and use, powerfull) there are issues which hold me
from recommending it (I'd love to use it myself):
1. https://intevation.de/rt/webrt?serial_num=4056
2. Extremely slow on some operations: even slower than dbf (though
faster on other). I'm attaching a small benchmark (sxc) of few
operations using dbf and sqlite on the same machine instead of
describing it.

And for postgres I haven't tried to learn it yet. But folks say it
is great.

> Do I have to split the raster in tiles or is there an other
> possibility to fill more than a few millions of null cells.

Please post more details first. *Maybe* then somebody will be able to
help you.

Maciek


--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compare.sxc
Type: application/vnd.sun.xml.calc
Size: 16034 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-user/attachments/20060216/8f5ba00a/compare.sxc