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

Newcomb, Doug doug_newcomb at fws.gov
Tue Oct 13 05:30:25 PDT 2015


Thanks!  Will try it out!

Doug

On Sun, Oct 11, 2015 at 12:55 AM, Vaclav Petras <wenzeslaus at gmail.com>
wrote:

> 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
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb at fws.gov
---------------------------------------------------------------------------------------------------------
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
As a federal employee, my email may be subject to FOIA request.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151013/03c351be/attachment.html>


More information about the grass-dev mailing list