BTW. On my Linux box v.out.ascii in GRASS 7 (SQLite backend) dumped 724,798 points in 8.2 seconds to stdout…
From: grass-user-boun...@lists.osgeo.org [mailto:grass-user-boun...@lists.osgeo.org] On Behalf Of Blumentrath, Stefan Sent: 30. juli 2015 14:47 To: patrick s. Cc: GRASS user list Subject: Re: [GRASS-user] v.to.rast 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… Cheers Stefan From: patrick s. [mailto:patrick_...@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) Patrick 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 ##v.info 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 Cheers Stefan From: grass-user-boun...@lists.osgeo.org<mailto:grass-user-boun...@lists.osgeo.org> [mailto:grass-user-boun...@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 Markus 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, Patrick On 24.07.2015 04:13, Markus Neteler wrote: On Thu, Jul 23, 2015 at 11:00 AM, patrick s. <patrick_...@gmx.net><mailto:patrick_...@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: http://grass.osgeo.org/grass70/manuals/v.to.rast.html#convert-vector-points-to-raster-with-raster-cell-binning (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). HTH Markus
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
