Hamish or others,
has anybody considered writing r3.in.xyz?
It could be useful for analyzing multiple return lidar point clouds and terrestrial lidar point clouds of vertical
features such as eroding stream banks.
I wanted to ask before we look into it here,
thanks, Helena
Helena wrote:
has anybody considered writing r3.in.xyz?
It could be useful for analyzing multiple return lidar
point clouds and terrestrial lidar point clouds of vertical
features such as eroding stream banks.
I wanted to ask before we look into it here,
yes, it is very easy; all you need to do is run r.in.xyz in a loop,
iterating on the zrange=. It is easily accomplished with a wrapper
script, no need to adjust (ie clutter) the C code. Stand by and I'll
upload one to addons. Due to memory concerns I don't think that
slicing up the segments in smaller 3D cubes versus larger 2D slices
would actually help much, except for very small 3D regions, so there
is not much of a performance hit by using a script.
from the r.in.xyz man page:
The zrange parameter may be used for filtering the input
data by vertical extent. Example uses might include prepar-
ing multiple raster sections to be combined into a 3D
raster array with r.to.rast3, or for filtering outliers on
relatively flat terrain.
The only code change to consider is:
- if (z < zrange_min || z > zrange_max) {
+ if (z < zrange_min || z >= zrange_max) {
G_free_tokens(tokens);
continue;
}
so points falling exactly on the upper bound of the range are considered
only once, and belong to the horizontal slice above the current one.
Hamish
Helena wrote:
> has anybody considered writing r3.in.xyz?
> It could be useful for analyzing multiple return lidar
> point clouds and terrestrial lidar point clouds of vertical
> features such as eroding stream banks.
> I wanted to ask before we look into it here,yes, it is very easy; all you need to do is run r.in.xyz in
a loop, iterating on the zrange=. It is easily accomplished
with a wrapper script, no need to adjust (ie clutter) the C code.
Stand by and I'll upload one to addons.
ok, done:
http://grass.osgeo.org/wiki/GRASS_AddOns#r3.in.xyz
if you have a multi-processor computer you can even run the import
of each vertical band in parallel using the workers= option, for a nice
speedup. (poor-man's technique)
see the help page for details on setting up the 3D region resolutions.
(can be tricky!)
The only code change to consider is:
- if (z < zrange_min || z > zrange_max) {
+ if (z < zrange_min || z >= zrange_max) {
G_free_tokens(tokens);
continue;
}so points falling exactly on the upper bound of the range
are considered only once, and belong to the horizontal slice
above the current one.
a solution has been implemented within the r3.in.xyz wrapper script,
no modifications to r.in.xyz are needed.
let me know if it works(!), and what sort of 3D interpolation could be
used to fill in the voids between the stars if a too-fine resolution
was used. (export to 3D vector then v.vol.rst?)
Hamish