Thanks for the feature request (and for trying ion). As you already stated, we currently only support the .terraindb schema (which is actually a sqlite3 database) for existing processed .terrain files. I don’t believe this format is formally documented anywhere (it is the output of the STK Terrain Server product created by AGI). I’ve written up this issue: https://github.com/AnalyticalGraphicsInc/cesium-ion-community/issues/14 for us to investigate documenting the schema or providing alternative ways to upload existing tilesets.
That being said, if you still have the original source data, I recommend trying to upload that to ion instead. The ion terrain processor should definitely create the most optimized and efficient tileset compared to other tools available.
Thanks,
Matt
Thanks for the additional information.
Sorry if some of this is stuff you already know, but I just wanted to make sure we are on the same page.
We would love for ion to support your source data format directly, assuming it’s in any kind of standard or generally available spec. (and that uploading your source data directly is an option). For example, we’ve had some requests for BIL files and definitely plan on supporting them in the future.
If you opt to stick with .terrain export from your tool, keep in mind that Cesium can’t load individual .terrain files themselves, it load an hierarchy of .terrain files and accompany layer.json. If you’re goal is to view a large amount of terrain in Cesium, then a terrain tileset is definitely the way to go and I think the issue I wrote up has you covered assuming your tool can export it.
If you are only interested in small areas of terrain where the filesize is small enough that you don’t need LOD or streaming, you could also consider exporting to a glTF file, which is a more traditional 3D model format but optimized for the web. It doesn’t address the level of detail or scaling issues needed for streaming terrain, but may fit your use case if it’s only a small area. Cesium has native support for glTF. Support for uploading glTF files (or other source data such as obj and collada) is currently in beta and will hopefully be available in ion to all users later this year.
Hope that helps clarify some thing, I’m happy to answer any additional questions you might have.
Matt
Hello again!
Based on your answer, we are definitely going to look more into what approach would be better for smaller data sets.
One option I suppose would be to export small data sets as geotifs which are already supported. But we will definitely have need for larger sets, covering a wide area and different LODs, so anything that comes from the issue opened above will be surelly usefull!
Now, I have two other questions that are loosely related to this topic and I am not sure if they should be here or on different posts, but let's introduce them anyway and if then you think I should move them to their own topic I will:
1. as far as gltf 2.0 files are concerned, we can already export 3D models to the format, but when it comes to uploading our results to ion we get some unexpected errors. The file have been tested against Visual Studio Code's validator and the online validator from http://github.khronos.org/glTF-Validator/ and they show no errors. In fact, the viewer in VScode renders the results just fine. When I try to upload them on ion though, after they are uploaded and processed I get an error: "There is an unexpected error and we are unable to view your asset."
2. One thing I haven't figured out yet is whether there is a public API for ion or if usage is done through the web interface only. For example could we upload the files by directly calling on the some REST endpoint?
Thank you in advance!
Hey there,
Concerning my sub question #1 above, I searched some more and I did find this issue (sorry I didn't check the Issues page before) https://github.com/AnalyticalGraphicsInc/cesium-ion-community/issues/2
But as far as question #2 is concerned I still haven't found anything in my searches. Hope I didn't miss anything again.
Thanks!~
Thank you for your reply!
I am glad to know the issue will be looked into and I will follow it closely.
For clarity let me mention that, in this specific case, we don't have the data in some of the supported formats (such as tif etc), but they exist as georeferenced 3D TINs within another environment (where a user may actually tinker with the terrain topology), and the purpose was to export these directly to a quantized-mesh format.
Does this sound like a good plan, or should we look more into other methods for approaching this?
Thanks in advance!