Negative Werte nach CHM-Rasterung - lidR
Ich verstehe nicht , warum , wenn normalisierte Punktwolken Rastern (unter Verwendung lidR, RUmwelt) ohne negativen Wert, kann ich Raster Vordach Höhenmodell mit negativen Werten bekommen?
Ein Beispiel basierend auf den Beispieldaten aus dem lidRPaket:
library(lidR)
LASfile <- system.file("extdata", "Megaplot.laz", package="lidR")
las <- readLAS(LASfile)
nlas <- normalize_height(las,tin())
summary(nlas$Z) # > summary(nlas$Z) # NO Negative values
# Min. 1st Qu. Median Mean 3rd Qu. Max.
# 0.00 7.78 14.93 13.27 19.32 29.97
Wenn wir uns den Wert des gerasterten CHM ansehen, können wir negative Werte finden. Das Phänomen ist bei diesem Datensatz weniger klar, aber bei meinen Daten können diese mehrere Meter betragen!
chm <- grid_canopy(nlas, res = 1, pitfree(subcircle = 0.15))
# > chm
# class : RasterLayer
# dimensions : 236, 228, 53808 (nrow, ncol, ncell)
# resolution : 1, 1 (x, y)
# extent : 684766, 684994, 5017772, 5018008 (xmin, xmax, ymin, ymax)
# crs : +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
# source : memory
# names : Z
# values : -0.0001215559, 28.97837 (min, max)
Es tritt auch mit dem Algorithmus dsmtin () auf, der dem für die Höhennormalisierung verwendeten Algorithmus sehr ähnlich ist.
grid_canopy(nlas, res = 1, dsmtin())
# class : RasterLayer
# dimensions : 235, 228, 53580 (nrow, ncol, ncell)
# resolution : 1, 1 (x, y)
# extent : 684766, 684994, 5017773, 5018008 (xmin, xmax, ymin, ymax)
# crs : +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
# source : memory
# names : Z
# values : -0.0001546422, 29.11114 (min, max)
Könnte mir jemand diese negativen Werte erklären?
Antworten
Für eine gegebene Position p (x, y) besteht die Interpolation einer Triangulation darin, herauszufinden, zu welchem Dreieck ABC der Ort p gehört, zu dem seine z-Koordinaten aus den Koordinaten des Dreiecks berechnet werden.
Für einen bestimmten Punkt gibt es eine mathematische Lösung, um festzustellen, ob der Punkt in ein Dreieck gehört. In der Informatik ist es jedoch wahrscheinlich, dass der Test aufgrund der Gleitkommagenauigkeit fehlschlägt, wenn sich ein Punkt sehr nahe an der Kante befindet. Aus diesem Grund wird die Berechnung mit einer Toleranz durchgeführt. Es ist wie ein Puffer um die Dreiecke. Aufgrund dieser Toleranz befindet sich möglicherweise ein Punkt im falschen Dreieck neben dem tatsächlichen. Dies ist keine große Sache, es führt zu Ungenauigkeiten im Zehntel Millimeter und Sie haben wahrscheinlich viele Fälle wie diesen in Ihrem Raster. Aber wen kümmert's? Sie liegt weit unter der tatsächlichen Genauigkeit des Sensors.
Wenn der erwartete Wert jedoch 0 ist, wird diese Ungenauigkeit sichtbar, wenn sie negativ ist. Dies ist der Grund für die -0.0001, die Sie entdeckt haben. In V3.0.4 ( heute veröffentlicht hoffentlich Release nächste Woche) hat die Toleranz + reduziert grid_canopy()Runden die Pixel Höhe zu viele Dezimalstellen nicht ausgeben , die nicht relevant sind. Das Problem ist weg.
Ihr Problem mit mehreren Metern Fehler könnte irgendwie ähnlich sein. Vor einigen Wochen wurde hier ein Fehler gemeldet . Ganz am Rand ist eine Delaunay-Triangulation oft sehr schlecht und erzeugt irrelevante Dreiecke. Siehe unten (links), wo einige fast vertikale Dreiecke erzeugt wurden. Irrelevante Dreiecke + Rechenungenauigkeiten können zu seltsamen Ergebnissen führen (Mitte). In Version 3.0.4 wurde dies behoben, indem die Toleranz + durch Überprüfen der Normalen der Dreiecke (rechts) verringert wurde.
In einem CHM könnte es auch in sehr steilen Dreiecken vorkommen, wenn überhaupt. Versuchen Sie v3.0.4, um festzustellen, ob das Problem dadurch behoben wird.
