Best method of returning tile availability maps from the server


I am trying to work on a “sparse” set of terrain tiles for Mars science work (using the Cesium-martini client-side mesh generator against terrain-rgb images). Basically, I am working with a terrain dataset where all areas have z <= 7 data but a few select regions have data up to z ~15.

I’d like to ship a quadtree of tile availability from the server that can be efficiently parsed using the getTileAvailability function on a terrain or imagery provider, to avoid requesting nonexistent tiles as much as possible. I know there has been some work in this regard for 3d tilesets, but I couldn’t tell if there were approaches that carried over to imagery datasets there.

Do any of you know of the best techniques to transport and utilize such tile availability maps? Or any examples of this in use? I can’t imagine that this hasn’t come up before, but previous solutions have so far eluded me…


Hi @davenquinn,

Thank you very much for your questions! Unfortunately, I do not have very much experience with transporting the tile availability maps that you are referencing. I am going to check in with the rest of our development team - we will reach out if there are any relevant updates. In the meantime, community input is welcomed!

All the best,

Hi @davenquinn , thanks for the question!

You may know this already, but the terrain engine has its own tile availability structure that is bundled in the metadata section of quantized mesh. The availability structure is not well documented but essentially it’s a list of available tile ranges per level in the tree. It can be reverse-engineered from the CesiumTerrainProvider source code in case I got the details wrong. As far as I know imagery layers will check the terrain availability before deciding to fetch imagery tiles, so per-imagery availability could be tricky.

Hope that helps!

1 Like