Need to deal with altitude better

[speigg]

When the geolocation api does not provide altitude, we currently fallback on the value 0, which is actually really bad, as 0 is the surface off the ellipsoid, which is not necessarily the ground level at any given geolocation. Instead, we should be using a terrain server. We can probably use the one that Cesium/AGI provides: https://cesiumjs.org/Cesium/Build/Documentation/sampleTerrain.html

We also need to make sure that we make it easy for people to create geo reference frames that have an accurate altitude, so probably want to make a request to the terrain server for each geo reference frame that is created. We can probably add an api that abstracts these details away (Argon.createGeoReferenceFrame(lon, lat)).

[blairmacintyre]

Their terrain is interesting, but there are some limits to their terms of use (for example, I don't know how we would effectively display their required attribution if we were using this continuously). We might use it in the empty reality, for example, and display their notice at the bottom, but I wouldn't want to continuously display it in the live video reality.

Another option is http://mapzen.com which I've been looking at as a possible source of world data (since they filter through the openstreetmap data, and we could use it to build a 3d world reality). They have the ability to fetch elevation tiles, and I don't know if they require a notice like cesium does, but I don't know which of these has more accurate backend data. I suspect cesium does, but I don't know.

I also have no sense as to which of these would make a better 1st person view.

[blairmacintyre]

A more interesting option would be to let the apps do this. This issue came up because the draggable cubes example wants to attach content to the initial location (much like the cube sample does), and when we switch between street view and the empty reality, we get very different altitudes.

Perhaps the draggable cubes example should take the initial LLA, query the cesium server directly, and attach the cubes to "the ground" there? Doing this at the application level solves the "attribution" issue, as the app is responsible for displaying it if it uses the service.

[shukieshah]

I found a free web service (Elevation Point Query Service) that returns the elevation for a specific latitude and longitude -- no API keys/attribution required. The source is The National Map but the only problem is that it only generates elevations for US territories and states.

http://ned.usgs.gov/epqs/

This service would cover US based queries but maybe it can be used in conjunction with other solutions to provide a comprehensive coverage of the globe.

[blairmacintyre]

@shukieshah thanks for the pointer. The "US only" is killer here, but also we can't really use a service that requires a query per location. Other services provide elevation tiles (in various resolutions) so that once you get a tile, you can do all your queries locally, and you can also do things like interpolation between points.

Mapzen.com looks good. There are probably others. I suspect what we need to do is integrate mapzen's tile elevation service into the app itself, such that when the location API returns no elevation value, we can look it up and just use it. I'll talk to them and see what they think about us using it.