La herramienta GRASS r.in.lidar genera rásteres incompletos

Question

He estado tratando de importar un enorme LIDAR de archivo (10.5) Gb a GRASS GIS usando r.in.lidar. Se hace la tarea, pero sólo para una parte de la imagen, como se muestra a continuación:

Altura del dosel Modelo (CHM), generados con la HIERBA:

CHM generado con la FUSIÓN:

El DEM, DSM y CHM generado en la HIERBA fueron construidos a partir de los comandos siguientes, respectivamente:

r.in.lidar -o input=/my/route.las output=lidar_min method=min
r.in.lidar -o input=/my/route.las output=lidar_p99 method=percentile pth=99
r.mapcalc "CHM = lidar_p99@ig - lidar_min@ig"

Las tres capas son incompletos, sólo algunas partes de la imagen son procesados. He probado diferentes soluciones: la importación de los archivos que tengo que fusionan para crear la más grande, la importación de archivos, que había sido creada mediante la FUSIÓN (un archivo con sólo los puntos de tierra). He intentado exportar el anterior rásteres a geotiff y abrirlos en QGIS, pero el resultado es el mismo.

Lo único que ha funcionado es la conversión de los datos LIDAR de archivo ASCII (sólo el xyz columnas) y, a continuación, importarlo con r.in.xyz.

r.in.xyz input=/my/route.txt output=lidar_min separator=comma method=min

y funcionó. Este es el DEM producidos utilizando r.in.xyz de la HIERBA.

A continuación, los datos se completa.

Creo que una de las posibles razones detrás de r.in.lidar no está funcionando como se espera, podría ser que la HIERBA sólo las importaciones de los pulsos que están en el nadir o muy cerca de ella, o sólo algunos pasos del vuelo. ¿Alguien sabe la razón detrás de este comportamiento?

_{Si ayuda, esta fue la línea de comandos utilizados en la Fusión para generar el CHM que trabajó:
CanopyModel /outlier:0,20 /suelo:D:\DTM_default.dtm /ascii D:\CHM_default.dtm 5 m m 0 0 0 0 D:\laslist.txt}

La muestra

He subido una pequeña muestra de los datos aquí (https://goo.gl/0S9p0l). Contiene un archivo con sólo las coordenadas xyz (.txt), otros, con toda la tabla (x,y,z, intensidad, ángulo de la exploración, etc.) (.las) y los otros dos archivos que se Dsm creado a partir de los archivos de punto (.txt y .las).

Answer 1

La inconsistencia es causada por puntos inválidos en el conjunto de datos. Cuando ejecuto (libLAS) lasinfo en el ejemplo proporcionado, me sale:

1170966 Unclassified (1) 
1565144 Ground (2) 

Pero cuando voy a ejecutar:

las2las -i sample.las --valid_only -o sample2.las

Tengo mucho menor número de puntos:

448086 Unclassified (1) 
633077 Ground (2)

que es exactamente lo r.in.lidar informes con el conjunto de datos original, ya que utiliza sólo válido puntos:

...1081163 points found in region.

v.in.lidar es un poco más detallado y dice:

1081163 points imported
1654947 input points were not valid

Tanto el uso de LASPoint_IsValid() función de libLAS C API para determinar el punto de validez (por lo que consideran no válidos cualquiera que sea libLAS considera no válida). Validez en libLAS depende de algunos ASPRS LAS de validez de la definición. Y puede estar relacionada a la gran exploración de los ángulos de acuerdo a libLAS documentación. Parece que no las2las sería capaz de cambiar la validez de los puntos.

Por favor, abra un ticket en GRASS GIS Trac si usted piensa que esto es un error o si tiene alguna sugerencia para la mejora.