[Tagging] Elevation and height on vertical features
gdt at ir.bbn.com
Fri Jan 8 17:09:49 UTC 2016
Colin Smale <colin.smale at 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
> 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
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
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 180 bytes
Desc: not available
More information about the Tagging