Replace deprecated geofox.ai with NASA-AMMOS 3DTilesRendererJS

[jo-chemla]

viewer.geofox.ai is now deprecated, this PR replaces it with NASA-AMMOS/3DTilesRendererJS for OGC 3D-tiles STAC items.
Note geofox was not exposed, and 3dtiles-renderer-js was not either as part of this PR, so the default is still cesium fullsize standalone for such assets

[m-mohr]

"example" and "bundle", that looks suspicious. Is that a permanent URL and meant to be used in production?

[jo-chemla]

These are indeed examples based on the underlying lib, 3DTilesRendererJS, developed by Garrett Johnson at NASA-AMMOS. It's one of the most advanced js 3d-tiles rendering lib, along cesium, the major difference being that it's compatible with threejs.

This example is probably going to stay in place because it makes it easy to consume any 3dtiles via their url.

In case it makes more sense, I can also switch to - or add - another viewer, iTowns, developped by french national geographic institute with the following URL schema - but again, an example url which arses url-query param tileset-url : https://www.itowns-project.org/itowns/examples/3dtiles_loader.html?tileset=URL

[m-mohr]

Okay, I guess I'm fine with any of the solutions as long as NASA or ITowns are fine with us pointing to their instances.

[jo-chemla]

I think they would be fine with this use-case, as this is simply using existing urls to display tilesets with each their own viewer/library, without a real load on the respective servers - no middleware proxy, assets fetched from where they reside.

@gkjohnson would you be open to use https://nasa-ammos.github.io/3DTilesRendererJS/example/bundle/index.html?tileset=URL within STAC Browser? Live demo here, it is a viewer to display STAC/Spatio-Temporal Asset Catalogs, an OGC standard to publish static/dynamic collections and catalogs that store geospatial assets (eventually implementing extensions) like satellite imagery COG, server endpoints like WMTS, COPC, but also OGC 3d-tiles.

Probably the same quesiton for @gchoqueux or @Desplandis regarding https://www.itowns-project.org/itowns/examples/3dtiles_loader.html?tileset=URL

[gkjohnson]

I'm not entirely sure of what STAC-browser is or what the context for this PR is but at a basic level the examples in the 3d tiles project are really just intended to demonstrate the functionality of the library. If people want to link to them that's fine but they have to prepared for those links to break. Unfortunately I'm not prepared to have to consider "breaking changes" for example links or query parameters, etc if other projects want to use them.

I think there's utility for a nice, general, and complete standalone 3d tiles viewer that can infer whether to use globe controls or not, allow for camera navigation, load multiple tile sets, and other inspection of the data but it's not something I can invest time in at the moment.

I've made NASA-AMMOS/3DTilesRendererJS#1070 to discuss some possible types of tile set validation that can be done to help ensure better data sets for rendering. And it's maybe a bit different than the type of viewer we're talking about here but while I haven't used it I've seen that @replash has build a very nice generalized 3d viewer for the web and OSX that seems similar to what we're talking about. I'm not sure what the plans are for that project but I've thought it might be nice to add 3d tiles to that project at some point. Or maybe there's some inspiration to be taken, at least.

That's maybe a bit more than you asked for but hopefully that answers what you were looking for 😅

[m-mohr]

Thank you for the detailed answer. Very helpful.

@jo-chemla I think this would indicate for me that we should not link to the NASA viewer unless there's a more stable version of it hosted somewhere.

[jo-chemla]

Thanks both for the feedback.

• indeed I switched to using this github website url provided by 3DTilesRendererJS when the geofox.ai 3dtiles viewer went down, anticipating the url formatting would not be subject to too frequent changes as this is the default 3DTilesRendererJS example with hash encoding of a tileset to load. In case it would break, it would therefore probably be the responsibility of the STAC-Browser user noticing that breaking change to find an alternative and PR, but I completely understand this could put some burden on you Matthias as the STAC-Browser repo active maintainer.
• And Garrett, thanks for all the details. It does look indeed like the replash 3d-viewer could be a great alternative if it ever supported 3DTilesRendererJS - could open up an issue to see if there is momentum around this, very impressive modular viewer implementation. This threeepipe can also can be useful as an alternative to f3d.app, used to load standard static meshes (obj fbx gltf etc) using https://threepipe.org/examples/tweakpane-editor?model=URL. And as always, thanks for all these very precious insights.

If you feel like it Matthias I can switch from the NASA-AMMOS/3DTilesRendererJS to the Cesium Sandcastle implementation in the meantime, for that PR to fix broken geofox 3D-tiles viewer!

[m-mohr]

Thanks @jo-chemla . Would that be something different than the existsing implementation?
https://github.com/radiantearth/stac-browser/blob/main/src/actions/assets/Cesium.js
Maybe we just remove geofox and keep Cesium for now, that at least is one viewer for 3D Tiles...

[jo-chemla]

Thanks for getting back, that's perfect. Actually, the NASA importer is already commented out within linkActions and assetActions, so this should be good to go. I can remove the NASA_AMMOS_3DTiles.js asset and link actions if you want as well before merging.

The only difference between Cesiumjs sandcastle and NASA-AMMOS/3DTilesRendererJS is related to implementation, and the fact that Garrett's take is usually easier to configure, faster to load tilesets, and easier to extend with plugins. If anyone is interested, I've also opened a thread repalash/threepipe#13 on ThreePipe to track integration of 3dtiles within their viewer framework.