REST API: Terrain Tile not found for zoom level

Greetings,

I am trying out ion’s REST API.
Specifically trying to download CWT terrain tiles (with the purpose of rendering them), but I’ve hit a wall.

I have an ion acount set up, I have included Cesium Wold Terrain in my Assets, and created an access token with the following permissions:

  • assets:list
  • assets:read
  • geocode
  • profile:read

With access to the following assets:

  • Bing Maps Aerial
  • Cesium World Terrain

When I attempt to download a tile with zoom level of 7 or above, for example https://assets.cesium.com/1/13/9280/2390.terrain,
I get a 404 response:

Error:
Code: NoSuchKey
Message:The specified key does not exist.
Key: assets/1/0/13/9280/2390.terrain

I have attempted this both from C# code and directly via Postman.
First I make a request at /v1/assets/1/endpoint with the above mentioned access token and then I make the tile request with the new access token provided by the response.
In C# I get the tile XY coords by using a GlobalGeodetic implementation I have and in postman I just use this example from sandcastle to view Tile coordinates and request specific ones.

In both cases I receive a 200 OK reply along with a tile for very small zoom levels, but 404 for anything at 7 or above.

Am I missing something in my calls? Does this have something to do with my token’s access? Is it that CWT does not have coverage at the areas I am requesting (I have tried various areas of course, even in London, with similar results)? Or is it something else entirely?

Thank you in advance,
regards,
Aristotelis

Have you confirmed that you can access https://assets.cesium.com/1/layer.json ? If so, your token and authentication etc are all working. You should be able to access that layer.json as an entry point to tell you where all the tiles are. You may need to append ?version=1.2.0 as stated in the layer.json.

Otherwise it sounds like that specific terrain tile at that level may not exist. You should try with a terrain tile you know exists (which you can get from looking at the network tab in CesiumJS) like https://assets.cesium.com/1/6/26/49.terrain.

Just for anyone else working on something similar I wanted to clarify that while the Cesium ion terms of service do not allow offline use of data from Cesium ion, you’re more than welcome to request content to render it in different engines through the REST API! The general rule of thumb here is your application should follow the same rules as a web browser. You’d need to re-request the data any time you re-launch your application, and caching the same way a browser would is OK.

I am curious what kind of application you’re rendering Cesium World Terrain in! Do you have a quantized mesh viewer in C#/are you writing one from scratch?

Hello Omar,

First of all, thank you for your quick reply! Much appreciated!

You are correct in that when I request a tile by copying the link from the Network tab in CesiumJS I do get a result!
And I see now what the problem is, although I am not sure how to fix it yet.
You see, I based my calls on the assumption that tileXY values at a specific zoom level would be the same with the values shown in the Sandcastle example I posted above, but they are not, the Y values do not allign.

For example at Lat: 37.906948 Lon: 23.009550 L: 12, the values shown in Sandcastle are X: 4619 Y: 1185 while in Network tab I get a request for X: 4619 Y: 2910.

It seems I have missunderstood the tilling system, but I am not sure exactly where at the moment. I am going to look into it, but any advice is welcome!

As for the viewer, I am just experimenting with something simple at the moment, nothing definite yet!

Hello again Omar,

It seems I found what my mistake was. I had assumed that the tile XY I saw at the Sandcastle example already had its origin at bottom left and that my implementation of global geodetic (from here) also considered that.

But while my results did align with the coordinates shown in the sandcastle example, they did not align with the actual terrain tiles, because my assumption about the origin was wrong.

So I had to do a numberOfYTilesAtZoom - Y - 1 to get the proper value.

Honestly I am a little confused with the conversion and the various tilling schemes, but I can see now it was a silly mistake, since the fact that the origin was different than what I thought should have been obvious by just looking at the numbers! :sweat:

Thanks again!