More actions for cesium (3Dtiles geofox), potree, static meshes (f3d), pmtiles, geoparquet

[jo-chemla]

Following discussion thread here, adding more actions for the following file types:

• OGC 3D-Tiles via Cesium Sandcastle action
• Potree and COPC via a standalone potree app
• single-mesh formats like gltf, obj via 3dviewer.net

Will add protomaps pmtiles probably soon. Not completely tested, still a draft for getting directions as to how things look at the moment.

[m-mohr]

Thanks! Do you have some example items/catalogs/... which I could test this with? I have examples for COPC, but not for the other file formats...

[jo-chemla]

Hi, thanks for getting back!

• Just added the simple protomaps pmtiles link/action.

Our (iconem) public STAC catalog at the moment only refers to some of the implemented viewers - test url here for local dev env running), and for other asset types & formats I don't have public data yet:

• Potree / COPC / ept: COPC USGS 3DEP ept and EPT LoLa Lunar Orbiter LoLa Lunar Orbiter sample USGS Astrogeology STAC LoLa Lunar Orbiter
• pmtiles protomaps: could not find a public reference implementation

I only have private assets for the two below at the moment, will try to open access to one soon and report back.

• OGC 3D-Tiles via Cesium Sandcastle
• single-mesh formats like gltf, obj via 3dviewer.net

[jo-chemla]

Note I also tried these DroneDB (~WebODM wrapper) public STAC catalogs (a bit slow) from pierotofy brighton-beach and cozy2963 3dhouse, which include static mesh obj files, but the mesh url seems to be incorrect.

Also most of the above tests were made with the Allow-Cors plugin switched on to avoid Cors-policy issues.

[jo-chemla]

@cholmes pointed on linkedin to a open-skysat-data Planet catalog which stores 3D-tiles tilesets as external links (Additional Resources -> 3D Tiles for the Angkor Wat stac-browser page) for the moment rather than STAC items, but they might change that soon to make the 3dtiles datasets standard STAC items. This would make it another public STAC of 3D-tiles items while we (iconem) have not published a public collection with 3Dtiles (and in a more distant future static meshes, ).

As for pmtiles, still could not find any catalog hosting them. The VIDA.place implementation and deep-dive article points at an implementation that stores pmtiles and parquet assets, but it seems to be private.

Ps for static meshes, there is a small bug in 3dviewer url parsing implementation which makes it to not load files passed via url, see discussion here

[cholmes]

@cholmes pointed on linkedin to a open-skysat-data Planet catalog which stores 3D-tiles tilesets as external links (Additional Resources -> 3D Tiles for the Angkor Wat stac-browser page) for the moment rather than STAC items, but they might change that soon to make the 3dtiles datasets standard STAC items. This would make it another public STAC of 3D-tiles items while we (iconem) have not published a public collection with 3Dtiles (and in a more distant future static meshes, ).

I wasn't really saying we might change it - more that if the community does coalesce around doing it as assets instead of links then I'd update it. Probably should do something like make a PR in the stac-spec best practices doc at https://github.com/radiantearth/stac-spec/blob/master/best-practices.md#common-media-types-in-stac that says what media type to use for 3d tiles. But does it need to be an asset for STAC Browser?

As for pmtiles, still could not find any catalog hosting them. The VIDA.place implementation and deep-dive article points at an implementation that stores pmtiles and parquet assets, but it seems to be private

The fiboa STAC's generated by @m-mohr have pmtiles for example https://data.source.coop/fiboa/austria/stac/collection.json and more at https://beta.source.coop/fiboa/ He did it as links too. I think I see more of an argument to do PMTiles as an asset than 3d tiles, mostly because 3d tiles isn't one file - you're linking to the base file that then links to the actual data. I'll raise an issue in stacspec to discuss, we should get to a recommendation for people on what to do.

[jo-chemla]

Hi there, thanks for the fast reply and sorry for the misunderstanding. Indeed the community has to discuss this, and a PR to the best-practices.md doc on common-media-types-in-stac might be a great way to introduce this discussion. Should I make an attempt at it? Note that there are not necessarly mime-types for every tileset type described in this stac-browser PR since eg 3dtiles are based on standard json+gltf/glb+textures filetypes - although some use the application/3dtiles+json mime type.

From my point-of-view, the reason that 3dtiles datasets could/should be marked as assets is guided by the fact that such datasets are a self-contained geospatial representation of the earth at one point in time. There are even single-file, self-contained COG/COPC 3dtiles packaging equivalent (.3tz/.3dtiles) described in this discussion which would result in a single-file geospatial asset. Even if 3dtiles is a collection of tiles, they don't make sense alone or without the complete hierarchy leading to each tile - the same way for a 2D TMS/XYZ representation of a geotiff, a single tile or subset of tiles would not make sense without the whole tileset.

