Table of Contents
The pgPointCloud extension stores LIDAR point cloud data in PostgreSQL using two static types: pcpoint, a single multi-dimensional point whose dimensions are described by a schema stored in the pointcloud_formats catalog table; and pcpatch, a compressed batch of pcpoint values that share the same pcid (schema id). Each schema fixes the dimensions present (X, Y, Z, Intensity, …), their numeric type, scale, and offset.
MobilityDB lifts these types into the temporal world via tpcpoint (a moving LIDAR/GPS sensor) and tpcpatch (a time series of compressed point clusters). It also adds set types pcpointset / pcpatchset and the spatiotemporal bounding-box type tpcbox. A complete reference for the static pcpoint and pcpatch types is given in the pgPointCloud documentation; this chapter covers MobilityDB's additions on top of pgPointCloud.
To use the types described here, MobilityDB must be built with the POINTCLOUD=ON CMake option. On such a build the generated mobilitydb.control declares requires = 'postgis, pointcloud', so a single CASCADE creates the full stack:
CREATE EXTENSION mobilitydb CASCADE; -- NOTICE: installing required extension "postgis" -- NOTICE: installing required extension "pointcloud"
Creating the extensions by hand in the wrong order, without CASCADE, raises a missing-type error.
Both tpcpoint and tpcpatch support the standard MobilityDB binary I/O through asBinary / tpcpointFromBinary / tpcpatchFromBinary and through PostgreSQL's COPY ... (FORMAT BINARY). The encoding carries the pcid of each value beside the dimension payload and, whenever the encoding backend knows the schema XML for that pcid, the schema itself, so a value dumped from one cluster imports into another that has never seen the pcid.
Every pcpoint and pcpatch value carries a pcid that resolves to a schema, which states the dimensions the value holds (X, Y, Z, …), the numeric type each is stored as, and its scale and offset. The schema is stated in SQL, in two tables: pointcloud_schemas holds what a schema states as a whole, and pointcloud_dimensions one row per dimension. A minimal 3D schema, every dimension stored as int32_t at unit scale:
INSERT INTO pointcloud_schemas (pcid, srid, compression, description) VALUES (1, 4326, 'none', 'Minimal 3D schema'); INSERT INTO pointcloud_dimensions (pcid, dim_no, dim_name, interpretation, dim_scale, dim_offset, active, description) VALUES (1, 1, 'X', 'int32_t', 1, 0, true, 'Easting'), (1, 2, 'Y', 'int32_t', 1, 0, true, 'Northing'), (1, 3, 'Z', 'int32_t', 1, 0, true, 'Elevation');
The size of each dimension and its offset within a point are absent because they follow from the interpretation, and the X, Y, Z and M dimensions are absent because they resolve from the names. The dim_no column states the order the dimensions are stored in, so it does not depend on the order the rows are inserted in, and dim_name is the name they resolve by. No column name needs quoting in any host these tables are materialised in. A schema is global to the database and usually registered once, at fixture-load time; the SRID is per schema and is inherited by every value carrying that pcid.
A database whose schemas are already registered in the pointcloud_formats catalog of pgPointCloud, as an XML document, keeps working: that catalog is read for a pcid that the two tables above do not state.
Mixing schemas is rejected at construction time: a tpcpoint sequence whose instants carry different pcid values cannot be built, and the same holds for a pcpointset and a pcpatchset. The schema is what gives the dimensions their meaning, so a value mixing schemas would carry coordinates nothing can interpret.
Three helpers answer what a pcid names without a value of that schema in hand and without depending on the table layout. Each answers NULL for a pcid no schema states.
Return the spatial reference system every value of a schema is expressed in
pointCloudSchemaSRID(integer) → integer
SELECT pointCloudSchemaSRID(1); -- 4326
Return how a patch of a schema is stored
pointCloudSchemaCompression(integer) → text
SELECT pointCloudSchemaCompression(1); -- none
Return how many dimensions of a schema hold values
pointCloudSchemaNDims(integer) → integer
SELECT pointCloudSchemaNDims(1); -- 3