We need a clear plan for point cloud functionality in GeoTrellis. The plan has been, at the point of writing this, is to have an external project names geotrellis-pointcloud which holds this functionality. It has the code that reads las/laz/etc point cloud data via PDAL java bindings into Spark RDDs, as well as distributed operations on point cloud RDDs such as DEM generation.
I hit a use case where I needed the DEM generation, but not the PDAL stuff. Namely, we were importing a set of lidar derived contour lines in a process where we dissolved very dense lines and wanted to derive a TIN from those points (the original lidar pointclouds were not available). This could use all of the pointcloud functionality that lives in geotrellis-pointcloud, without the additional burden of installing the PDAL binaries and the required configuration to allow the JNI bindings to work.
There seems to be two paths here:
Separate geotrellis-pointcloud into subprojects; one that focuses on PDAL IO to and from GeoTrellis types like an RDD of PointClouds, and one that focuses on the algorithms that you can apply to point clouds once they are in the Scala types. This would require a rewrite of the algorithms to work against an abstraction of point clouds, instead of the pdal-jvmPointCloud type.
Bring the functionality that doesn't require PDAL into core GeoTrellis. we could re-implement a geotrellis-pointcloud project that deals with the algorithms, and separate out a geotrellis-pdal project that deals explicitly with the PDAL based IO. This separate things based on pure JVM and abstracted point cloud types (that could handle both the line-dissolve use case above and PDAL point clouds)
Either path suggests an abstraction of functionality on top of an interface into point cloud types, that can either be served by PDAL types or something like Array[Coordinate].
I'll catalog the functionality that I see in geotrellis-pointcloud, that would have to be cleaned up and made generally useful:
TinToDem - Creating a DEM from a point cloud via delaunay triangulation
CutPointCloud - Cutting point clouds based on a tile layout
Pyramiding point cloud layers
IO component that writes point cloud layers to GeoTrellis avro based layers (not reading from PDAL readable files)
PointCloudToDem methods, which do IDW interpolation for DEM creation. TinToDem and PointToGrid functionality should be in the same place, and consistently named.
Looking for ideas on how to do this split, and what should be in GT core and an external geotrellis-pointcloud or geotrellis-pdal project.
We need a clear plan for point cloud functionality in GeoTrellis. The plan has been, at the point of writing this, is to have an external project names geotrellis-pointcloud which holds this functionality. It has the code that reads las/laz/etc point cloud data via PDAL java bindings into Spark RDDs, as well as distributed operations on point cloud RDDs such as DEM generation.
I hit a use case where I needed the DEM generation, but not the PDAL stuff. Namely, we were importing a set of lidar derived contour lines in a process where we dissolved very dense lines and wanted to derive a TIN from those points (the original lidar pointclouds were not available). This could use all of the pointcloud functionality that lives in geotrellis-pointcloud, without the additional burden of installing the PDAL binaries and the required configuration to allow the JNI bindings to work.
There seems to be two paths here:
geotrellis-pointcloud
into subprojects; one that focuses on PDAL IO to and from GeoTrellis types like an RDD of PointClouds, and one that focuses on the algorithms that you can apply to point clouds once they are in the Scala types. This would require a rewrite of the algorithms to work against an abstraction of point clouds, instead of thepdal-jvm
PointCloud
type.geotrellis-pointcloud
project that deals with the algorithms, and separate out ageotrellis-pdal
project that deals explicitly with the PDAL based IO. This separate things based on pure JVM and abstracted point cloud types (that could handle both the line-dissolve use case above and PDAL point clouds)Either path suggests an abstraction of functionality on top of an interface into point cloud types, that can either be served by PDAL types or something like
Array[Coordinate]
.I'll catalog the functionality that I see in geotrellis-pointcloud, that would have to be cleaned up and made generally useful:
geotrellis.pointcloud.raster._
)Looking for ideas on how to do this split, and what should be in GT core and an external
geotrellis-pointcloud
orgeotrellis-pdal
project.