Can I safely reduce the resolution of the numbers in approximateTerrainHeights.json?

I haven’t been able to find more details, but it appears the numbers in approximateTerrainHeights.json are minimum and maximum elevations in meters. Sometimes to 8+ decimal places. Is it save to reduce these to 2 decimal places (cm) to massively reduce the size of this file?

I would say “sure” with the caveat that it depends on what you’re doing. For example, from Gabby’s response here, it looks like if you’re not clamping anything to terrain you could safely emit the whole file. I think it would just affect the precision of objects clamped to terrain.

Further digging into it, from this GitHub issue it looks like it’s mostly used as a fallback if the terrain provider doesn’t provide this information. So if you’re using Cesium World Terrain I think it can do without it as well.

On further inspection, I think it still does use in various places (see ). So I think reducing the precision of the numbers will just reduce the precision of things using it.

Actually, rounding to 2 decimal places is a great idea and something we should have done when we first created this file. Even rounding to whole numbers or 1 decimal may be okay (if it further significantly reduces file sizes). You just need to make sure you round down for the minimums and up for the maximums. This file needs to be regenerated anyway, so I’ll write up an issue for us to do this at the same time.

Rounding here will actually have no impact on visualization or performance, this is a good change all around.

Thanks! Downloading this file was taking 700ms for me. I ran this little script to round the numbers:

#!/usr/bin/env ruby
require 'json'

filename = ARGV[1] || "./dist/Assets/approximateTerrainHeights.json"
objects = JSON.load(
objects.each do |k,v|
  objects[k] = {|i| i.round }

puts JSON.dump(objects)

And used webpack to copy it over the `dist/Assets/approximateTerrainHeights.json` file whenever we compile our app, and it reduced the loading time to just 30ms, drastically reducing our time to first draw :slight_smile:

That sounds like a pretty significant optimization! Would you care to open a pull request to contribute this back to Cesium? The contributing guide is a good place to start.

This is the GitHub issue that had discussion relevant to this:

Iw ould just make sure you round minimums down and maximums up to make sure it’s still a valid approximation.

Hi Omar,

Sorry for the late response, I’ve made a PR here:

Kind regards,