[OSM-talk] augmenting contour data with gps track logs
John F. Eldredge
john at jfeldredge.com
Tue Dec 29 01:41:20 GMT 2009
I have heard that the altitude data available to civilian GPS units (as opposed to the US military units) has deliberate errors built in, in order to make it harder for someone planning for a future artillery attack. There is said to be a separate, more accurate, but encrypted, altitude signal for US military use. Remember, the GPS satellite constellation was put up by the US military.
John F. Eldredge -- john at jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria
From: Frederik Ramm <frederik at remote.org>
Date: Tue, 29 Dec 2009 00:20:09
To: Robin Paulson<robin.paulson at gmail.com>
Cc: OSM Talk<talk at openstreetmap.org>
Subject: Re: [OSM-talk] augmenting contour data with gps track logs
Robin Paulson wrote:
> ok, i didn't realise that. what levels of bad precision are we talking
> about; i assume it varies form model to model; how does it compare to
> the precision of srtm?
I'm not really an expert in this but Internet sources say that altitude
error is *at least* factor 1.5 compared to x/y error. My personal
experience (with a decent & recent Garmin device) is that a 200ft
altitude error is not unusual.
SRTM3 reportedly has a maximum error of about 20ft (but I haven't
verified that myself).
> i would envisage it being used in favour of the srtm data (which is
> very coarse, as you point out, hence my interest in replacing it)
There are also patches of better altitude data available. What we
normally use is SRTM-3, but for the area of the USA there is also SRTM-1
with triple the resolution.
> my idea was to extract a series pf lat, lon, alt triplet from the gps
> tracks, and use this to build a 'mesh' of the earth's surface, which
> would be stored independently of the points/ways which we create at
> the moment. the implicit assumption being that wherever the post box
> or any other object is placed on the globe, it takes it's height from
> the underlying mesh. from this mesh, we can then generate contours, 3d
> models, etc, etc as we do at present with the srtm data
That would certainly be a good start. I do however think that special
editors and the ability to manually edit that mesh will be required
sooner or later. You might, for example, have very a few very precise
measurements that you want reflected in the data, or you might want to
correct for an erroneous track or something.
The folks from OpenSeaMap are, by the way, thinking along the same lines
for bathymetry (ocean depth) data. They might get access to a very
coarse international data set which they can use as a basis, but then
want to refine that using spot measurements or other sources. It appears
that well-equipped ships, when en-route, automatically broadcast ocean
depth measurements of some kind which can be used to improve data.
>> In my eyes, a separate project "OpenTerrainModel" or something like that is
>> called for, the results of which could seamlessly replace our usage of SRTM
>> data today.
> is there an api for accessing the gpx files en masse? or a gpx.planet download?
Lars Francke is working on something like it at the moment, see "Export
of GPX data" over on the dev list.
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
talk mailing list
talk at openstreetmap.org
More information about the talk