Is geoparquet suitable to store point cloud data?

[wiesehahn]

Geoparquet "defines a specification for how to store geospatial vector data (point, lines, polygons)".
There is no mention of point cloud data and I have not seen any implementations. I was wondering if it would be suitable to store point cloud data as well, or which are the arguments against this? Lidar data for example contains X,Y,Z coordinates and additional data per point such as classification, intensity etc. Working with this data often means many filtering steps, and in my understanding the columnar format of parquet could be beneficial.

[rouault]

I have not seen any implementations

PDAL can write Geoparquet: https://pdal.io/en/2.6.0/stages/writers.arrow.html#writers-arrow . Maybe @hobu has comments on how efficient it is

[wiesehahn]

thought about @hobu as well. Probably he can also make a comparison to LAS/COPC. I know GeoParquet has no spatial index yet which would be a drawback for many applications but otherwise how does the the read/process effiency and the compression compare?
If I would like to calculate some terrain metrics for example just X, Y and Z coordiantes of points classifified as ground are needed, as I understand it would be possible to efficiently read just these data points from a Parquet file while I am not sure if this would be possible from LAS.

[hobu]

GeoParquet isn't quite as nice as GeoArrow IMO because you still have the pain of unpacking the wkb and you can't store them with defined precision in the wkb column.

That said, my experiments show the GeoParquet+GeoArrow point cloud file that PDAL currently writes with default settings is about 3x larger than an equivalent COPC file for storing all attributes. I haven't really done a lot of column compression tuning, and PDAL's also storing the coordinates as floats/doubles, which COPC isn't doing. There's plenty more work to do to make it nicer, but I just pushed out the preview to try to see if there was interest.

It would be very nice to be able to store the COPC index as part of the metadata per row-group, but the typical recommendations for the sizes of those are much larger than a typical octree node in COPC. With some experimentation and design, we could come up with something however.

[paleolimbot]

I wonder if (Geo)Parquet might be able to help in a situation where part of your workflow is non-spatial, particularly at the beginning. The amount of engineering effort put in to effectively query a Parquet file (or files, often in cloud storage) for non-spatial queries is massive and could be worth leveraging. That's probably true even for a wkb-encoded geometry column (although I'd like to see GeoArrow in the spec for exactly this use-case).

[wiesehahn]

If I got this correct, with the upcoming spec 1.1 you do not have to encode geometries as WKB anymore.

[kylebarron]

Correct