(Tourist)

04/28/08 01:31 AM

View in Google Earth

height altitude elevation accuracy - some results

So how good is the accuracy of height data in Google Earth?
I wrote a program in VB to extract height information over a KML path. There is also a service available at http://www.nearby.org.uk/elevation-kml.php which uses USGS GIS data to provide heights for KML paths.
I followed a river, the Shoalhaven in NSW Australia, from its mouth upstream for 270 km with a kml path of 657 datapoints, and got heights for each datapoint from Google and USGS. The results are up and down, but I then made any downstream points equal to the lowest of any upstream points – water flows downhill so any lower upstream points will be more correct.
The river can be divided into 3 lengths, the flatter coastal length, the rugged country length where it rises to 520 metres, and the high plateau length. In the flatter coastal length Google averages an error of 14.25 metres, while USGS averages a 5.64 metre error. In the rugged country length Google averages an error of 30.25 metres and the USGS data has an average error of 7.27 metres. In the upper plateau length Google averages an error of 10.84 metres and USGS has an average error of 4.43 metres. The results will actually be worse than this as the lower upstream points will not always be as low as the river.
An excel spreadsheet with the results and chart is available at www.simpeff.com/shoalhaven.xls

(Tourist)

04/28/08 12:39 PM

Re: height altitude elevation accuracy - some resu

Could you elaborate on the sources of the comparison data other than GE? How did you collect the control elevations that were used as the "truth"? Are all the vertical datums the same? Ellipsoid vs. Geoid? Did you check your control points vs. SRTM? I'm fairly sure that's what GE uses.

I find it interesting that the GE data is off by so much and would like more info.

(Tourist)

04/28/08 03:42 PM

Program file, source code & kml files

I have included relevant information in a zip file on my website. It contains the program, vb6 source code, the kml file initially used and final kml file returned with USGS data. Available at www.simpeff.com/GEHeights.zip
The program grabs co-ordinates from a kml file, moves the GE camera to the next coordinate, waits until it is within 0.00000001 degrees of the location (if you try to get the exact location it plays up) then grabs the terrain height from GE. The same kml file was input to get the USGS data back from http://www.nearby.org.uk/elevation-kml.php (this site only gives the next 100 heights, so you need to put the returned file through another 6 times).
I just ran the program again with the returned file from the USGS data and obtained exactly the same results (0 error on all double values). This returned file is the same co-ordinates but has the USGS height data included also. This indicates that there is no delay in movement errors and it is accessing the precise same co-ordinate data. Where there are the very large discrepancies of 100 meters or so USGS isn't out by the same amount, so we have to assume the GE terrain data is out.
Given the grid size of 90 meters used in GE substantial errors were expected. On average the height is of a point 25 metres away from the river bed, and rivers always have steep banks and cliffs.
There have been a lot of queries on the forum about the accuracy of height data so I just thought I would give some real numbers.

(Tourist)

04/28/08 06:21 PM

Re: Program file, source code & kml files

Great , I'll take a look. Again, what is the source of the data you are comparing GE and the USGS to?

And why do we assume GE is out? I took a look at the USGS site and the best data they have for Australia is 90m SRTM. Should be pretty close to the same.

(Tourist)

04/28/08 07:24 PM

rivers don't flow uphill

Rivers only flow downwards, so an assumption is made that all points downstream are lower than ANY upstream points.
Errors in this logic are on the conservative side, the lowest upstream point may still not be in the riverbed.
So the comparison is not to USGS data, it is to any lower points upstream. USGS data is included as a futher check.
I do not comprehend what you mean by "what is the source of the data you are comparing GE and the USGS to?", it sounds very technical
Ciao

(Tourist)

04/29/08 09:17 AM

Re: rivers don't flow uphill

I was thinking that you had a set of elevation values from a more reliable source that you were comparing GE and the USGS to. I misunderstood what you were doing. Instead it seems you are comparing the internal consistency of each data set by seeing if drainage is correct.

Got it, thanks.

(Tourist)

04/29/08 07:18 PM

Re: height altitude elevation accuracy - some results

All the terrain data at the sources you posted links to are relatively low accuracy data sets.

For instance the SRTM data averages the terrain over a 90m rectangular grid. The steeper the terrain or more variation in heights the more the height at any given point will vary from the height given for the grid at teh nearest sample point. You can also see that the lowest point which you are looking for is not always the height given.

Technically what are you finding are false sinks and by looking for the downhill path you are doing a common process when working with grids termed hydro or flow enforcement.

(Tourist)

05/14/08 09:54 AM

Re: height altitude elevation accuracy - some resu

I have been doing a detailed study of the accuracy of the Height data on Google Earth and Google Maps and if I presume that the data source is the same as mine ie. SRTM data then Google have a registration (georeferencing) problem. The data for non-US is mis-registered one pixel (or 90 meters) North. I have done extensive checks to ensure that the SRTM data is generally correct and corresponds very well with the UK Ordnance Survey heights. The areas I have looked at give accuracies generally better than 10 meters.

When however, I check the Google heights with my heights shifted north by one pixel there is a 1 meter rounding error only.

I first noticed this problem in the Dominican Republic which is fairly mountainous finding that east west rivers were running along the side of hills. There are a number of other sources of height data for instance
http://www.heywhatsthat.com/profiler.html
which seems to agree with Ordnance Survey.

When using heywhatsthat you can enable contours in Google (Terrain) and Contours. If you select a loaction outside the USA then the problem is obvious at the top of hills. This does demonstrate how nicely google have drawn the contours.

I have also checked with a barometric GPS which gives good accuracy as long as the weather is stable.

I suspect that the same problem exists for the US but at a 30 meter error because of the smaller pixel size. I have not yet checked that this is the case.

Thanks

(Tourist)

05/14/08 11:59 AM

Re: height altitude elevation accuracy - some resu

There is a known shift in early SRTM data which had been corrected in later versions. If you are using the CGIAR version, I know they've done a lot of work to fix this. It will be interesting to see what the results are in areas with data other than SRTM.

(Tourist)

05/15/08 12:40 AM

Re: height altitude elevation accuracy - some resu

My SRTM is version 2, I am aware that there is a version 3, and I need to change. I will urgently get the tiles where I have checked the error in detail and see whether there is a difference. I wonder what version heywhatsthat uses?

(Tourist)

05/15/08 04:57 AM

Re: height altitude elevation accuracy - some resu

We use SRTM version 2, 1 arcsecond in the US and 3 arcsecond everywhere else, and fill in with SRTM30 outside the SRTM coverage area.

MK

earth.google.com bbs.keyhole.com

UBB.threads™ 6.5.1.1