Best practices for PMTiles & 3dTiles?

[cholmes]

PMTiles and 3d Tiles have both increased in adoption since we published spec, and our best practices doesn't mention them.

There's a desire to add them to STAC Browser, see: https://github.com/radiantearth/stac-browser/pull/465

But we don't have a clear recommendation for how to put them in STAC. @m-mohr and I have done some small catalogs with them, and we both used 'links' instead of assets. But there are arguments that they should/could be assets. I see a stronger case for PMTiles, as it's a single file and serves as an alternate representation of the data - indeed I've long hoped that sophisticated clients could see a STAC with both PMTiles and GeoParquet and make use of them together, leveraging PMTiles for overviews and GeoParquet for raw data.

I know less about 3d Tiles, but I did get some generated for Planet data and put it in a STAC catalog. I went with 'links' as the main 3d tiles entry point is just a JSON file that then links down to more data (at least from what I could tell), so it felt less like a single asset, more like a link to a set of assets. And I don't think we have other assets that are multiple parts - I believe we require shapefiles to be zipped, and when bands are represented by individual tiffs we link to each specific tiff as its own asset.

I'm not sure if there's advantages for clients if these are assets, or if clients like stac browser are fine to just inspect the links as well as the assets to display them more nicely, which to me is one of the main goals of figuring this out.

[jo-chemla]

Thanks for initiating this discussion. Just gave my point-of-view in the original thread here - I'm both a OGC/3Dtiles producer and consumer so I'll sum-up my 2 cents here. A 3dtiles tileset/dataset has originally been produced as the tiled, 3d representation of a single 3D geospatial asset - see cesium-ion for examples datasets of vexcel or aerometrex over the new-york or sydney areas.

This has been from the beginning a cloud-native-geospatial standard, now adopted by OGC, that was geared towards tiling pointclouds, meshes and object instances collections, very similar to the way COG or COPC are tiled standardized representations of raster/pointclouds.

Individual tiles cannot be consumed without the hierarchy files leading to that file - accumulating matrix transforms for example, refine strategy or geometricError. Isolating a given level-of-detail within the hierarchy would be akin to selecting a given zoom-level in a COG or COPC file to get a ~downsampled, lower resolution of the full-res dataset. There are also two single-file, self-contained 3dtiles packaging (equivalent to COG/COPC, .3tz/.3dtiles) described in https://github.com/CesiumGS/3d-tiles/issues/727#issuecomment-2312984585 which would result in a single-file geospatial asset.

Although less common, 3dtiles can also be a combination/merger of tilesets, the same way one can moisaick 2D COGs into a vrt or output cog, or the same way one can combine copc into another copc or a vpc. This is probably the way Google 3D Cities dataset is produced and updated without reprocessing/retiling the whole asset.

Hence why from our point-of-view, best-practice would be to describe 3dtiles datasets as assets rather than links. Note the mime-type that is sometimes used by the community seem to be application/3dtiles+json

[m-mohr]

@cholmes @jo-chemla For PMTiles and 3DTiles there's a documented way to add them to STAC, see the web-map-links extension: https://github.com/stac-extensions/web-map-links

PMTiles is also already implemented in ol-stac for example.

[jo-chemla]

Thanks for the link to the web-map-links extension. From my point of view, 3d-tiles can be seen as both a single geospatial asset (especially if packaged as a single file indeed, as .3dtiles or .3tz) and a link or server endpoint.

In the meantime, I've made a minor PR https://github.com/radiantearth/stac-spec/pull/1321 to add the Mime Types I've stumbled upon when doing the STAC-Browser asset and links actions PR:

Type	Comment
application/vnd.laszip+copc	COPC Cloud optimized PointCloud
application/vnd.apache.parquet	Apache Geoparquet
application/3dtiles+json	OGC 3D Tiles
application/vnd.pmtiles	Protomaps PMTiles

[m-mohr]

If your primary data is 3DTiles (and you want people to download it, not sure whether that happens) it's indeed an asset (and should additionally be provided as link via the extension).

If your primary data is something else (like a Point Cloud LAZ file? No clue what file formats are used in 3D) and the 3DTiles is an addition to that (primarily for viz), it's better suited as a link, I think.

[jo-chemla]

Thanks for that point. 3D-Tiles is indeed usually a derivative product, that can be consumed as a server endpoint or downloaded as a whole tileset locally for faster viz - via an ecosystem of libraries and tooling maintained mostly by the Cesium team, CesiumJS for the web, QGIS, UnrealEngine, Unity, O3DE, or by other contributors like loadersgl or NASA-AMMOS/3DTilesRendererJS etc.

One can convert to 3D-tiles using open-source tilers for tiling pointclouds (usually laz/las format for pointclouds), or using commercial off-the-shelf licenses for tiling massive meshes (fbx, obj, gltf etc) - we produce 3D-tiles for meshes up to a few 100M triangles. But the primary, massive-mesh data cannot be consumed by any software suite, hence we consider the 3d-tlies as a primary asset. The fact that 3D-tiles tileset.json + tiles directory hierarchy can be packed as a single package file, .3tz/.3dtiles leans towards the same direction that the dataset is a single-file, frozen asset.