OpenStreetMap
It bothers me that imports of UK OS OpenData into WGS84 might mean that each year those points drift out of sync of real locations by 2.5 cm north-eastwards. Not only that but the further back in time the further out OSM data could be. I don't know if this has been considered or corrected for. Additionally OSM has no true way of knowing the WGS84 epoch of a co-ordinate, for the uploaded API changes occur at some arbitrary point in the future after survey. The uploaded GPX traces can be without timestamps and thus unknown drift also. Ordnance Survey use ETRS89 and ETRF89 datums to correct for plate tectonic movement. Is that what happens to UK co-ordinates stored by OSM?
Дийцар
Коммент robert 11 June 2010 18:48
No. Almost nobody contributing to OSM has a way of generating data with this high detail. The number representation of the coordinates in the DB, depending where you are on the planet, just about gives you this level of accuracy if you're lucky.
Коммент robert 11 June 2010 18:48
Where I say detail, I mean accuracy.
Коммент Pink Duck 11 June 2010 21:51
Except people who have imported OS OpenData such as political/administrative boundaries which aren't physically there and don't tend to change, except within OSM. Most of the data being added is of course low accuracy, +/- 2 metres for my GPS unit itself. But OSM shouldn't be throwing away accuracy and precision where it is freely available from governmental sources.
Коммент JohnSmith 12 June 2010 00:30
@Pink Duck this is another reason for having the right tags, like source=*, set properly, that way you can make educated guesses about the quality of the data and how it should be handled.
Also I think you are over estimating the accuracy of boundary data, any surveys done are simply to mark on the ground what was on paper, since most boundaries mostly live on paper.
Коммент Pink Duck 12 June 2010 09:54
What initially got me concerned was seeing Ordnance Survey quote 1 metre per year as a maximum for tectonic movement. However, having looked into the rates more I realise that was mainly in the vertical component and thus not that applicable to OSM. The largest lateral movements tend to be 10 cm / year, which equates to around 6 metre drift within my lifetime. I do apply the right source tags for OS OpenData imports, but what I shall also do is tag a record of the UTC date when the conversion into WGS84 was made.
Коммент robert 12 June 2010 11:50
Except you're not getting the data for free.
All these things you're talking about take developer time to implement, server capacity to process and using all these different local datums around the world would massively (massively) complicate the project's data model.
Doing this for accuracy that almost nobody will ever use (NOBODY should be using osm for surveying) is not a top developer priority.
Коммент Pink Duck 12 June 2010 16:27
I haven't actually asked for any changes. I do more additions to OSM than what I download from it. I was just concerned about the longevity and usefulness of the project where lack of tectonic drift accounting means that everything loses accuracy with time. I accept that compromises have to be made for a non-commercial project.
Коммент Proterra 12 June 2010 20:35
*Also I think you are over estimating the accuracy of boundary data, any surveys done are simply to mark on the ground what was on paper, since most boundaries mostly live on paper.*
Boundaries are usually meered to physical features on the ground which in turn are surveyed to the accuracy required of the scale
Коммент nm7s9 13 June 2010 10:35
I agree with you completely Pink Duck. Even if our data is only +/- 2 metre accuracy, if there is a known drift, over time, in this data, then we should account for it.
Perhaps it's not an urgent issue, but from the perspective of trying to create a professional quality map, it's (IMHO) an important one.