<div dir="ltr"><div class="gmail_extra">Hi all,<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 8, 2015 at 11:54 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>With the resolution option one case change the resolution of the output while using computational region to set extent and resolution of the <span class="">base</span> 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 <span class="">base</span> 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, <span class="">r</span>.<span class="">in</span>.<span class="">lidar</span> 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 <span class="">base</span> raster when reading it instead of using current region (cells aligned to the raster)".<br></blockquote></div><br><br></div><div class="gmail_extra">I've added the flag to use base raster resolution instead of the computation region resolution in r66468 to trunk. It is not by default since the region should be respected by default (and that has its own use cases). I've used -d for flag, since I had no better idea (r, a, b are used in often used other contexts).<br><br>There is no documentation yet, but there is a test on artificial data which looks good. I was testing this on real data, but I was able to see some bigger differences only with ratio of raster and region resolution about 1/30, so I was not able to check the result in detail in this case. More testing is appreciated.<br><br>The implementation should handle the the cases when region extent and raster extent are different in some better way, but for cases when region is the same or little bit smaller than the base raster, it will work fine.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Vaclav<br></div><div class="gmail_extra"><br><a href="https://trac.osgeo.org/grass/changeset/66468">https://trac.osgeo.org/grass/changeset/66468</a><br><br></div></div>