Re: [OSM-talk] augmenting contour data with gps track logs
On Tue, Dec 29, 2009 at 12:01 AM, Liz ed...@billiau.net wrote: There are many sources of error in SRTM and GPS and barometric height measures. First of all Height compared to what? WGS84 adjusted by the deviation between WGS84 and EGM96 at the lat/lon of the measurement? Would that work? A fast bicycle descent wrecks the height calculation because the processor is too slow. Could that be resolved by asking it to output raw WGS84 altitudes and then doing the calculations to adjust it to MSL offline? Just questions. I don't know enough about this stuff to have the answers. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] augmenting contour data with gps track logs
the srtm contour data used in some osm renders is great, partic for cyclists and walkers. i've realised that it's not as high accuracy/precision as it might be though. i notice that most GPS devices also record the elevation within their tracklogs, and that it might be useful to extract this data, and use it to provide more data for calculating the altitude of a given point. any ideas? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] augmenting contour data with gps track logs
Robin, Robin Paulson wrote: the srtm contour data used in some osm renders is great, partic for cyclists and walkers. i've realised that it's not as high accuracy/precision as it might be though. i notice that most GPS devices also record the elevation within their tracklogs, and that it might be useful to extract this data, and use it to provide more data for calculating the altitude of a given point. Pure GPS elevation is worthless due to bad precision (for technical reasons, Z measurement is much worse than X/Y measurement in GPSes). Some GPSes have barometric altimeters which are very precise but need calibration (to an extent they can be post-calibrated if you have visited a point with known altitude and weather hasn't changed on you too much during the trip). The biggest problem however is that altitude data is an altogether different beast than what we're normally working with. The hill shadings and contour lines you see on our maps are basically derived from a giant, planet-wide bitmap which has one pixel for (approximately) every 100metre x 100metre square on the earth's surface. We would need a mechanism that takes the spot heights measured with your GPS and somehow weaves them into this (or a finer-resolution) bitmap, *or* go for a true 3D surface model of the earth. Both will require different kinds of editors than we have now. Simply adding altitude information to features we map will not do because most editors are unaware of that, and it is unclear what it means exactly. If you map a post box with altitude=100ft, and I later find that the post box is in fact on the other side of the road - does that mean that this side of the road is still 100ft, just the post box has to be moved, or does that mean that I have to move the altitude information together with the post box? 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. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] augmenting contour data with gps track logs
2009/12/28 Frederik Ramm frede...@remote.org: Pure GPS elevation is worthless due to bad precision (for technical reasons, Z measurement is much worse than X/Y measurement in GPSes). Some GPSes have 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? We would need a mechanism that takes the spot heights measured with your GPS and somehow weaves them into this (or a finer-resolution) bitmap, *or* go for a true 3D surface model of the earth. Both will require different kinds of editors than we have now. 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) Simply adding altitude information to features we map will not do because most editors are unaware of that, and it is unclear what it means exactly. If you map a post box with altitude=100ft, and I later find that the post box is in fact on the other side of the road - does that mean that this side of the road is still 100ft, just the post box has to be moved, or does that mean that I have to move the altitude information together with the post box? the idea was not to get people to manually tag the altitude of objects (like post boxes), partly for the reasons you point out, partly because it's slow. 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 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. exactly is there an api for accessing the gpx files en masse? or a gpx.planet download? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] augmenting contour data with gps track logs
Hi, 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. exactly 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. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] augmenting contour data with gps track logs
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 -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria -Original Message- From: Frederik Ramm frede...@remote.org Date: Tue, 29 Dec 2009 00:20:09 To: Robin Paulsonrobin.paul...@gmail.com Cc: OSM Talktalk@openstreetmap.org Subject: Re: [OSM-talk] augmenting contour data with gps track logs Hi, 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. exactly 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. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] augmenting contour data with gps track logs
2009/12/28 Robin Paulson robin.paul...@gmail.com: 2009/12/28 Frederik Ramm frede...@remote.org: Pure GPS elevation is worthless due to bad precision (for technical reasons, Z measurement is much worse than X/Y measurement in GPSes). Some GPSes have 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? Attached is a plot of my bike ride with three devices (different models unfortunately) recording altitudes. (x is degrees longitude, y metres) One thing to consider when using the traces from osm's collection is that not all of them are recorded on the ground level, there are at least a couple of airplane traces and a paraglider trace. Cheers attachment: trace-test.png___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] augmenting contour data with gps track logs
On Tue, 29 Dec 2009, Robin Paulson wrote: the srtm contour data used in some osm renders is great, partic for cyclists and walkers. i've realised that it's not as high accuracy/precision as it might be though. i notice that most GPS devices also record the elevation within their tracklogs, and that it might be useful to extract this data, and use it to provide more data for calculating the altitude of a given point. any ideas? There are many sources of error in SRTM and GPS and barometric height measures. First of all Height compared to what? Sea Level? Sea Level is as arbitrarily defined as any tag in OSM - its what somebody else says Sea Level is. Next - there are plenty of fake elevations in SRTM data. I can show you places where the creek is higher than the ground according to SRTM. On the flat plain the only trees grow next to the creek and are an obvious feature - so the satellite measure picks out the trees as a rise in ground level. Sometimes the contour elevation is found to be a big shed. Most of the time the Garmin Etrex Hcx offers the same height as the SRTM data on the imported map, but seeing where and when it makes errors is the key to understanding the errors. A fast bicycle descent wrecks the height calculation because the processor is too slow. It defaults to barometric measure then but this is affected by more than height. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
