Weird altitude effects in Google Earth

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:

before
after

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

before
after

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.

About Timothy Whitehead

Timothy has been using Google Earth since 2004 when it was still called Keyhole before it was renamed Google Earth in 2005 and has been a huge fan ever since. He is a programmer working for Red Wing Aerobatx and lives in Cape Town, South Africa.






PLEASE NOTE: Google Earth Blog is no longer writing regular posts. As a result, we are not accepting new comments or questions about Google Earth. If you have a question, use the official Google Earth and Maps Forums or the Google Earth Community Forums.

Comments

  1. I’ve never had good luck recording tours, but also never investigated it to the extent you have. You may have heard of Kamelopard, a Ruby library for building KML. It has a spline feature which has worked well for tours I’ve built. I use Earth just to record a list of placemarks, and then let Kamelopard create a spline between those points, which the tour will follow. http://blog.endpoint.com/2014/05/kamelopard-version-0015-released.html



PLEASE NOTE: Google Earth Blog is no longer writing regular posts. As a result, we are not accepting new comments or questions about Google Earth. If you have a question, use the official Google Earth and Maps Forums or the Google Earth Community Forums.