[GRASS-dev] [GRASS-user] r.to.vect stats
mlennert at club.worldonline.be
Tue May 2 00:24:05 PDT 2017
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>>
> > > 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
> > >
> > >>
> > >> 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 . 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."  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 ?
More information about the grass-dev