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

[Vaclav Petras]

[Switching from grass-user to grass-dev.]

On Mon, May 1, 2017 at 5:11 PM, Markus Metz <markus.metz.giswork at gmail.com>
wrote:

> > > 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 ;-)
>

I was perhaps not clear enough. The code of r.in.lidar and 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 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 ?
> >
> >
> > 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.
>

I agree, script would be easier to maintain, but considering the
duplication between 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?

Thanks for the feedback,
Vaclav

[1] https://trac.osgeo.org/grass/changeset/70996
[2]
https://docs.python.org/2/library/subprocess.html#subprocess.Popen.communicate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170501/ca476d86/attachment.html>