Hi,
I have some LiDAR data that was not levelled properly and I was wondering does anybody know of a way of levelling the las files to gps points?
Thanks in advance
···
Le gach dea ghui,
Shane Carey
GIS and Data Solutions Consultant
On Tue, Dec 19, 2017 at 3:29 AM, Shane Carey <careyshan@gmail.com> wrote:
I have some LiDAR data that was not levelled properly and I was wondering
does anybody know of a way of levelling the las files to gps points?
Hi,
if the issue is really just vertical (which is usually the case), you can
use v.transform zshift to shift by the given value. For rasters, e.g. DEM
based on binning the lidar points with r.in.lidar, you can use r.mapcalc to
shift it (e.g. expression "new = old + 2").
The shift can be determined by binning (or even interpolating) the points,
followed by querying raster using the GPS points as a vector using
v.what.rast, and then by computing the difference using v.db.addcolumn and
v.db.update. Finally, you can average the difference using v.db.univar. One
(average) values will be usually good enough for lidar point cloud, for UAV
point cloud, spatially variable shift might be needed.
Vaclav
[cc’ing the list]
One way to do the spatially variable shift is to do what I suggested earlier, but instead of the last step (computing average), interpolate a surface from the differences at each point using, e.g., v.surf.rst with zcolumn option set to the difference column computed earlier. For the average, the assumption was that the shift is everywhere the same. Here, the assumption is that you can interpolate in between the points, i.e. that the interpolated values are meaningful. This assumption might be broken e.g. when some abrupt surface change influenced the vertical shift of the lidar points in a specific area/around certain GPS point (unlikely case).
To actually shift the data, you need to either do the calculation in the attribute table (using the aforementioned modules such as v.db.update) or more simply, and likely more efficiently, apply the shift to a raster with binned elevations from r.in.lidar using r.mapcalc (same expression as before, just with a raster map name instead of a constant).
···
On Wed, Dec 27, 2017 at 5:22 PM, Shane Carey <careyshan@gmail.com> wrote:
Oh super Vaclav, is there a way of doing a spatially variable shift or can you only do a block shift?
Thanks for your help
On Wed, Dec 27, 2017 at 4:42 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Tue, Dec 19, 2017 at 3:29 AM, Shane Carey <careyshan@gmail.com> wrote:
I have some LiDAR data that was not levelled properly and I was wondering does anybody know of a way of levelling the las files to gps points?
Hi,
if the issue is really just vertical (which is usually the case), you can use v.transform zshift to shift by the given value. For rasters, e.g. DEM based on binning the lidar points with r.in.lidar, you can use r.mapcalc to shift it (e.g. expression “new = old + 2”).
The shift can be determined by binning (or even interpolating) the points, followed by querying raster using the GPS points as a vector using v.what.rast, and then by computing the difference using v.db.addcolumn and v.db.update. Finally, you can average the difference using v.db.univar. One (average) values will be usually good enough for lidar point cloud, for UAV point cloud, spatially variable shift might be needed.
Vaclav
Excellent, that is the way to do it!
Thanks
···
On Wed, Dec 27, 2017 at 11:14 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
[cc’ing the list]
One way to do the spatially variable shift is to do what I suggested earlier, but instead of the last step (computing average), interpolate a surface from the differences at each point using, e.g., v.surf.rst with zcolumn option set to the difference column computed earlier. For the average, the assumption was that the shift is everywhere the same. Here, the assumption is that you can interpolate in between the points, i.e. that the interpolated values are meaningful. This assumption might be broken e.g. when some abrupt surface change influenced the vertical shift of the lidar points in a specific area/around certain GPS point (unlikely case).
To actually shift the data, you need to either do the calculation in the attribute table (using the aforementioned modules such as v.db.update) or more simply, and likely more efficiently, apply the shift to a raster with binned elevations from r.in.lidar using r.mapcalc (same expression as before, just with a raster map name instead of a constant).
–
On Wed, Dec 27, 2017 at 5:22 PM, Shane Carey <careyshan@gmail.com> wrote:
Oh super Vaclav, is there a way of doing a spatially variable shift or can you only do a block shift?
Thanks for your help
On Wed, Dec 27, 2017 at 4:42 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Tue, Dec 19, 2017 at 3:29 AM, Shane Carey <careyshan@gmail.com> wrote:
I have some LiDAR data that was not levelled properly and I was wondering does anybody know of a way of levelling the las files to gps points?
Hi,
if the issue is really just vertical (which is usually the case), you can use v.transform zshift to shift by the given value. For rasters, e.g. DEM based on binning the lidar points with r.in.lidar, you can use r.mapcalc to shift it (e.g. expression “new = old + 2”).
The shift can be determined by binning (or even interpolating) the points, followed by querying raster using the GPS points as a vector using v.what.rast, and then by computing the difference using v.db.addcolumn and v.db.update. Finally, you can average the difference using v.db.univar. One (average) values will be usually good enough for lidar point cloud, for UAV point cloud, spatially variable shift might be needed.
Vaclav
Le gach dea ghui,
Shane Carey
GIS and Data Solutions Consultant
[following on a private email:]
On Wed, Dec 27, 2017 at 6:14 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
Here, the assumption is that you can interpolate in between the points,
i.e. that the interpolated values are meaningful. This assumption might be
broken e.g. when some abrupt surface change influenced the vertical shift
of the lidar points in a specific area/around certain GPS point (unlikely
case).
Another assumption/limitation is that for interpolation to make sense, you
need to have area covered with GPS points and what is outside the GPS
points (i.e. not in between the GPS points) is not correctly interpolated
(interpolation vs extrapolation). There will be edge cases where it may or
may not work and in any case you should try different methods with
different settings and see the results. If you have just couple of points
(e.g. not enough to take one out and test the interpolation), average (one
value for all) may be the most robust option.