[GRASS-dev] [GRASS-user] r.to.vect stats

[Moritz Lennert]

On 02/05/17 03:03, Vaclav Petras wrote:
> [Switching from grass-user to grass-dev.]
>
> On Mon, May 1, 2017 at 5:11 PM, Markus Metz
> <markus.metz.giswork at gmail.com <mailto:markus.metz.giswork at gmail.com>>
> wrote:
>
>     > > Is it different from the binning code in r.in.xyz <http://r.in.xyz> ?
>     >
>     >
>     > Not really. r.in.lidar was based on r.in.xyz <http://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 <http://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 <http://r.in.xyz> and a new
>     wrapper script could be created, something like r.in.lidar.filter ;-)
>
>
> I was perhaps not clear enough. The code of r.in.lidar and r.in.xyz
> <http://r.in.xyz> is the same even now except for the separation of the
> binning code and LAS versus ASCII. There is some filtering related to
> lidar, but I don't understand if it is what you mean. Nevertheless, some
> filtering in r.in.xyz <http://r.in.xyz> and getting some functionality
> from r.in.lidar would make sense (as they are used interchangeably
> depending on libLAS availability); unfortunately not really making it
> simpler.
>
>
>     > >
>     > >>
>     > >> 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 <http://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 <http://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 <http://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
>     <http://r.in.xyz>, taking as input not a text file but a GRASS
>     vector with points.
>
>
> I agree, script would be easier to maintain, but considering the
> duplication between r.in.xyz <http://r.in.xyz> and r.in.lidar (and
> possibly also r.in.pdal which I haven't mentioned yet), I though moving
> the binning code to the library and perhaps gaining some performance
> improvement along the way is a better option.
>
> But I'm not against a wrapper. I added a prototype with limited
> functionality to addons [1]. However, I'm not sure how to account for
> large data - that's what discouraged me from creating a wrapper. The
> Python subprocess documentation says use communicate() but its doc says
> "The data read is buffered in memory, so do not use this method if the
> data size is large or unlimited." [2] Do I have to do the buffering
> myself then or is it just fine? Is there some code like this in GRASS?

Wouldn't using pipe_command() and feed_command() in the grass.script be 
a solution ?

Moritz