Colin Smale <colin.sm...@xs4all.nl> writes: > On 2016-01-08 17:18, Greg Troxel wrote: > >> So we just have to fix things that are wrong, and transform heights in >> other datums into WGS84 before entering them. This is exactly the same >> situation that we encounter for horizonal datums, except that people are >> even less aware of which vertical datum they are using. > > How did all the elevation data get into OSM in the first place? GPS is
That's a good question. I guess you have to read the source tags :-) (A joke - I know they don't explain.) > notoriously bad at determining elevation/altitude. Apparently some > receivers will give you the raw WGS84 altitude, and others will make > some "corrections". Every nav-type receiver I have encountered, going back to the Garmin GPS 45 in 1995, has done the geoid conversion and output WGS84's approximation of orthmetric height. You are right that elevation accuracy is bad. It's usually 2x or so worse than horizontal, but errors matter more in height than horizontal so it feels far worse. > If the elevation in OSM was taken from some other published (and > suitably licensed, of course) source, I would probably expect it to be > relative to the traditional local datum and not WGS84. That's true, but the differences are small. In most of the US, we are talking maybe 1m in difference between NGVD29, NAVD88, WGS84. Even NGVD29 is pretty good. I suspect the big errors come from pre-1900 height systems. > So which ones are which? Which of the data already in OSM needs fixing, > and which is already correct? True but how is this different from horizontal coordinates? > Maybe we should discard all the elevations currently in OSM, and ask the > user "are you sure your elevations are in WGS84?" before accepting new > ones. Definitely we should not throw everything out. I don't understand why you want to; I see this as just the usual process of data getting added and people checking/improving it. Something that's 2m off or even 10m is vastly better than no data. Having some sort of notice in editors about both horizontal and elevation being in WGS84 could make sense, but I think it is one of 100 things to tell people, and that this heads us down the path of needing to take mandatory training and pass an exam before being able to edit!! >> I don't think it makes sense to add datum tags and have heights in other >> datums. That just pushes the work onto the data consumer and adds >> confusion. > > How can being more explicit about the datum lead to added confusion? We > allow explicit units for maxspeed etc, so why not allow an analogous > concept here? It adds confusion because it legitimizes not using the proper datum. So far OSM is a 1-datum project. It then means that downstream in the processing chain all software that deals with OSM data (and all humans) have to know about all these datums and have vertical datum conversion code, which is even harder to find than horizontal datum conversion code (e.g. proj4). Units for maxspeed is totally different. That is about unit only; the actual physical quantity still has the same reference point. The analogy would be to say that in some countries maxspeed is relative to 1.3 km/hr so when you say 80 km/hr you really mean 81.3 km/hr. And, the point of maxspeed units is that maxspeed rules/signs are expressed in different units in different countries, and that lets mappers type in what they see easily. But the real point is: if we don't do this for horizontal, why should we do it for vertical? And, can you point to specific bad data that is significant and due to vertical datum confusion? At least around me, all vertical data that exists, going back nearly 100 years, is consistent at the 1m level (except maybe broken GPS receivers, but it's not like people using them know what they are doing about this issue). I have the impresssion this is true in most other places, at least for height data from the 80s onward. > http://www.ngs.noaa.gov/GEOID/PRESENTATIONS/2007_02_24_CCPS/Roman_A_PLSC2007notes.pdf Thanks - that is a great summary (that I think almost no one in OSM needs to really understand, but it's fun), and there is much more on their site and hours of podcasts. I don't think we have data in OSM at a level of accuracy where these issues are causing problems.
signature.asc
Description: PGP signature
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
