altitude

Mapzen altitude tiles in Google Earth

October 24, 2016

A couple of weeks ago we set up a server that allows you to view the NOAA’s post Hurricane Matthew aerial imagery in Google Earth. The imagery comes from the NOAA’s map, which provides the data in tiles. For more on how tiled maps work see this post.

The experiment worked better than we expected, so today we are expanding it to use Mapzen’s altitude data, which we have previously used for drawing contour lines.

To see the results, download this KML file.

It is not perfect, and you will notice the imagery shift slightly north or south as you zoom in. This is because the tiles are in the Mercator map projection which stretches the map in the north-south direction, especially towards the poles. However, this effect is less significant as you zoom in.

Weird altitude effects in Google Earth

September 9, 2016

Yesterday we made some Google Earth tours of various US parks. We recorded the tours using Google Earth’s built in ‘Record a tour’ button on the tool bar and then navigating with a SpaceNavigator 3D mouse. Everything seemed fine until we played back the tours and found that some of them have bumps in them and occasionally some have quite severe up and down jitter. We found that these effects were actually part of the tours as they would occur in the same place when played again.

Our first thought was that not all the terrain had loaded properly when the tour was recorded. Thus Google Earth recorded the wrong altitudes when recording the tour, and when playing it back new altitude data is available, so it looks wrong. After much investigation, we do believe that is the main cause of the problem, but that there are other issues as well.

We thought it would be interesting to try and fix the tours by using some maths to smooth out the altitudes. However, we found that because of the way the altitudes are stored in the tours, smoothing them out may be difficult or impossible. Google Earth can store altitudes in two basic ways: relative to the ground (or sea floor) or an absolute measurement (from sea level). A third option is to leave out the altitudes and have objects automatically clamp to the ground level. The difference between relative altitudes and absolute altitudes is not always obvious, but in some cases it is important to get it right. We had a problem with this in the past when we created a script to draw arcs. If we used absolute altitudes the ends of the arcs ended up all at a fixed altitude instead of ground level, and if we used relative altitudes then the arcs were not smooth but included all the bumps from the ground below them. The eventual solution that we came up with was to use absolute altitudes and read the end point altitudes from Google’s Elevation API.

In the case of the tours, we found that they are being stored as relative altitudes, which is a problem, because we cannot smooth them out without knowing what the ground altitude is at each point. Oddly enough, this contradicts what it says on this page, which states that Google Earth uses absolute altitudes for tours precisely because of the problems we are experiencing.

As we noted in this post, when viewing areas with 3D, Google Earth shows the altitudes from the 3D imagery in the status bar. So the first thing we wanted to do was determine whether or not relative altitudes in Google Earth are treated as relative to the default terrain at all times, or whether it uses the 3D imagery where available. What we found was surprising.

Google Earth does use the default terrain at all times, but in some cases, it modifies the default terrain when you turn on 3D imagery – and this modification includes the altitudes being used in the relative altitude calculation. Typically, 3D imagery is above the default terrain, so intuitively one would expect relative altitudes to move upwards when you turn on 3D imagery. What happens is the opposite. They move downwards. This is because Google Earth adjusts the default terrain downwards to stop it from being seen in the 3D imagery.

The two scenes below illustrate what happens. In both cases we have some lines set to a fixed height relative to the ground:

Left: ‘3D buildings’ layer turned on. Right: ‘3D buildings’ layer turned off.

In the second scene above, we are looking at a corner of an area with 3D imagery and you can see how the area with 3D imagery actually has a lower ground level than the surrounding areas. An extreme case of such altitude adjustments can be seen in this post.

In addition to all this we encountered one or two places where Google Earth couldn’t decide what the correct altitude was. If we had a line with a relative altitude set, it would jump between two different heights, depending on which direction we looked at it. We believe this is the cause of the worst of the jitter we experienced in the tours.

We still don’t have an actual solution to our problem.

Altitudes and polygons in Google Earth

December 22, 2015

When creating the Santa Tracker we made use of some code we had previously written for creating arcs in Google Earth. As we noted in that post, however, the arcs use relative altitudes, but for smaller arcs there can be noticeable dips and bumps in line with the underlying terrain. The other alternative is to use absolute altitudes but this results in arcs that end at a fixed altitude either underground or up in the sky, depending on the altitude one sets and the altitude of the ground at the ends of each arc. Neither of these possibilities was satisfactory for the Santa Tracker as it often shows the arcs up close and Santa himself is shown following the arc and would bounce around alarmingly as he flies over mountains and rivers below.

The cause of the problem is simple. KML paths and polygons that are drawn in KML do not have any altitudes associated with each point. It is possible to set the whole path or polygon to either follow the terrain or be at a specific altitude, but you cannot adjust the altitude of individual points. KML does, however, support altitudes and KMLs derived from other sources, such as GPS’s, which include altitude, do correctly display the altitudes in Google Earth, and we actually used this feature when creating the arcs mentioned above.

To draw nice smooth arcs that end at ground level at each end we need to know what the absolute altitude of ground level is for each end of the arc – but this is not available in the KML file. So we did some investigation and discovered that Google provides an elevation API as part of the Google Maps API. So, to create our arcs we first obtain the altitudes of all the points along the path or polygon and then we can draw nice looking arcs and give Santa a smooth ride.

We also thought that maybe other people might find a use for code that takes a KML of a path or polygon and adds in the altitude data from the Google Maps Elevation API. So, here it is:

Simply select a KML containing paths or polygons and the script will add altitude data from the Google Maps Elevation Service. You probably won’t see any difference in the resulting KML file when loaded in Google Earth, as the paths or polygons will still be at ground level. However, if you check the properties of a path or polygon you will see that it now shows various altitudes instead of an altitude of zero. Its real use is in cases where you want to do further processing, as we did for creating arcs. If anyone finds this useful do let us know in the comments what application you found it useful for.

Note that the Elevation Service is not intended to be used to extract large quantities of elevation data, so don’t expect to be able to use it to copy whole areas of elevation information into other applications.

Google gets altitude wrong and drowns a city

July 22, 2015

Thank you to GEB reader ‘jonahtornado’ for letting us know that Google appears to have got the altitude wrong in the 3D for the Italian city of Crotone. If looked at in Google Earth with the ‘Water Surface’ turned on it appears to be underwater.

It is actually not uncommon for 3D imagery to have a slight difference in altitude between it and the Google Earth default terrain, which results in a visible step at the edge of 3D regions in some places. Being near the coast, however, has resulted in most of the city being below sea level, which makes for quite an interesting effect. For best results turn on “Use photorealistic atmosphere rendering” found in Tools -> Options.

Use this KML file to fly straight there in Google Earth.

The ‘cliff’ where the 3D imagery meets default terrain is about 30m high.

According to our KML file the above 3D imagery was added to Google Earth in December 2014.