[GRASS-dev] r.in.lidar: height above ground

[Vaclav Petras]

Hi all,

On Tue, Sep 8, 2015 at 11:54 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:

> 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.
>
> 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)".
>


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

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.

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.

Vaclav

https://trac.osgeo.org/grass/changeset/66468
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151011/40e54488/attachment.html>