[GRASS-user] r.to.vect stats

GRASS GRASS user
1

Hi,

I need a tool which converts vector features (points) to raster map
using statistical method like min,max,mean (something like
`r.in.lidar` does - if more points are found within one cell, raster
value is computed by given method).

I started with module `r.to.vect`, but it takes only one attribute
value if more features found, `v.kernel` does not support attributes.
There is probably such tool, I must overlook something...

Thanks for pointers, Ma

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

2

On 01/05/17 12:43, Martin Landa wrote:

Hi,

I need a tool which converts vector features (points) to raster map
using statistical method like min,max,mean (something like
`r.in.lidar` does - if more points are found within one cell, raster
value is computed by given method).

I started with module `r.to.vect`, but it takes only one attribute
value if more features found, `v.kernel` does not support attributes.
There is probably such tool, I must overlook something...

I generally use v.to.db op=coor && v.db.select | r.in.xyz for such a task. I don't know if a dedicated module would be much faster than a script that wraps around these modules. I guess avoiding the v.to.db part could gain you some time when dealing with lots of points.

Moritz

3

On Mon, May 1, 2017 at 6:54 AM, Moritz Lennert <mlennert@club.worldonline.be

wrote:

On 01/05/17 12:43, Martin Landa wrote:

I need a tool which converts vector features (points) to raster map
using statistical method like min,max,mean (something like
`r.in.lidar` does - if more points are found within one cell, raster
value is computed by given method).

I started with module `r.to.vect`, but it takes only one attribute
value if more features found, `v.kernel` does not support attributes.
There is probably such tool, I must overlook something...

I generally use v.to.db op=coor && v.db.select | r.in.xyz for such a
task. I don't know if a dedicated module would be much faster than a script
that wraps around these modules. I guess avoiding the v.to.db part could
gain you some time when dealing with lots of points.

Hi, this is certainly a missing feature. Even the v.to.rast documentation
[1] says:

v.out.ascii input=myschools_wake output=- column=value | r.in.xyz input=-

