This document proposes a GeoPackage standard for storing lidar point cloud data in a tile-based format. Key points: - It models point cloud data after the existing raster tile-based model in GeoPackage, storing point features in a new "pctiles" data type and adding a table to describe point dimensions. - The proposal reuses many of the existing GeoPackage tables like tile matrix set and tile matrix but removes fields that don't apply to point data like pixel dimensions. - It includes conventions for the blob contents storing each point as packed native data types, optional compression, and new fields in the user data table for things like point count per tile. - The implementation is currently limited

1. GeoPackage for
(lidar, top-down, tile-based)
Point Clouds
OGC TC Meeting
Michael P. Gerlek (RadiantBlue)
mpg@flaxen.com
1 June 2015
RadiantBlue 15 June 2015

2. Summary• No magic
– “Do the obvious thing”
• Yes, it’s actually a 2D model, not 3D
– LAS-centric
• Follows from raster tiling model
– Added “pctiles” data type
– Added new table for point dimensions
• Implemented in PDAL
5 June 2015 RadiantBlue 2

3. SQLite, etc.
• No changes to underlying tooling
• Not using spatial indexing
5 June 2015 RadiantBlue 3

4. Spatial Ref Sys Table
• (no change)
5 June 2015 RadiantBlue 4

5. Contents Table
• New data type: “pctiles”
5 June 2015 RadiantBlue 5

6. PCTile Matrix Set
• New table
– Taken directly from (Raster) Tile Matrix Set
• But no new fields
• Question
– Should this indeed be a separate table?
– Or should current (raster) table be overloaded
to allow point cloud tiles?
5 June 2015 RadiantBlue 6

7. PCTile Matrix
• New table
– Taken directly from (Raster) Tile Matrix
• Removed columns that don’t make sense for point
clouds (pixel space)
– tile_width, tile_height (in pixels)
– pixel_x_height, pixel_y_height (spatial)
• Question:
– Here too, could reuse existing (raster) table
– And just ignore the pixel field
– Or just redefine/overload tile_width/height
5 June 2015 RadiantBlue 7

8. “User Data” Table
• Added two new columns
– num_points
– child_mask
• Both helpful to clients (but not required)
– “How many points are available to be pulled
from the database for this tile?”
– “Which of this tile’s four child tiles are
available?”
5 June 2015 RadiantBlue 8

9. Blob Contents
• Packed set of points
– Each point is a packed set of dimensions
– Stored as native data types
• Example
– X0, Y0, Z0, T0, X1, Y1, Z1, T1, …
– f64, f64, f64, u64, f64, f64, f64, u64, …
• Optional compression via lazperf
– Standalone compression lib (think gzip)
– Derived from LAZ codec, datatype-aware
– (should be signaled in matrix set table or in metadata)
5 June 2015 RadiantBlue 9

10. Data Columns Table
• (not used)
5 June 2015 RadiantBlue 10

11. Metadata Table
• No schema change
• md_scope: “dataset”
• md_standard_uri: “LAS”
• mime_type: “text/plain”
• Need to define a convention
– (Or not)
5 June 2015 RadiantBlue 11

12. Metadata Reference Table
• No schema change
• reference_scope: “table”
• column_name: “table”
• row_id_value: “NULL”
• md_parent_id: “NULL”
5 June 2015 RadiantBlue 12

13. PCTile Dimensions Table
• New table
– Need to describe the “contents” of a “point”
5 June 2015 RadiantBlue 13
table_name TEXT NOT NULL PK,FK
ordinal_position INTEGER NOT NULL PK Lexical ordering of
the point structure
dimension_name TEXT NOT NULL “X”, “gps_time”, etc.
data_type TEXT NOT NULL “double”, “uint32”,
etc.
description TEXT
minimum, mean,
maximum
DOUBLEs Because histogram
stretch

14. Implementation Limitations
• Power-of-two zoom levels only
– And must start at 0
• Metadata protocol assumes LAS
– Quick hack
• Compression option not yet supported
• PDAL repo, rialto-tiling branch
5 June 2015 RadiantBlue 14

15. Some Minor Errata (OGC 12-128r10)
• Requirement 11
– A bit hard to parse – suggest “record” clauses be separated by semicolons
• Overloading of min_x, etc.
– Section 1.1.3.1.1
• Suggest explicitly stating that the bounding box is of the data and not the tile matrix set
– Section 2.2.6.1.1
• Suggest explicitly stating that the bounding box is of the tile matrix set and not the data
(although it is clear in subsequent 2.2.6.1.2)
• Table 14
– Reference to table 14 should be to table 15?
• Table 16 (column 1, row 4)
– Should be “row_id_value1” (superscript typo)
• Table 17
– Addition: table_name is an FK
5 June 2015 RadiantBlue 15

16. Thank you.
RadiantBlue 165 June 2015