Update approximateTerrainHeights.json

approximateTerrainHeights.json was generated from the STK World Terrain as of #3903, with all of the improvements made to Cesium World Terrain, we should regenerate this file.

Long term plan is still for this data to be accurately provided by each terrain provider, but approximateTerrainHeights.json will always be a good fallback for servers that don’t have the information.

[hpinkos]

@thw0rted thanks for pointing that out, it doesn’t look like we have an otherwise for loading the approximateTerrainHeights.json file https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Core/ApproximateTerrainHeights.js#L58-L60

[thw0rted]

This was actually easier than what I suggested before, because if you have a JSON file you can turn it into a valid ES6 module by just adding export default at the beginning. That let me throw together this build real quick. It builds and runs without apparent issue, with two caveats:

• The tests for StaticGroundGeometryColorBatch and StaticGeometryPerMaterialBatch fail but only if run in the whole suite – running just those two specs works fine. This suggests that some earlier test is manipulating the ApproximateTerrainHeights module (it’s the only one I changed), but I haven’t been able to figure out how
  • ETA: I realized that I had been grepping through Source/ without looking at Specs/, and it turns out that tons of tests poke around in the guts of ApproximateTerrainHeights. Even ignoring my suggestion from this fork, maybe those interactions should be replaced with a mock?
• It looks like the non-ES6 version of the createGroundPolylineGeometry worker inlines all its dependencies (recursively), including ApproximateTerrainHeights, which means that it gets its own (bundled) copy of the data. In a non-ES6 environment, I don’t have a good solution for this. (I had made a snide remark here but it looks like Firefox still hasn’t gotten onboard with ES6 modules in a web worker, so, oops?)