Valeurs négatives après rastérisation CHM - lidR
Je ne comprends pas pourquoi, lors de la pixellisation de nuages de points normalisés (à l'aide de lidR, Renvironnement) sans valeur négative, je peux obtenir un modèle de hauteur de canopée raster avec des valeurs négatives?
Un exemple basé sur les exemples de données du lidRpackage:
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
Si nous regardons la valeur du CHM rastérisé, nous pouvons trouver des valeurs négatives. Le phénomène est moins clair avec ce jeu de données mais avec mes données, celles-ci peuvent être de plusieurs mètres!
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)
Cela se produit également avec l'algorithme dsmtin (), qui est vraiment similaire à celui utilisé pour la normalisation de la hauteur.
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)
Quelqu'un pourrait-il m'expliquer ces valeurs négatives?
Réponses
Pour une position p (x, y) donnée, l'interpolation d'une triangulation consiste à trouver à quel triangle ABC la localisation p calcule ses coordonnées z à partir des coordonnées du triangle.
Pour un point donné, il existe une solution mathématique pour savoir si le point appartient à un triangle. Cependant, en informatique, en raison de la précision en virgule flottante, lorsqu'un point est très proche du bord, le test est susceptible d'échouer. C'est pourquoi le calcul est fait avec une tolérance. C'est comme avoir un tampon autour des triangles. En raison de cette tolérance, un point peut être trouvé dans le mauvais triangle adjacent au triangle réel. Ce n'est pas un gros problème, cela conduit à des inexactitudes du 10ème millimètre et vous avez probablement de nombreux cas comme celui-ci dans votre raster. Mais qui s'en soucie? Elle est bien inférieure à la précision réelle du capteur.
Mais lorsque la valeur attendue est 0, cette imprécision devient visible lorsqu'elle est négative. C'est la raison du -0,0001 que vous avez repéré. Dans la v3.0.4 ( publiée aujourd'hui la semaine prochaine, nous l'espérons), la tolérance a été réduite + grid_canopy()arrondit l'élévation des pixels pour ne pas afficher trop de chiffres décimaux qui ne sont pas pertinents. Le problème a disparu.
Votre problème avec plusieurs mètres d'erreur peut être similaire. Un bug a été signalé ici il y a quelques semaines. Tout au bord, une triangulation de Delaunay est souvent très médiocre et génère des triangles non pertinents. Voir ci-dessous (à gauche) où des triangles presque verticaux ont été générés. Des triangles non pertinents + des inexactitudes de calcul peuvent conduire à des résultats étranges (au milieu). Dans la version 3.0.4, cela a été corrigé en réduisant la tolérance + en vérifiant la normale des triangles (à droite).
Dans un CHM, je suppose que cela peut également arriver dans des triangles très raides, le cas échéant. Essayez la v3.0.4 pour voir si elle résout votre problème.
