<div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>in r66151, I've fixed/enabled the resolution option in combination with the base raster. When the option resolution is set, the module is little bit slower as it uses Segment library. Determining the optimal size of segments according to percentage option is a todo.<br><br></div>With the resolution option one case change the resolution of the output while using computational region to set extent and resolution of the base raster. However, after discussion with Doug, I see that it makes more sense to match the output to the region, which can be nicely set beforehand to align with some other raster. If this resolution would low (coarse) - we do binning - it makes sense to use the input base raster at higher (finer) resolution, the original resolution of the data is a clear choice. I'm not sure if this should be the default but probably not, since it would violate the region behavior. <br><br></div>As a result, r.in.lidar output would respect region, optionally modified by resolution (current behavior) and the input would use the region as well, unless a flag would be set. This flag would be something like -d "Use the resolution of the input base raster when reading it instead of using current region (cells aligned to the raster)".<br><br></div>This issue with input/output region is similar with the one with r.resamp.rst. From point of view of what is need for r.in.lidar it seems that r.resamp.rst should honor the resolution of the data since we are resampling from that resolution or at least it should have a flag for it. Similarly to r.in.lidar, we often want to resample to match some existing raster which we can only do using region.<br><br></div>I wonder how much this is violating region policies and on the other hand, how much it actually adds to intuitiveness and usability.<br><div><div><div><div><br></div><div>Vaclav<br></div><div><br><a href="https://trac.osgeo.org/grass/changeset/66151">https://trac.osgeo.org/grass/changeset/66151</a><br><a href="https://trac.osgeo.org/grass/changeset/66094">https://trac.osgeo.org/grass/changeset/66094</a><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 3, 2015 at 10:49 PM, Vaclav Petras <span dir="ltr"><<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi,<br><br></div>in r66094, I've added base raster map to r.in.lidar. When provided, r.in.lidar with subtract its values from the points' z values. In this way, one can get height about ground.<br><br></div>Needs testing before general anouncement, so feel free to do so.<br><div><div><div><br></div><div>Adding a simple suggestion how to do a benchmark or test.<br></div><div><br></div><div>Vaclav<br></div><div><br><a href="https://trac.osgeo.org/grass/changeset/66094" target="_blank">https://trac.osgeo.org/grass/changeset/66094</a><br><br></div><div>PS: Just now I realized that this should have been the commit with word news or feature or something for automatic extraction.<br></div></div></div></div>
</blockquote></div><br></div>