Hi,
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.
Needs testing before general anouncement, so feel free to do so.
Adding a simple suggestion how to do a benchmark or test.
Vaclav
https://trac.osgeo.org/grass/changeset/66094
PS: Just now I realized that this should have been the commit with word news or feature or something for automatic extraction.
(attachments)
rinlidar_simple_benchmark.txt (2.06 KB)
This feature will be greatly appreciated by anyone working with lidar and vegetation.
Doug
···
On Thu, Sep 3, 2015 at 10:49 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
Hi,
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.
Needs testing before general anouncement, so feel free to do so.
Adding a simple suggestion how to do a benchmark or test.
Vaclav
https://trac.osgeo.org/grass/changeset/66094
PS: Just now I realized that this should have been the commit with word news or feature or something for automatic extraction.
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
–
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@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.
Hi,
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.
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)”.
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.
I wonder how much this is violating region policies and on the other hand, how much it actually adds to intuitiveness and usability.
Vaclav
https://trac.osgeo.org/grass/changeset/66151
https://trac.osgeo.org/grass/changeset/66094
···
On Thu, Sep 3, 2015 at 10:49 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
Hi,
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.
Needs testing before general anouncement, so feel free to do so.
Adding a simple suggestion how to do a benchmark or test.
Vaclav
https://trac.osgeo.org/grass/changeset/66094
PS: Just now I realized that this should have been the commit with word news or feature or something for automatic extraction.
Hi all,
On Tue, Sep 8, 2015 at 11:54 PM, Vaclav Petras <wenzeslaus@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