[GRASS-user] v.to.rast

Blumentrath, Stefan Stefan.Blumentrath at nina.no
Thu Jul 30 05:46:48 PDT 2015

OK, that sounds unreasonably slow. Maybe a bug… (or is this only due dbf backend?)

You could try v.out.ogr (instead of v.out.ascii) and write to CSV?! You can then use the CSV in r.in.xyz…

If you only need point counts (and not the sum of some values) you could use v.to.db to generate a list with x/y coordinates you could pipe to r.in.xyz and count the points there.

Or (as an ugly work around) you could convert the raster map you already created from your points back to vector (area) and then use v.vect.stats and then convert the result to raster…


From: patrick s. [mailto:patrick_gis at gmx.net]
Sent: 30. juli 2015 14:27
To: Blumentrath, Stefan; Markus Neteler
Cc: GRASS user list
Subject: Re: [GRASS-user] v.to.rast

Thanks Stefan

It seems first of all v.out.ascii is slow. Following your proposaI, the tmp-file has only 5300 observations after 9min15s. As I have 650.000 points this export will need approx. 18h! Can I speed this up somehow? (Database-driver is dbf)


P.S. g.region -up & v.info are given below.

##g.region -up
projection: 99 (Swiss. Obl. Mercator)
zone:       0
datum:      ch1903
ellipsoid:  bessel
north:      1297000
south:      1074200
west:       2484400
east:       2834800
nsres:      25
ewres:      25
rows:       8912
cols:       14016
cells:      124910592

 Number of points:       647957          Number of centroids:  0          |
 |   Number of lines:        0               Number of boundaries: 0          |
 |   Number of areas:        0               Number of islands:    0          |
 |                                                                            |
 |   Map is 3D:              No                                               |
 |   Number of dblinks:      1                                                |
 |                                                                            |
 |   Projection: Swiss. Obl. Mercator                                         |
 |                                                                            |
 |               N:           1294822    S:           1075554                 |
 |               E:           2831184    W:           2486245

On 30.07.2015 13:59, Blumentrath, Stefan wrote:
Hi Patrick,

From my experience r.in.xyz is very fast.
How many points are you processing (v.info pt) and what are your region settings (g.region –up)?

In order to find out where time is spend yo could split upt the process into two steps:
v.out.ascii input=pt output=./tmp column=VAL
r.in.xyz input=./tmp z=4 output=pt method=sum


From: grass-user-bounces at lists.osgeo.org<mailto:grass-user-bounces at lists.osgeo.org> [mailto:grass-user-bounces at lists.osgeo.org] On Behalf Of patrick s.
Sent: 30. juli 2015 10:18
To: Markus Neteler
Cc: GRASS user list
Subject: Re: [GRASS-user] v.to.rast


I tested the approach you proposed, but seems to be very slow for large datasets: I am processing ~1000.000 points of observation on a 25m-Grid across Switzerland, where only few cells have multiple points inside. While v.to.rast takes a few minutes for conversion, the combination "v.out.ascii input=pt output=- column=VAL | r.in.xyz input=- z=4 output=pt method=sum" has been running for multiple hours and is still in progress.

Is there any alternative to run this conversion? I need it to run neighborhood analyses as kernel density with population field, i.e. r.neighbors in=pt out=pt_dens -c size=300 meth=sum. Maybe there is an approach to directly use the vector data and avoid conversion- something as v.neighbors meth=sum?

Thanks for you help,

On 24.07.2015 04:13, Markus Neteler wrote:

On Thu, Jul 23, 2015 at 11:00 AM, patrick s. <patrick_gis at gmx.net><mailto:patrick_gis at gmx.net> wrote:

Dear all

I am puzzled on the behavior of v.to.rast. When several points fall into one

gridcell, the raster seems to get one value but not the sum of these. Is

there a way to sum these up instead?

Yes. I have added a related example here:


(while it does not really fit to that manual page it is expected

there. Perhaps we need to really enhance v.to.rast to do such a job

right away).



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20150730/e85ffdff/attachment-0001.html>

More information about the grass-user mailing list