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.gisw...@gmail.com <mailto:markus.metz.gisw...@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
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