We produce 3dtiles for various places on earth, be it monuments or entire cities, and consider them as geospatial assets the same way a pointcloud COPC, a geotiff COG, or a static mesh file, is an asset - each of this dataset types is one byproduct of the 3d-scan processing pipeline. The fact that it is an asset for STAC-Browser, or the qgis plugin, or any STAC reading library means 3dtiles datasets can be imported the same way copc or cog would be imported within an existing project or scene.

I can see cases where it would make less sense to consider 3dtiles as a single asset, and that is when it is shared as an endpoint to a collection of assets - for example, the Google 3D Cities endpoint. This might make more sense to consider such collections as web-map-links STAC extension, or a link to the endpoint, because the underlying data is a combination of several acquisition and processing. But both points might still hold, this can still be considered a geospatial asset, the same way a mosaick of several input images can still be considered a single asset.

Plus, thanks a lot for the fiboa pmtiles catalog, will be helpful to test this PR against! pmtiles assets are actually also broadcasted as links at the moment, so cannot test it out yet. Will see if I can find a standalone app for ingesting parquet files though in the context of this PR!

[jo-chemla]

Following the discussion, I realized how links actions can be created and used within stac-browser and then created them for protomaps and 3d-tiles. I also added your geoparquet.info viewer to geoparquet assets actions. So the following STAC catalogs can be used to test against this PR, and all works great - so will remove the draft, I think it is ready for review:

Asset actions:

• Geoparquet: fiboa STAC
• COPC / Potree / ept: COPC USGS 3DEP ept and EPT LoLa Lunar Orbiter LoLa Lunar Orbiter sample USGS Astrogeology STAC LoLa Lunar Orbiter

Link actions

• pmtiles protomaps same fiboa STAC
• OGC 3D-Tiles via Geofox.ai rather than Cesium Sandcastle Planet catalog

Note pmtiles protomaps were not tested as assets but as links. For OGC3dTiles, we do store them as assets rather than links on our catalog, but it is still private, both asset and links 3dtiles works good. I renamed CesiumSandcastle files and components to OGC3dTiles since the asset action now uses Geofox.ai. And finally regarding 3dviewer.net, there is a bug when parsing mesh url as urlparam, discussions to resolve it are here.

[m-mohr]

Thanks. It may take me some time to review this (deadlines coming up!), but want to let you know I've seen this.

I may extract the geoparquet.info implementation for now as I think it's not really ready for general public usage yet.

[m-mohr]

Some improvements needed for URL parsing and some code seems unused. Otherwise LGTM. Thanks, and sorry for the long wait.

[jo-chemla]

No worries for the long wait, totally understandable! Just replied to your comments and will quickly edit the PR accordingly!

[m-mohr]

Thanks, let me know once you are finished :-)

[jo-chemla]

Just did the edits and resolved the corresponding comments. 3 last things:

• Regarding potree metadata.json, cloud.js filename, how do I check if the pointcloud extension is implemented?
• is it possible now to use geoparquet.info or you still consider it as experimental?
• Note I'm duplicating a bit of code in assets and links for Cesium/Geofox.

[m-mohr]

Thanks for the updates.

• Regarding potree metadata.json, cloud.js filename, how do I check if the pointcloud extension is implemented?

It seems that's not possible yet as there's no pointer from the asset to the actual "parent" STAC entity.
Will be possible "soon", once I updated to use stac-js. But that's nothing we have available at hand.
That also means we can't check whether related assets are available.
I'm wondering whether it's really needed to have these links for the metadata documents? Wouldn't you just need those viewers for the main data file? I'm new to point clouds, but it sounds a little weird from an external perspective...

• is it possible now to use geoparquet.info or you still consider it as experimental?

Actually, no progress since last time. So still experimental.

• Note I'm duplicating a bit of code in assets and links for Cesium/Geofox.

Yeah, I saw that. Not ideal, but fine for now.

[jo-chemla]

Thanks for the feedback, understood for geoparquet.info and ~minor duplication in assets/links actions.

Regarding potree, these metadata documents are actually the pointers to the data itself. Viewers like potree, giro3d (soon loadersgl) require either endpoint to the cloud.js or metadata.json to load the dataset. Point coordinates and attributes are then stored in a /data/r020.bin folder for potree v1, and potree v2 expects two companion files to metadata.json, hierarchy.bin & octree.bin

These files are roughly equivalent to the tileset.json file of the OGC 3Dtiles spec.

[m-mohr]

I see. Let's add a todo comment in the code that this should be checking for related assets or the point cloud extension in the future once stac-js is implemented. And as this is pretty "greedy" for now, let's disable the action for now so that others need to opt-in when they deploy their instance.

Otherwise LGTM. I'll merge this once 3.3.0 is released as it's feature-freeze, but will merge it afterwards for 3.4.0. Thanks for the effort and responsiveness today as well.

[jo-chemla]

Thanks, just merged your last comments re Potree.
Ready to merge from my point-of-view, thanks for all the feedback!