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.

[jo-chemla]

Thanks for getting back, and of course no worries, merging this PR can wait! I've just removed Geoparquet from the assetsActions config - but kept the ./src/actions/assets/Geoparquet.js file in case it will be useful once geoparquet.info is ready for public use.

I'm also considering changing the viewer for 3D static meshes from 3dviewer.net to f3d.app, for which I just implemented a PR to load models passed as url-params. As soon as it is merged I'll update the 3D-viewer asset action.

[jo-chemla]

Just updated the 3d mesh viewer (from 3dviewer.net to f3d.app/web) since my PR for f3d.app to support url-params has just been merged, because it is more resilient at parsing mesh extension (via either url extension, response contentDisposition header or user-provided extension)!
This PR is ready to go from my side, but no need to rush!