For certain cases, you may be able to use v.out.lidar instead of
v.out.ascii, but it is probably less efficient (although it uses LAS
instead of ASCII, you can't use pipes). You could also use v.mkgrid with
rectangular grid and v.vect.stats [2] followed by v.to.rast (which avoids
export, but for large grids it is likely very slow).

I have separated the binning code in r.in.lidar [3] so that it can be used
in r.in.xyz and the missing module which would do the binning of a vector
map into a raster map. There is actually a large overlap with code for
grid-based decimation of a point cloud (2D with gridded or averaged X and
Y). I already committed the code to r.in.lidar [4], but we had a discussion
on mailing list and decided that this functionality should not be part of
r.in.lidar, so it is disabled [5] but the code is still there.

Anyway, a new module needs to be implemented for this. The name can be
something like r.binning, r.vect.stats, r.point.stats, or r.points.stats.
It might good project for beginners.

Vaclav

[1]
https://grass.osgeo.org/grass72/manuals/v.to.rast.html#convert-vector-points-to-raster-with-raster-cell-binning
[2]
https://grass.osgeo.org/grass72/manuals/v.vect.stats.html#point-statistics-in-a-hexagonal-grid
[3] https://trac.osgeo.org/grass/changeset/66595
[4] https://trac.osgeo.org/grass/changeset/67210
[5] https://trac.osgeo.org/grass/changeset/68418

4

On 01/05/17 15:36, Vaclav Petras wrote:

On Mon, May 1, 2017 at 6:54 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:

    On 01/05/17 12:43, Martin Landa wrote:

        I need a tool which converts vector features (points) to raster map
        using statistical method like min,max,mean (something like
        `r.in.lidar` does - if more points are found within one cell, raster
        value is computed by given method).

        I started with module `r.to.vect`, but it takes only one attribute
        value if more features found, `v.kernel` does not support
        attributes.
        There is probably such tool, I must overlook something...

    I generally use v.to.db op=coor && v.db.select | r.in.xyz
    <http://r.in.xyz> for such a task. I don't know if a dedicated
    module would be much faster than a script that wraps around these
    modules. I guess avoiding the v.to.db part could gain you some time
    when dealing with lots of points.

Hi, this is certainly a missing feature. Even the v.to.rast
documentation [1] says:

v.out.ascii input=myschools_wake output=- column=value | r.in.xyz
<http://r.in.xyz> input=-

Duh, that's obviously much better than using v.to.db + v.db.select. I guess I haven't had many situations lately where the coordinates weren't already in the attribute table...

For certain cases, you may be able to use v.out.lidar instead of
v.out.ascii, but it is probably less efficient (although it uses LAS
instead of ASCII, you can't use pipes). You could also use v.mkgrid with
rectangular grid and v.vect.stats [2] followed by v.to.rast (which
avoids export, but for large grids it is likely very slow).

I have separated the binning code in r.in.lidar [3] so that it can be
used in r.in.xyz <http://r.in.xyz>

Is it different from the binning code in r.in.xyz ?

and the missing module which would do
the binning of a vector map into a raster map. There is actually a large
overlap with code for grid-based decimation of a point cloud (2D with
gridded or averaged X and Y). I already committed the code to r.in.lidar
[4], but we had a discussion on mailing list and decided that this
functionality should not be part of r.in.lidar, so it is disabled [5]
but the code is still there.

So what you are saying is that the code should go into a library and be used by all relevant modules ?

Anyway, a new module needs to be implemented for this. The name can be
something like r.binning, r.vect.stats, r.point.stats, or
r.points.stats. It might good project for beginners.

I like the idea. But do you really think this would be much faster than v.out.ascii | r.in.xyz ?

Moritz

5

On Mon, May 1, 2017 at 11:43 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

I have separated the binning code in r.in.lidar [3] so that it can be
used in r.in.xyz

Is it different from the binning code in r.in.xyz ?

Not really. r.in.lidar was based on r.in.xyz, now they are different but of course the idea is to make them again as similar as possible.

and the missing module which would do
the binning of a vector map into a raster map. There is actually a large
overlap with code for grid-based decimation of a point cloud (2D with
gridded or averaged X and Y). I already committed the code to r.in.lidar
[4], but we had a discussion on mailing list and decided that this
functionality should not be part of r.in.lidar, so it is disabled [5]
but the code is still there.

So what you are saying is that the code should go into a library and be used by all relevant modules ?

Yes. That would be ideal. Now it is in separate files in r.in.lidar and it can be copied and synced, but I think the library would not be less general than other libraries, so there is probably no reason to not include it. The only reason I didn’t do it is that I wanted to do the refactoring in r.in.xyz first (which I never finished) and then work on the library.

Anyway, a new module needs to be implemented for this. The name can be
something like r.binning, r.vect.stats, r.point.stats, or
r.points.stats. It might good project for beginners.

I like the idea. But do you really think this would be much faster than v.out.ascii | r.in.xyz ?

I don’t know if much faster, but it will be at least little faster. Another issue is that “v.out.ascii | r.in.xyz” is little hard to do on MS Windows and from GUI in general. Yes, there should have been a wrapper module for this already, but the a module to do the task directly is seems to me as a better solution esp. if there is the library. But the wrapper module may be a good way to start and to decide about the name and interface.

6

On Mon, May 1, 2017 at 7:47 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Mon, May 1, 2017 at 11:43 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

I have separated the binning code in r.in.lidar [3] so that it can be
used in r.in.xyz

Is it different from the binning code in r.in.xyz ?

Not really. r.in.lidar was based on r.in.xyz, now they are different but of course the idea is to make them again as similar as possible.

I would rather keep r.in.xyz as simple as possible and instead add wrapper scripts for specific tasks. Maybe r.in.lidar could be sync’ed back to r.in.xyz and a new wrapper script could be created, something like r.in.lidar.filter :wink:

Anyway, a new module needs to be implemented for this. The name can be
something like r.binning, r.vect.stats, r.point.stats, or
r.points.stats. It might good project for beginners.

I like the idea. But do you really think this would be much faster than v.out.ascii | r.in.xyz ?

I don’t know if much faster, but it will be at least little faster. Another issue is that “v.out.ascii | r.in.xyz” is little hard to do on MS Windows and from GUI in general. Yes, there should have been a wrapper module for this already, but the a module to do the task directly is seems to me as a better solution

Why would a new C module be a better solution than a simple wrapper combining v.out.ascii + r.in.xyz? Considering code maintenance, a wrapper script would be easier to maintain. Otherwise, a dedicated C module would be another clone of r.in.xyz, taking as input not a text file but a GRASS vector with points.

my2c

Markus M