Re: [Tagging] RFC ele:regional

[Simon Poole]

I was just making a statement of fact, not arguing one way or the other.
The original reason for using HAE in the ele tag was exactly what Kevin
claimed what would be the only sensible use of the HAE value. That it
probably was a bad idea because it didn't take the realities of mapping
in to account (as far as these could even be known at the time) doesn't
affect the original intent.

The really only open question is: do we consider ele so burnt that it
should just go away and we use a different tag (for example
ele:regional, though I would be against that specific key) for "height
indicated on things without knowing exactly which datum is being used"
or do we use ele for that.

Simon

Am 08.05.2020 um 03:11 schrieb Greg Troxel:
> Simon Poole  writes:
>
>> Am 04.05.2020 um 15:19 schrieb Kevin Kenny:
>>> Elevation as height-above-ellipsoid, unless you're using it in the
>>> intermediate results of a GPS calculation, is nonsensical.
>> However if you read the argumentation on the Altitude page that was
>> exactly the reasoning: store hae and therefore be able to calculate
>> datum specific heights easily after the fact.
> Yes, but this is a ridiculous stramwan.   HAE and height above wgs84
> geoid are equally well defined, but one (height above geoid) is what is
> used for height and also happens to be almost matching all civil height
> systems.
>
>
> The real point here is that people want to take data that has a number
> but not a datum and enter it and feel good about themelves, instead of
> realizing and admitting that they are doing something fundamentally
> wrong.  I am perfectly ok with entering a height that has no datum, and
> having some meta key that basically says that the height value is
> inaccurate, and perhaps "ele:datum=unknown" is good for this, crisply
> denoting that the height is without a solid basis.
>
> But, I find it unreasonable that people want to legitimize this sort of
> confusion, rather than mark it as confusion as a warning to others.



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Colin Smale]

On 2020-05-08 18:01, Greg Troxel wrote:

> I think we now know that the existing datums don't differ much from WGS84 
> except Belgium, and given the EVRF2007 datum, it seems clear that Belgium now 
> will have that and the old one, differing by 2m.
> Hence the thing we need to know, we don't, in this case.

Depends how you define "much". According to this info on Wikipedia
(sorry that it is in Dutch), the French also have their own datum, which
is TAW-1.82m, which works out to NAP-0.50m. 

https://nl.wikipedia.org/wiki/Tweede_Algemene_Waterpassing 

A little light reading for Greg: "The transformation of GPS into NAP
heights: Combining NAP, GPS and geoid heights to compute a height
reference surface for the Netherlands" 
https://repository.tudelft.nl/islandora/object/uuid%3Ae661fcdd-6fe8-46e9-b5ea-51dabbd89175___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

On 2020-05-08 11:33, Martin Koppenhoefer wrote:

It could be useful when mapping something like a building. You could 
establish a certain elevation as local zero (e.g. the elevation of the 
ground floor) and have all other levels based on this. It is something 
that could also not be needed because of an editor who abstracts this 
(no need to store relative information if some frontend could do it), 
but I would not hinder people from experimenting with it.


I can see wanting to do this, but I think it should not use the ele= 
tag, and this really feels like it needs to be "height above ground 
floor" or something.   It really needs a scheme that is well thought 
out.   I too think it's fine if people do this, as long as they don't 
use the ele= tag, which means something else.




 > ele:regional is about admitting that you don't know

But, it asserts that the value is in some particular datum, and that you
can tell which one from knowing the area.   All of this is untrue.

maybe a particular datum can not be given, but you can be quite sure (as 
sure as you are willing to accept from a tag which pretends it is) it is 
one of those common in the area (which also will not differ a lot, 
probably).


I think we now know that the existing datums don't differ much from 
WGS84 except Belgium, and given the EVRF2007 datum, it seems clear that 
Belgium now will have that and the old one, differing by 2m.

Hence the thing we need to know, we don't, in this case.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> I was not aware there weren't any meaningful differences (when comparing
> some official height references to the German DHHN92 those in wikipedia.de
> with delta information all are within 1m besides Belgium DNG/TAW, which is
> -2.3).

Thanks for looking into this.  It is interesting about Belgium's datum
being so far off, but I'm sure there's some long-ago historical reason
and various datums along the way matched some earlier datum.   Perhaps
relating a nautical datum (tends to be mean low water) with a land datum
(tends to be mean sea level).

> Maybe all we should do is clarify that we are NOT expecting
> ellipsoid heights in ele tags (leaving open the possibility to add
> ele:datum tags)?

I would very much like to clarify that, and it feels like we have
consensus on that point.  I can edit the wiki page to make it clearer,
since we have had a big discussion and there is no one advocating for
ellipsoidal height in OSM.

I am ok with some text about the possible future use of ele:datum to
refer to some other datum, although I think it's preferable for people
to transform, just as it is for horizontal.

> WGS84 uses a 2 dimensional ellipsoidal coordinate system?

WGS84 at its core is a 3-dimensional cartesian system, written XYZ, with
the origin at the center of mass of the earth.  There is a transform to
latitude, longitude, and ellipsoidal height (which is just math and not
a source of errors).   All modern datums are like this.  Note that WGS84
is essentially the same thing as ITRF2014, the current international
datum from the geodesy (since of measuring the earth) community, perhaps
differing by a few mm, perhaps not.

> Wouldn't "natural" height information be based on this ellipsoid? I'm all
> fine with stating we should use geoid heights, but it doesn't necessarily
> seem to be implicit.

It does need to be made clear, as there is ample reason to think there
has been confusion about it in OSM.


ellipsoidal heights are not natural!

To understand this, one has to look to the history of surveying.  Until
the satellite era, horizontal datums and vertical datums were basically
separate.  Horizontal was done by maesured baselines and triangulation.

Vertical was done by 'leveling' which is basically a telescope with a
bubble level, so you transfer horizontally from one place to another,
and then read the difference on a rod, which is basically a giant
measuring stick.  As you move from a tide gauge across a continent, you
keep track of the accumulated differences (and loops, and then you do
least squares).

Implicit in leveling is that two places at the same height are at the
same gravitational potential, and that when you say "height is x m" you
mean that if you measured vertically (along the plumb line) it was x
until you got to where the ocean would flow to if there were a tunnel.
So height as surveyors used it, and the national/regional datums taht
this height is referenced too, have always been about gravity, and the 0
reference level has more or less been at some notion of sea level.
Typical is the mean reading of a tide gauge over 19 years (a sun/moon
cycle).

NAVD88 is referenced to a single tide gauge at Father's Point in
Rimouski, Quebec.  NGVD29 set a number of tide gauges around the
continent at 0 (and this caused distortions).

Satellite techniques just measure position and distance, and not
gravity.  Thus they in their raw form give you ellipsoidal height.  But,
this is not useful for water engineering, because lower elllipsoidal
height is not downhill.  So WGS84 defines a "geoid model" that gives the
height of an equal-gravity surface that more or less corresponds to mean
sea level, compared to the ellipsoid, and except for 1) some buggy
android programs and 2) survey-grade GPS equipment, all GPS (GNSS,
GLONASS, Galileo, BeiDou, etc.) receivers give altitudes in height above
the geoid, because aligning (at the meter level) with the previous
national height datums is important, and having water flow to lower
elevations is important.  And because nobody except national-level
surveyors has ever cared about ellipsoidal heights.

Ellipsoidal heights are basically used only as internal steps in
surveying, and nobody in the surveying world would ever think to put
them on a sign, or say to the public "the ellipsoidal height of Mount
Washington is X".  (A datasheet for surveyors would say that, but it
would also give the NAVD88 height.  A poll of 1000 surveyors asking
"should we put ellipsoidal height or NAVD88 on the sign" would result in
all 1000 of them looking at you like you were crazy and saying "NAVD88,
of course".)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Fr., 8. Mai 2020 um 17:16 Uhr schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

> I was not aware there weren't any meaningful differences (when comparing
> some official height references to the German DHHN92 those in wikipedia.de
> with delta information all are within 1m besides Belgium DNG/TAW, which is
> -2.3). Maybe all we should do is clarify that we are NOT expecting
> ellipsoid heights in ele tags (leaving open the possibility to add
> ele:datum tags)? WGS84 uses a 2 dimensional ellipsoidal coordinate system?
> Wouldn't "natural" height information be based on this ellipsoid? I'm all
> fine with stating we should use geoid heights, but it doesn't necessarily
> seem to be implicit.
>


forgot the link:
https://de.wikipedia.org/wiki/H%C3%B6he_%C3%BCber_dem_Meeresspiegel#Amtliche_H%C3%B6hensysteme_ausgew%C3%A4hlter_L%C3%A4nder
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Fr., 8. Mai 2020 um 14:35 Uhr schrieb Colin Smale :

> As I mentioned before, the national datums of the Netherlands and Belgium
> differ by over 2m, which for everything connected to water is very
> significant. Waterways often form the border, with bridges that cross the
> border. You cannot use a map/chart (at last for tidal waters) if you don't
> know what datum it uses.
>


it seems Belgium is an "outlier" because they use the low water level as
reference.


Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Fr., 8. Mai 2020 um 14:26 Uhr schrieb Greg Troxel :

> Martin Koppenhoefer  writes:
>
> > Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel :
> > the "definition" for "ele:local" (in German language on the English talk
> > page of the tag) seems to be about this: a local datum based on a local
> > reference (i.e. not the same as ele:regional). I am not in any way
> involved
> > in ele:local, just wanted to point it out.
>

> That does sound like what I mean by local.   I would say that heights in
> such local systems should not be entered into OSM, and I would find
> their use in anything tourist-facing to be very strange.
>


It could be useful when mapping something like a building. You could
establish a certain elevation as local zero (e.g. the elevation of the
ground floor) and have all other levels based on this. It is something that
could also not be needed because of an editor who abstracts this (no need
to store relative information if some frontend could do it), but I would
not hinder people from experimenting with it.


> > ele:regional is about admitting that you don't know
>
> But, it asserts that the value is in some particular datum, and that you
> can tell which one from knowing the area.   All of this is untrue.



maybe a particular datum can not be given, but you can be quite sure (as
sure as you are willing to accept from a tag which pretends it is) it is
one of those common in the area (which also will not differ a lot,
probably).


> As I said before, if you want to put something like
>
> information=board
> inscription="Mount Washington // Elevation 6288 Feet"
>
> that's totally fine.
>


yes, but I want the elevation to be in a semantic tag, not in
description/note/name/inscription


[not want]  any notion that HAE is reasonable in OSM
>


I am fine with this. HAE is not what casual mappers would expect (to have
the sea signficantly different than 0). But I have come to the impression
that some people would prefer HAE because it can be seen more logical when
speaking about WGS84.

Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Fr., 8. Mai 2020 um 14:09 Uhr schrieb Greg Troxel :

> Martin Koppenhoefer  writes:
>
> > Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel :
> >
> >>   3) Look up the data sheet and mark it as ele:datum=NGVD29 or
> >>   ele:datum=NAVD88 as it turns out.
> >
> > IIRR, in another mail, you wrote that the difference between these 2 is
> > less than a meter, can you confirm this, or did I understand you or
> > remember wrong?
>
> Yes,it typically is.
>
> So let me ask you again, since you keep declining to answer this:
>
>   Please give an example of an elevation of a real thing that is
>   meaningfully different in one of these "regional datums" (established
>   by a country's survey agency) compared to WGS84 height above geoid.
>   Identify the regional datum, and identify two values linked with a
>   rigorous transformation (such as national survey agencies publish).
>
>
> Thus far, you have not established that there is an actual problem that
> needs to be solved.
>


I was not aware there weren't any meaningful differences (when comparing
some official height references to the German DHHN92 those in wikipedia.de
with delta information all are within 1m besides Belgium DNG/TAW, which is
-2.3). Maybe all we should do is clarify that we are NOT expecting
ellipsoid heights in ele tags (leaving open the possibility to add
ele:datum tags)? WGS84 uses a 2 dimensional ellipsoidal coordinate system?
Wouldn't "natural" height information be based on this ellipsoid? I'm all
fine with stating we should use geoid heights, but it doesn't necessarily
seem to be implicit.

Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Kevin Kenny]

My thoughts - trying to be brief, I started writing a much longer
message, but it got disorganized fast:

1. ele=* should always be orthometric.

2. Datum may be supplied with ele:datum=*, defaulting to
'ele:datum=unknown'. Within the regions of the Earth where a datum is
valid, all the datums in common use agree to within a couple of metres
of each other. (Obviously, you wouldn't want to try to extrapolate
NAVD88 onto a different continent!) Accuracy at that level is good
enough for virtually all land and aeronautical applications. How many
elevations in OSM have been determined with precise division of
levels, or with a four-hour integration time on a survey-grade GNSS
station?

3. A key like ele:tidal=* should be considered for nautical uses,
because water depths and bridge heights in tidal regions are measured
relative to tidal elevations.

4. Tidal datum may be supplied with ele:tidal:datum=*. The values for
this key may the local tidal measurements of MLLW, MLW, LMSL, DTL,
MTL, MHW, LWD, MHHW. Default in North America should likely be
'ele:tidal:datum=mllw' because that's how bathymetry is tabulated here
- referenced to local Mean Lower Low Water. Other locales will likely
have other conventions.

Rationale for separate keys: Orthometric and tidal elevations may be
some metres apart, and there would likely be considerable confusion if
the two were to use the same key. (Consider the case of the Bay of
Fundy, where the tidal range is 16 m. Geoid height and MLLW will be
eight metres apart - try to compare 'ele:*' values!

Bridge heights and water depths are not elevations, but elevation
differences, and need further discussion. (How best to call out water
depths on inland waterways, or bridge heights above them?) The Wiki
doesn't appear yet to have a lot about bathymetry.

5. Height-above-ellipsoid COULD be tabulated as ele:ellipsoidal=*
(with datum required), I suppose - but I agree with Greg Troxel that
ellipsoidal elevation has no place in OSM. It's an intermediate
calculation, which we wouldn't be discussing on the 'tagging' list at
all if it were not for the fact that the Android location API
unfortunately exposes it. It's very often tens of metres off from the
actual surface of the sea. It cannot be displayed as anything that an
ordinary user would recognize as an 'elevation' without further
computation; data consumers ought not to be required to resort to such
computations merely to produce a map for popular use, as opposed to a
navigational chart. Since API's like the one to 'vdatum' generally
allow conversion between two arbitrarily chosen reference frames, it's
no more work for the programmer of a data consumer that needs precise
data to convert from the supplied datim than from the ellipsoid.

Those wishing to determine whether a building site is above 19-year
highest high water should really consult a competent engineer, and not
OSM. (Disclaimer: I am an engineer. In a different specialty entirely.
Choice of building site in a tidal region is entirely outside my
professional competence, and it would be unethical and illegal for me
to consult on such a project.)

Those piloting a vessel had better have charts from a competent
authority. For commercial vessels, there are legal chart carriage
requirements that OSM will likely never satisfy.

"Leadsman!" "And a quarter five, over a clay bottom!"

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Colin Smale  writes:

> As I mentioned before, the national datums of the Netherlands and
> Belgium differ by over 2m, which for everything connected to water is
> very significant. Waterways often form the border, with bridges that
> cross the border. You cannot use a map/chart (at last for tidal waters)
> if you don't know what datum it uses. 

Thanks.  2m is perhaps significant, and I'm surprised it's that much.  I
would suggest that if people care about that 2m, then they need to
transform to a common height reference.

I would expect that Europe is working on a new satellite-native regional
height system, similar to the new 2020 in Australia and the 2022 one in
North  America, that will basically align heights.

> In OSM we often leave out "obvious" annotations, giving rise to a kind
> of "default" (such as maxspeed in km/h). But there is always a way of
> making it explicit, for those who feel the need. In this case we may
> agree to define "ele" as relative to the "local datum" or WGS84 or
> whatever, but we must always provide a system for making that explicit,
> and (preferably) a means to derive the intended basis for values that
> are not explicitly qualified.

So what do you think about what I've been saying:

  ele is assumed to be in, and should be represented in, WGS84 height
  above geoid (as the international norm, aligned with OSM's horizontal
  datum)

  ele:datum=unknown represents that the mapper doesn't know what datum
  the number they put in ele is expressed in

  ele:datum=EPSG:5703 (as an example for NAVD88), when the mapper really
  does know the datum, and doesn't want to transform to WGS84


I assume you are referring to:

  https://epsg.io/5709

  https://epsg.io/5710

and it seems that the European more modern height datum has already
happened:

  https://epsg.io/5730 (superceded)
  https://epsg.io/5621 (European Vertical Reference Frame 2007)

This looks useful:

  http://euref.eu/documentation/Tutorial2015/t-04-01-Liebsch.pdf

And this all makes me think that an elevation without a datum cannot be
reliably used at the better than 2m level.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Colin Smale]

On 2020-05-08 14:09, Greg Troxel wrote:

> Martin Koppenhoefer  writes:
> 
> Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel :
> 
> 3) Look up the data sheet and mark it as ele:datum=NGVD29 or
> ele:datum=NAVD88 as it turns out. 
> IIRR, in another mail, you wrote that the difference between these 2 is
> less than a meter, can you confirm this, or did I understand you or
> remember wrong?

Yes,it typically is.

So let me ask you again, since you keep declining to answer this:

  Please give an example of an elevation of a real thing that is
  meaningfully different in one of these "regional datums" (established
  by a country's survey agency) compared to WGS84 height above geoid.
  Identify the regional datum, and identify two values linked with a
  rigorous transformation (such as national survey agencies publish). 

As I mentioned before, the national datums of the Netherlands and
Belgium differ by over 2m, which for everything connected to water is
very significant. Waterways often form the border, with bridges that
cross the border. You cannot use a map/chart (at last for tidal waters)
if you don't know what datum it uses. 

In OSM we often leave out "obvious" annotations, giving rise to a kind
of "default" (such as maxspeed in km/h). But there is always a way of
making it explicit, for those who feel the need. In this case we may
agree to define "ele" as relative to the "local datum" or WGS84 or
whatever, but we must always provide a system for making that explicit,
and (preferably) a means to derive the intended basis for values that
are not explicitly qualified.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel :
>
>> The notion of "local" has the same problem, and it is also a poor choice
>> of words in that in surveying, "local", refers to coordinate systems
>> established for particular projects or surveys that have no lasting
>> significance.
>
> the "definition" for "ele:local" (in German language on the English talk
> page of the tag) seems to be about this: a local datum based on a local
> reference (i.e. not the same as ele:regional). I am not in any way involved
> in ele:local, just wanted to point it out.

That does sound like what I mean by local.   I would say that heights in
such local systems should not be entered into OSM, and I would find
their use in anything tourist-facing to be very strange.

>> Basically, either you know what datum an elevation is in, in which case
>> you can 1) transform it to WGS84 height above geoid or 2) label it
>> correctly, or you don't know, in which case you should simply *admit
>> that you do not know*.

> ele:regional is about admitting that you don't know

But, it asserts that the value is in some particular datum, and that you
can tell which one from knowing the area.   All of this is untrue.   In
contrast "ele:datum=unknown" is a crisp statement that you don't know
the datum, no more and no less.

As for guessing about regional, data consumers can guess too, but
encoding a guess in a vague way seems really unhelpful.

>> I would also ask: if this is reasonable for height, why isn't it also
>> reasonable for horizontal coordinates?
>
> because we typically have much more horizontal positional information with
> which we can compare. Errors in horizontal position are more evident
> because the relation to the surrounding (alignment, reference, angles,
> axis, proportions, etc.) won't fit. Up to a certain degree (e.g. when other
> information around is missing, and when accurate positional information is
> missing) we also do have and tolerate very approximate horizontal spatial
> information.

I'm talking about things like NAD83 vs WGS84, which is basically a 1m
difference around me.   We either transform or accept the fuzz, but it
would be crazy to label points as being in NAD83.  That's really my point.

> Greg, you wrote we should convert locally signed regional datum elevation
> information to the WGS84:geoid reference. In other context, we do not do
> unit conversions, for example we do not convert speed limits in mph to kph,
> nor do we convert weight information or maxheight information.

This isn't really about units.  Datum is about point of reference, and
the "don't convert" argument applies equally well to horizontal datums.

As I said before, if you want to put something like

information=board
inscription="Mount Washington // Elevation 6288 Feet"

that's totally fine.

> I could imagine doing a "reasonable" conversion (precision the same as
> expected from the original value) if there would be support from the
> tools (e.g.  mobile editors, iD or Josm), but otherwise I would not
> expect the vast majority of mappers doing this conversion at all in
> case of a value read off a sign, and even if they did I would expect
> this conversion step to be error prone (e.g. the mapper won't know
> which is the original datum).

I agree that casual mappers doing conversions is likely too much.

However, I don't see the harm in just entering a signed elevation in
ele= and not worrying about it, or also adding ele:datum=unknown to
represent that the data is not known to have been handled accurately.

My primary objection is not about having a tag to say the datum is
unknown.  What I really don't like is:

  the notion that it is a desired state to have elevations in other than
  the standard OSM datum, and that all data consumers should have to deal
  with this

  any notion that HAE is reasonable in OSM

  marking something as "regional" as if that is clear, when the reality
  is "unknown".  (If I come across a sign in the US with elevation, even
  I, as an elevation nerd, have no idea if it's NGVD29 or NAVD88, or if
  it's just plain bogus, with the number being copied from someone else
  who didn't really know either.)


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel :
>
>>   3) Look up the data sheet and mark it as ele:datum=NGVD29 or
>>   ele:datum=NAVD88 as it turns out.
>
> IIRR, in another mail, you wrote that the difference between these 2 is
> less than a meter, can you confirm this, or did I understand you or
> remember wrong?

Yes,it typically is.

So let me ask you again, since you keep declining to answer this:

  Please give an example of an elevation of a real thing that is
  meaningfully different in one of these "regional datums" (established
  by a country's survey agency) compared to WGS84 height above geoid.
  Identify the regional datum, and identify two values linked with a
  rigorous transformation (such as national survey agencies publish).


Thus far, you have not established that there is an actual problem that
needs to be solved.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Peter Elderson  writes:

> Why not use a datum:value pair?
>
> ele=[datum:]value
>
> datum: is optional. If you don't know, just leave it out. Data users can
> assume locally signed or known.

Becuase, as I have said many times and no one seems to be listening, in
OSM we have said that we use WGS84, and thus all elevations must be in
WGS84 (height above geoid), the same way that all horizontal coordinates
must also be in WGS84.

The very notion of putting in elevations in other datums is very
irregular, and it's a path to madness where data in OSM is in varying
reference systems and the data consumer then has to deal and transform.
It seems really obvious that the data should be in the standard OSM
datum and therefore correct.

This entire situation is really blowing up a situation of people who
want to simultaneously not be rigorous, by entering elevations that they
don't have any basis for trusting or knowing the datum, and to be sort
of appearing to be rigorous by labeling them in a way that isn't sound.

I think it's completely fair to have an extra tag that indicates the
elevation value is low quality, so that those mappers that know this and
those data consumers that know this can express and understand this.
But it's also very important for the simple case to remain simple.

Adding datum: into elevation means that every data consumer has to adapt
to the new rule, while ele:datum= does not - those that ignore it
are not harmed.


Other than your proposal making it difficult for data consumers, it
seems equivalent to ele:datum=.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel :

>   3) Look up the data sheet and mark it as ele:datum=NGVD29 or
>   ele:datum=NAVD88 as it turns out.
>


IIRR, in another mail, you wrote that the difference between these 2 is
less than a meter, can you confirm this, or did I understand you or
remember wrong?

Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel :

> The notion of "local" has the same problem, and it is also a poor choice
> of words in that in surveying, "local", refers to coordinate systems
> established for particular projects or surveys that have no lasting
> significance.
>


the "definition" for "ele:local" (in German language on the English talk
page of the tag) seems to be about this: a local datum based on a local
reference (i.e. not the same as ele:regional). I am not in any way involved
in ele:local, just wanted to point it out.




> Basically, either you know what datum an elevation is in, in which case
> you can 1) transform it to WGS84 height above geoid or 2) label it
> correctly, or you don't know, in which case you should simply *admit
> that you do not know*.
>


ele:regional is about admitting that you don't know



> I would also ask: if this is reasonable for height, why isn't it also
> reasonable for horizontal coordinates?



because we typically have much more horizontal positional information with
which we can compare. Errors in horizontal position are more evident
because the relation to the surrounding (alignment, reference, angles,
axis, proportions, etc.) won't fit. Up to a certain degree (e.g. when other
information around is missing, and when accurate positional information is
missing) we also do have and tolerate very approximate horizontal spatial
information.


Greg, you wrote we should convert locally signed regional datum elevation
information to the WGS84:geoid reference. In other context, we do not do
unit conversions, for example we do not convert speed limits in mph to kph,
nor do we convert weight information or maxheight information. I could
imagine doing a "reasonable" conversion (precision the same as expected
from the original value) if there would be support from the tools (e.g.
mobile editors, iD or Josm), but otherwise I would not expect the vast
majority of mappers doing this conversion at all in case of a value read
off a sign, and even if they did I would expect this conversion step to be
error prone (e.g. the mapper won't know which is the original datum).

Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Peter Elderson]

Why not use a datum:value pair?

ele=[datum:]value

datum: is optional. If you don't know, just leave it out. Data users can
assume locally signed or known.

Thus, the spontaneous mapper and the elevation experts are served. Mapper
communities can establish regional preferences. Quality checking can be
applied.

As usual with measures, unit may follow the value, where m is default.

Best, Peter Elderson


Op vr 8 mei 2020 om 10:04 schreef Marc Gemis :

> >   2) Use ele:datum=unknown as a clue that the data is not that high
> >   quality.
>
> or make that the default, so that when there is no ele:datum data
> consumers have to consider it as unknown .
> Any ordinary mapper, including myself, just wants to put the number
> they see on a sign into the database. Why do they need to add
> ele:datum=unknown?
> Let people that do know the datum (a much smaller group I assume) add
> ele:datum explicitly.
>
> regards
>
> m.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Marc Gemis]

>   2) Use ele:datum=unknown as a clue that the data is not that high
>   quality.

or make that the default, so that when there is no ele:datum data
consumers have to consider it as unknown .
Any ordinary mapper, including myself, just wants to put the number
they see on a sign into the database. Why do they need to add
ele:datum=unknown?
Let people that do know the datum (a much smaller group I assume) add
ele:datum explicitly.

regards

m.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Joseph Eisenberg  writes:

> Is there a reason to use this new tag ele:regional instead of ele:local=*
> which is already mentioned on the Key:ele page?

The notion of "ele:regional" is semantically wrong, because there is no
way to map a particular lcoation to a single vertical datum.

The notion of "local" has the same problem, and it is also a poor choice
of words in that in surveying, "local", refers to coordinate systems
established for particular projects or surveys that have no lasting
significance.

I have tended to say "regional datum", because in the US we share NAVD88
with Canada, and because I have the impression that in Europe multiple
countries share a vertical datum.


Basically, either you know what datum an elevation is in, in which case
you can 1) transform it to WGS84 height above geoid or 2) label it
correctly, or you don't know, in which case you should simply *admit
that you do not know*.


I would also ask: if this is reasonable for height, why isn't it also
reasonable for horizontal coordinates?

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Mark Wagner  writes:

> What about regions where two or more reference systems are in common
> use?  If I copy an elevation from a USGS benchmark and put it in
> "ele:regional", how does an end-user know if it's a recent benchmark
> measured in NAVD 88 or an older benchmark measured in NVGD 29?

They don't, and this is why doing what you ask about is a bad idea.  (I
realize you are asking a mostly rhetorical question.)

The right thing to do is one of

  1) transform the elevation from whichever system it is in to WGS84
  height above geoid.  This is after all what we do with horizontal
  coordinates -- it is not acceptable in OSM to store coordinates in
  some random datum that is not WGS84, and then make up extra tags to
  pretend that's ok.

  2) Use ele:datum=unknown as a clue that the data is not that high
  quality.

  3) Look up the data sheet and mark it as ele:datum=NGVD29 or
  ele:datum=NAVD88 as it turns out.  Keep in mind that this 'on the
  ground' verifiability notion is taken to crazy extremes, and that
  looking up a height in a database is just as legit as reading it off
  the disc.  The physical discs are after all merely a distributed
  database.  If you are encoding "this disc says X", then you are
  reporting a fact you see with your eyes.  But once you report "the
  elevation of this disc is X (because it said so)", then you are making
  assumptions and *you have not actually verified* what you are putting
  into OSM.  In particular you have not verified it any more than
  looking it up in the NGS databse, and arguably you have verified it
  much less.

The next question is:

  If I just put a height that might be NGVD29 or NAVD88 into the db as
  ele, where it is interpreted as WGS84 heigh above geoid, what harm
  is done, and who suffers that harm?

and I would say "close to zero, and anybody who is upset is welcome to
look up the datasheets, transform precisely, and adjust the values in
the osm db, just like anybody who finds nodes that are not placed
correctly in horizontal coordinates is welcome to move them to better
places".


Not addressed at Mark, but I find the insistence that we have a real
problem to be hard to understand.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Simon Poole  writes:

> Am 04.05.2020 um 15:19 schrieb Kevin Kenny:
>> Elevation as height-above-ellipsoid, unless you're using it in the
>> intermediate results of a GPS calculation, is nonsensical.
>
> However if you read the argumentation on the Altitude page that was
> exactly the reasoning: store hae and therefore be able to calculate
> datum specific heights easily after the fact.

Yes, but this is a ridiculous stramwan.   HAE and height above wgs84
geoid are equally well defined, but one (height above geoid) is what is
used for height and also happens to be almost matching all civil height
systems.


The real point here is that people want to take data that has a number
but not a datum and enter it and feel good about themelves, instead of
realizing and admitting that they are doing something fundamentally
wrong.  I am perfectly ok with entering a height that has no datum, and
having some meta key that basically says that the height value is
inaccurate, and perhaps "ele:datum=unknown" is good for this, crisply
denoting that the height is without a solid basis.

But, I find it unreasonable that people want to legitimize this sort of
confusion, rather than mark it as confusion as a warning to others.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Simon Poole]

Am 04.05.2020 um 15:19 schrieb Kevin Kenny:
> Elevation as height-above-ellipsoid, unless you're using it in the
> intermediate results of a GPS calculation, is nonsensical.

However if you read the argumentation on the Altitude page that was
exactly the reasoning: store hae and therefore be able to calculate
datum specific heights easily after the fact.




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

sent from a phone

> On 4. May 2020, at 23:20, Joseph Eisenberg  wrote:
> 
> Is there a reason to use this new tag ele:regional instead of ele:local=* 
> which is already mentioned on the Key:ele page?
> 
> "The elevation in a local datum can be tagged as ele:local=*, with elevation 
> specified in metres


when I have read the discussion for ele:local I had come to the impression that 
it is about something else: 
https://wiki.openstreetmap.org/wiki/Talk:Key:ele:local

Cheers Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Joseph Eisenberg]

Is there a reason to use this new tag ele:regional instead of ele:local=*
which is already mentioned on the Key:ele page?

"The elevation in a local datum can be tagged as ele:local=*, with
elevation specified in metres."

https://wiki.openstreetmap.org/wiki/Key:ele - under "basics" - added back
in 2012:
https://wiki.openstreetmap.org/w/index.php?title=Key:ele=811890

-- Joseph Eisenberg

On Mon, May 4, 2020 at 1:58 PM Martin Koppenhoefer 
wrote:
>
>
>
> sent from a phone
>
> >> On 4. May 2020, at 18:54, Greg Troxel  wrote:
> > This really feels like solving a non-problem.  If you just put what's
> > on the sign in ele, and don't worry about it, that's ok.  If somebody
> > else actually makes a valid, hard-core measuremnt, and fixes it, even
> > better.
>
>
> I thought it could help to have a key which explicitly states that you
just took a value from somewhere else, which is probably using a reference
that is regionally typical (i.e. you took a height from a sign, normally
you will not know which reference is used (sea level of some kind)). When I
find signs on the ground with height information I’m always reluctant to
add the values as it’s not clear whether I should transform them and if
yes, from where to where. The wiki isn’t very clear either.
>
> When you are making a valid hardcore measurement it would be a pity to
throw it into “ele” with its unknown specifics, you’d likely want to be
more precise (I agree ele:datum is fine for this) and a specific tag seems
also more save from being carelessly modified.
>
> Cheers Martin
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

sent from a phone

>> On 4. May 2020, at 18:54, Greg Troxel  wrote:
> This really feels like solving a non-problem.  If you just put what's
> on the sign in ele, and don't worry about it, that's ok.  If somebody
> else actually makes a valid, hard-core measuremnt, and fixes it, even
> better.  


I thought it could help to have a key which explicitly states that you just 
took a value from somewhere else, which is probably using a reference that is 
regionally typical (i.e. you took a height from a sign, normally you will not 
know which reference is used (sea level of some kind)). When I find signs on 
the ground with height information I’m always reluctant to add the values as 
it’s not clear whether I should transform them and if yes, from where to where. 
The wiki isn’t very clear either. 

When you are making a valid hardcore measurement it would be a pity to throw it 
into “ele” with its unknown specifics, you’d likely want to be more precise (I 
agree ele:datum is fine for this) and a specific tag seems also more save from 
being carelessly modified.

Cheers Martin 




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Peter Elderson]

If you know the elevation in one system, can the elevation the other
systems be derived from that?

Vr gr Peter Elderson


Op ma 4 mei 2020 om 20:05 schreef Mark Wagner :

> On Sun, 3 May 2020 14:16:09 +0200
> Martin Koppenhoefer  wrote:
>
> > sent from a phone
> >
> > > On 3. May 2020, at 13:06, Volker Schmidt  wrote:
> > >
> > > When I see an elevation value on the ground I do not see any
> > > reference to the reference system, so I cannot know, as a mapper,
> > > what reference system is at the base of the informaton that I find
> > > on the ground. In that respect the proposal is not at all clear
> > > from a practical perspective
> >
> >
> > the idea is you do not even have to know, simply copy the value from
> > the sign.
>
> What about regions where two or more reference systems are in common
> use?  If I copy an elevation from a USGS benchmark and put it in
> "ele:regional", how does an end-user know if it's a recent benchmark
> measured in NAVD 88 or an older benchmark measured in NVGD 29?
>
> --
> Mark
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Mark Wagner]

On Sun, 3 May 2020 14:16:09 +0200
Martin Koppenhoefer  wrote:

> sent from a phone
> 
> > On 3. May 2020, at 13:06, Volker Schmidt  wrote:
> > 
> > When I see an elevation value on the ground I do not see any
> > reference to the reference system, so I cannot know, as a mapper,
> > what reference system is at the base of the informaton that I find
> > on the ground. In that respect the proposal is not at all clear
> > from a practical perspective  
> 
> 
> the idea is you do not even have to know, simply copy the value from
> the sign. 

What about regions where two or more reference systems are in common
use?  If I copy an elevation from a USGS benchmark and put it in
"ele:regional", how does an end-user know if it's a recent benchmark
measured in NAVD 88 or an older benchmark measured in NVGD 29?

-- 
Mark

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> So the question is how we can solve this. We could discourage the use of
> the "naked ele" and encourage to always use a more specific subtag, e.g.

But is there significant amounts of data that have ele as ellipsoidal
height, more so than the prevalence of somewhat wrong data in OSM?   If
not, there is nothing to be gained from tag churn.

> - ele:egm96= to mean ele referring to the EGM96 geoid

Again this makes life difficult for data consumers.  Plus it's EGM08
now, and approximately zero people are clear on which of these flavors
they or any device are using.

> - ele:wgs84= to mean ele based on the WGS84 ellipsoid (or maybe

This is very confusing and therefore a bad idea.  Elevation in WGS84 is
obviously, to those who really understand height, intended to mean heigh
above geoid.  Nobody with the slightest respect for existing practice
would ever use the word "elevation" to mean "height above ellipsoid".

And, I don't think we should encourage HAE to be stored in OSM at all.

> "ele:ellipsoid" which would imply the WGS84 ellipsoid?)

Also very confusing, as in the US ellipsoidal heights are often relative
to the NAD83 ellipsoid.  However, people that use them are clear on what
they are doing and they are labeled correctly.

> and whichever height reference system is used, e.g.
> - ele:dhhn92
> - ele:tm75
> and more: https://taginfo.openstreetmap.org/search?q=ele%3A
>
> - ele:regional for "I have no idea but it was written on a sign", could
> still be a way to be expressive about the reliability. For many use cases
> +- 50m is better than no information. We could also keep "ele" for this
> like you suggested, although it wouldn't be explicit then.

This really feels like solving a non-problem.  If you just put what's
on the sign in ele, and don't worry about it, that's ok.  If somebody
else actually makes a valid, hard-core measuremnt, and fixes it, even
better.  But this is just like having approximate horizontal coordinates
- if a hotel is 10m off from where  it should be, that's stil useful and
somebody can and will fix it later.


You still haven't articulated that there is a real problem  to be
solved, or made an argument that my proposal for ele and ele:datum is
unsuitable.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Mo., 4. Mai 2020 um 13:10 Uhr schrieb Simon Poole :

> The previous versions of the page in particular the one that was actually
> voted on (in 2007) does -not- have that reference, see also
> https://wiki.openstreetmap.org/wiki/Talk:Key:ele for discussion on the
> issue back to 2007.
>


yes, it is true that the original proposal in 2007 didn't have this
reference. But it was quite common at that time (think about it, in the
first 4 months, only 5 people have voted on the proposal), that some time
later, like in 2008, a tag definition was refined after discussion, when it
had turned out that there had been some omissions in the original draft.

The discussion about the geodetic datum in 2007 is indeed already pointing
at the problem of the reference, but I only see one person (inas) arguing
in favor of the ellipsoid.



> As to the original page being German, well that 2007 is the time the
> German speaking community discovered OSM and started what actually turned
> it in to a success. Pretending that things didn't happen because they were
> originally in German at the time, is negating large bits of OSMs history.
>

still it would also be neglecting reality to say that the Germans had the
Definitionshochheit for the global use of the ele tag in 2007. People who
didn't speak German, or who didn't read the wiki in all of its detail, will
have used the tag with their own idea what it means. IMHO you can't say the
global usage of "ele" today is in any way influenced by what was written on
a wiki page called de:altitude in 2007.

So the question is how we can solve this. We could discourage the use of
the "naked ele" and encourage to always use a more specific subtag, e.g.

- ele:egm96= to mean ele referring to the EGM96 geoid
- ele:wgs84= to mean ele based on the WGS84 ellipsoid (or maybe
"ele:ellipsoid" which would imply the WGS84 ellipsoid?)
and whichever height reference system is used, e.g.
- ele:dhhn92
- ele:tm75
and more: https://taginfo.openstreetmap.org/search?q=ele%3A

- ele:regional for "I have no idea but it was written on a sign", could
still be a way to be expressive about the reliability. For many use cases
+- 50m is better than no information. We could also keep "ele" for this
like you suggested, although it wouldn't be explicit then.

Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Kevin Kenny]

On Mon, May 4, 2020 at 9:16 AM Greg Troxel  wrote:
> It is a good guess that signs you see are in your
> national vertical datum.  But some (most?) places have multiple datums,
> and it seems very likely that values people have known have been copied
> forward on signs for who knows how long, and there's no way to tell
> which one is meant.This is true on the US for things like mountains
> and "highest point on the masschusetts turnpike" signs -- which lacks a
> datum.

They're also likely obtained by looking at contour lines on a topo,
and are likely to be 10 m away from the actual value, whatever datum
is supposedly in use. (Or they were simply obtained by division of
levels, long before satellite geodesy).  In that case, the choice of
datum is of no significance at all. (But using the ellipsoid is still
Just Plain Wrong.)

I'd wager that virtually all `ele=*` values in OSM are tabulated only
to that level of accuracy. and as long as we say that _some_ modern
vertical datum (say, NAVD 29 or newer) is used rather than the
ellipsoid, we should be Just Fine.

Many peaks in the lists near me (such as Adirondack 46, Catskill 3500)
have their elevations quoted as the highest closed contour line on the
old USGS topos. Since the summits were used only as vertical controls,
their altitudes weren't measured that precisely. Many were used as
horizontal controls, and some of the trig points there are used as
part of a network that measures continental drift, since we have 150
years of data. The state survey of the 1870s was surprisingly good,
and the placement of first-order controls included astrometric
measurement of the deflection of the vertical.

Obligatory Colvin drawing from the state survey:
https://upload.wikimedia.org/wikipedia/commons/9/93/Division_of_Levels_-_Measurement_of_Whiteface_Mountain.jpg
Obligatory photo of Kevin's boots at a trig point
https://flickr.com/photos/ke9tv/9514568039

-- 
73 de ke9tv/2, Kevin

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Kevin Kenny]

On Mon, May 4, 2020 at 8:53 AM Greg Troxel  wrote:
> I'll also say that this alternate datum notion is irregular, in that we
> expect horizontal positions to be transformed from national horizontal
> datums to WGS84, and that putting in a tag to say that coordinates were
> in some other datum would be, I think, considered madness.  Instead, we
> expect people to transform any such data to WGS84.  (And we realize that
> meter level shifts are not that important usually, because measurements
> and source data is rarely that good.)

To muddy the waters further, while WGS84 included a geoid model,
virtually nobody uses it. It's been deprecated for over 20 years.

Elevations quoted as 'WGS84 elevation' (as opposed to
height-above-ellipsoid) are virtually always relative to EGM96,
Generally speaking, published topographic maps will cite separately
which horizontal and vertical datums they use. (Newer stuff might use
EGM 08, but the two agree to less than a meter almost everywhere.

Elevation as height-above-ellipsoid, unless you're using it in the
intermediate results of a GPS calculation, is nonsensical.

-- 
73 de ke9tv/2, Kevin

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Volker Schmidt  writes:

> I am not an expert, but it looks as if the Wiki page Key:ele
>  is not up-to-date.
> I thought that WGS84 uses the EGM96 Geoid, named "WGS84 EGM96 Geoid".
> Hence there should be no difference between WGS84 and EGM96 elevations.

To be somewhat pedantic, EGM96 is a function that takes lat/lon as input
and produces a value which is the offset of the ellipsoid and  the geoid
(equal-gravity surface).   So "EGM96 elevation" is a big awkward.   But,
one uses WGS84 ellipsoidal height and EGM96 to get "WGS84 altitude".

I believe EGM96 was replaced with EGM08:
  https://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_wgs84.html

But this is basically an update with more precision, so it's very much
the same thing.

> Also it would be helpful, f you could give examples of local elevation
> systems which would need explicit tagging.
> When I see an elevation value on the ground I do not see any reference to
> the reference system, so I cannot know, as a mapper, what reference system
> is at the base of the informaton that I find on the ground. In that respect
> the proposal is not at all clear from a practical perspective.

Completely agreed.  It is a good guess that signs you see are in your
national vertical datum.  But some (most?) places have multiple datums,
and it seems very likely that values people have known have been copied
forward on signs for who knows how long, and there's no way to tell
which one is meant.This is true on the US for things like mountains
and "highest point on the masschusetts turnpike" signs -- which lacks a
datum.  The wikipedia article doesn't address this point :-)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Basically I think the whole elevation as height above ellipsoid is
mostly a huge misunderstanding, and I wonder how much support there is
for it.

My memory matches what Martin pointed to: ele= is "height above sea
level".  And, given that layman's terms description, and that OSM is
using WGS84, then it seems really obvious that the particular flavor of
"height above sea level" should be "WGS84 altitude" meaning "height
above the WGS84 geoid".

In the US, ele= tags typically have the NAVD88 height, from GNIS, or
elevations from GPS receivers that do geoid corrections (e.g. Garmin).
(Yes, there's slight fuzz but it's tiny compared to vertical GPS
accuracy.)

The talk page you pointed to says "elevation should be WGS84 because we
use GPS" and then reasons that this must be HAE, even though almost no
GPS receiver used by a mapper (pre android) would have been showing HAE.
In fact, to this day I have not seen a GPS receiver (other than geodetic
survey type ones) display height in HAE (without labeling it as such),
other than buggy android apps.

So it's likely that people were using what their receivers displayed
(height above geoid) and perhaps just thought that was HAE, rather than
really intending to use height values with huge differences from
conventional height datums.

Stepping back from untangling the history, I have three questions about
ele=:

  1) Does anybody think it makes sense to use HAE in OSM, vs "WGS84
  elevation" meaning heigth above geoid?

  2) Are there lots of points in OSM that actually have ele in HAE?  (I
  am unaware of any such points in the US.)

  3) Are there any national height datums that are ellipsoidal height?
  (I think not, because height is very much about water and therefore
  about gravity.)  If not, why is it sensible for OSM to start doing
  this?  IMHO, OSM should follow existing standards and practices of the
  relevant fields in terms of definitions, to the extent that this is
  sensible.



So I would propose:

  adjust ele page to be very clear that this is WGS84 altitude (height
  above geoid) and caution about bad data on some android apps.

  mark Altitude page as an old proposal that has no current support



and if that's off base it would be good to hear from people how it's
off, and why.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Following up to myself, a few things I didn't have time to say last
night.

Once we accept that the base notion of ele= means WGS84 geoid height
(meaning the MSL sort of height), and that ellipsoidal heights basically
have no place in OSM, then:

  0) The entire notion of looking at a sign on a mountain and believing
  that is suspect.  I certainly think it's fair to put in a sign object
  with an inscription, as "there is a sign" is a fact.  But on mountains
  here, there is often some number in feet, and it's never clear whether
  that's in NGVD29, or NAVD88.  Often the number doesn't change much and
  it doesn't matter.  But a sign with a number without a datum has to be
  taken with a huge grain of salt.  (As I understand it, most countries
  have a 20s-50s generation height system and an 80s/90s height system,
  and many are moving to a 2020s height system.)

  1) For this proposal to be considered, we need to have examples of how
  different elevations are between "WGS84 altitude" and various national
  height datums.  In the US, the differences are at the meter or so
  level.  So while the ability to enter national datum heights without
  losing accuracy is useful, there is complexity in use to trade off
  against that.  I suspect that differences from most other national
  vertical datum to WGS84 are small.

  2) As always, I am concerned that tagging discussions tend to focus on
  what taggers want to represent and not be so concerned with how data
  consumers uses the tags.  Tags are after all a protocol that is
  written by mappers and read by renderers, routers, etc.  It's
  therefore important that simpler data consumers get sensible answers,
  and that mappers being less precise provide data that is not grossly
  wrong.

  Therefore, if we're going to represent this, I think we should say:

ele=
ele:datum=

  where ELEVATION is some sort of "height above sea level", where the
  main/primary datum is the WGS84/EGM, and if it is in some other datum
  (e.g. NAVD88 in the US and I am seeing various other ones on the
  list), then ele:datum denotes that datum.  This means that if a mapper
  just puts in an elevation, ignoring vertical datum, or if a renderer
  ignores it then nothing terrible happens, just a meter or two of fuzz.
  And, if the mapper is precise, and the renderer deals, then all is ok
  with no loss of precision due to datum issues.


I'll also say that this alternate datum notion is irregular, in that we
expect horizontal positions to be transformed from national horizontal
datums to WGS84, and that putting in a tag to say that coordinates were
in some other datum would be, I think, considered madness.  Instead, we
expect people to transform any such data to WGS84.  (And we realize that
meter level shifts are not that important usually, because measurements
and source data is rarely that good.)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Peter Elderson  writes:

> Thanks for explaining why my android phone says I am at +38m (+/- 3) in my
> backyard when in fact it is at Dutch sea level -4.4m.

Well, I didn't quite.   The location API returns HAE.For a program
to show that value to a human as "elevation" is buggy.   So in addition
to what I said, you have to add "your software is buggy".   File a bug
with that app!

On Android:

  install GPSTest (available in F-Droid).  It will show two heights.
  One is mislabeled "Alt", when it should say HAE*, and the other is "Alt
  (MSL)" which is the WGS84 sea level type height.
  * I have discussed with the author, but the notion is that people will
be baffled by HAE.  However, I think that's better than
misinterpreting it as a gravity-based height

  install OsmAnd.  In addition to maps, get the "World Altitude
  Correction" map.  This is really the WGS84 gravity model, and when it
  is loaded OsmAnd will convert HAE from Android to height above the
  WGS84 gravity surface
  

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Simon Poole]

The previous versions of the page in particular the one that was
actually voted on (in 2007) does -not- have that reference, see also
https://wiki.openstreetmap.org/wiki/Talk:Key:ele for discussion on the
issue back to 2007.

As to the original page being German, well that 2007 is the time the
German speaking community discovered OSM and started what actually
turned it in to a success. Pretending that things didn't happen because
they were originally in German at the time, is negating large bits of
OSMs history.

Simon

Am 04.05.2020 um 12:04 schrieb Martin Koppenhoefer:
> Am Mo., 4. Mai 2020 um 10:50 Uhr schrieb Simon Poole  >:
>
> Historically the understanding was that ele would use "height
> above the
> ellipsoid", there is some reasoning on the Altitude page, might have
> made sense originally. In 2013 the ele entry was fiddled to point
> to the
> height above geoid.
>
>
>
> in 2013 the altitude page was not really created yet, there was only a
> page in German which hardly can be seen as relevant for the global
> project. The "key:ele" page already referred to the geoid rather than
> the ellipsoid in September 2008, as it said "height above sea level":
> https://wiki.openstreetmap.org/w/index.php?title=Key:ele=next=125595
> "Elevation (height above sea level) of a point in metres."
>
> Generally, the "altitude" term does not seem to catch it at all, it
> appears to mean a height _above_ ground, while with the "ele" tag and
> variations we are aiming at recording the actual ground elevation.
>
>
>
> This leaves us with
>
> a) conflicting definitions in the wiki (not the first time)
>
> b) a tag de-facto redefined after multiple years of use (natural=tree
> anybody?)
>
>
>
> not really comparable, because "a tree" is very clear, "a ground
> elevation" isn't (because it refers to a reference which isn't given)
>
>  
>
>
> Naturally the correct way to solve the issue would have been to
> introduce a new tag with the appropriate semantics and then let
> ele die
> out. Given that the mess has already happened it could be argued
> that we
> might as well use ele with the semantics that have been proposed for
> ele:regional, because that is what it "mostly"* has been used for.
>
>
>
> this would mean repeating the same mistake as 2013, continue to use
> the same tag for which it was already discovered that the values are
> referring to different references (well knowing, that not all values
> refer to the definition, some are referring to the WGS84 ellipsoid,
> some are referring to a geoid)
>
>
> Cheers
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Mo., 4. Mai 2020 um 10:50 Uhr schrieb Simon Poole :

> Historically the understanding was that ele would use "height above the
> ellipsoid", there is some reasoning on the Altitude page, might have
> made sense originally. In 2013 the ele entry was fiddled to point to the
> height above geoid.
>


in 2013 the altitude page was not really created yet, there was only a page
in German which hardly can be seen as relevant for the global project. The
"key:ele" page already referred to the geoid rather than the ellipsoid in
September 2008, as it said "height above sea level":
https://wiki.openstreetmap.org/w/index.php?title=Key:ele=next=125595
"Elevation (height above sea level) of a point in metres."

Generally, the "altitude" term does not seem to catch it at all, it appears
to mean a height _above_ ground, while with the "ele" tag and variations we
are aiming at recording the actual ground elevation.



This leaves us with
>
> a) conflicting definitions in the wiki (not the first time)
>
> b) a tag de-facto redefined after multiple years of use (natural=tree
> anybody?)
>


not really comparable, because "a tree" is very clear, "a ground elevation"
isn't (because it refers to a reference which isn't given)



>
> Naturally the correct way to solve the issue would have been to
> introduce a new tag with the appropriate semantics and then let ele die
> out. Given that the mess has already happened it could be argued that we
> might as well use ele with the semantics that have been proposed for
> ele:regional, because that is what it "mostly"* has been used for.
>


this would mean repeating the same mistake as 2013, continue to use the
same tag for which it was already discovered that the values are referring
to different references (well knowing, that not all values refer to the
definition, some are referring to the WGS84 ellipsoid, some are referring
to a geoid)


Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Simon Poole]

Just so that it is clear for everybody what the issue is about,  Android
is not really relevant outside of resurfacing it.

Historically the understanding was that ele would use "height above the
ellipsoid", there is some reasoning on the Altitude page, might have
made sense originally. In 2013 the ele entry was fiddled to point to the
height above geoid.

This leaves us with

a) conflicting definitions in the wiki (not the first time)

b) a tag de-facto redefined after multiple years of use (natural=tree
anybody?)

Naturally the correct way to solve the issue would have been to
introduce a new tag with the appropriate semantics and then let ele die
out. Given that the mess has already happened it could be argued that we
might as well use ele with the semantics that have been proposed for
ele:regional, because that is what it "mostly"* has been used for.

Simon

* if would naturally be nice if that wasn't just based on speculation.

Am 04.05.2020 um 02:37 schrieb Greg Troxel:
> Martin Koppenhoefer  writes:
>
>> I’m asking for comments on 
>> https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional
> Two big comments:
>
>   First, the current wiki documentation about ele and Altitude should be
>   really straigthened out, so that we have a basis for what we are
>   comparing to.
>
>   Second, the notion of a single regional vertical datum doesn't really
>   work.  In the US, that could be the old NGVD29, or the current NAVD88.
>   Plus, we are about to get NATRF2022.  However, all of these are within
>   a meter or so, and in terms of vertical data in OSM, that's not really
>   a big problem.  So if there is going to be precision, then we should
>   follow GIS and have an explicit datum.  I would say an EPSG code is
>   sensible -- see the proj package for canonical values.
>
>
>
> As for ele/Altitude, there is great confusion out there about "WGS84"
> and two separate concepts:
>
>   height above the ellipsoid.  Often written HAE. The ellipsoid is a
>   mathematical surface that is NOT a surface of equal gravity.  While
>   geodesists and geodetic surveyors use it, and while it's part of the
>   calculations within GPS, I am not aware of a single vertical datum in
>   use in any country that is relative to the ellipisoid.  Note that
>   water does not flow "downhill" when "down" means to a lower value of
>   HAE.  Water is hugely important in elevation and mapping.
>
>   height above geoid, or height above a reference equal-gravity surface,
>   or height above sea level.  (Yes, I realize that "sea level" is a huge
>   can of worms.)   This is more or less what every height system uses or
>   intends to use.
>
>
> In WGS84, one gets from the base computation lat/lon and a height above
> the ellipsoid.  This is purely a geometric answer and is totally
> disconnected from grravity.  Then, GPS receivers use a gravity model to
> compute the offset from the ellipsoid and the reference gravity surface
> (which is more or less the "sea level surface"), and they them use that
> to get a "height above sea level".  Receivers that display to humans
> display this sea level height.  NMEA has that same sea level height.
>
> (Android stands alone in that the API returns height above ellipsoid.
> That's not wrong, but it is unusual.  IMHO how Android defines an
> interface is irrelevant to OSM's definitions.)
>
>
> When people say "WGS84 altitude", they mean the height above the WGS84
> equal-gravity surface as computed from the ellipsoidal height and the
> gravity model.  This is sort of 0m at sea level.  Note that the
> ellipsoid can be 100m different from this equal-gravity surface, and is
> often significantly different.  It's ~30m in Boston and I hear it's 50m
> in Switzerland.  Nobody who says "WGS84 altitude" really means "WGS84
> ellipsoidal height".  If they did, they would say "WGS84 ellipsoidal
> height".
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Colin Smale]

On 2020-05-04 09:10, Peter Elderson wrote:

> Thanks for explaining why my android phone says I am at +38m (+/- 3) in my 
> backyard when in fact it is at Dutch sea level -4.4m.

GPS receivers, including Android phones, should adjust the GPS WSG84
height to "sea level". But the vertical accuracy of GPS is much less
than the horizontal accuracy, and it needs more satellites in the fix to
give a decent altitude. I live pretty much at 0m NAP, and the altitude
it shows varies a lot, both above and below zero.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Peter Elderson]

Thanks for explaining why my android phone says I am at +38m (+/- 3) in my
backyard when in fact it is at Dutch sea level -4.4m.

Best, Peter Elderson


Op ma 4 mei 2020 om 02:39 schreef Greg Troxel :

> Martin Koppenhoefer  writes:
>
> > I’m asking for comments on
> https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional
>
> Two big comments:
>
>   First, the current wiki documentation about ele and Altitude should be
>   really straigthened out, so that we have a basis for what we are
>   comparing to.
>
>   Second, the notion of a single regional vertical datum doesn't really
>   work.  In the US, that could be the old NGVD29, or the current NAVD88.
>   Plus, we are about to get NATRF2022.  However, all of these are within
>   a meter or so, and in terms of vertical data in OSM, that's not really
>   a big problem.  So if there is going to be precision, then we should
>   follow GIS and have an explicit datum.  I would say an EPSG code is
>   sensible -- see the proj package for canonical values.
>
>
>
> As for ele/Altitude, there is great confusion out there about "WGS84"
> and two separate concepts:
>
>   height above the ellipsoid.  Often written HAE. The ellipsoid is a
>   mathematical surface that is NOT a surface of equal gravity.  While
>   geodesists and geodetic surveyors use it, and while it's part of the
>   calculations within GPS, I am not aware of a single vertical datum in
>   use in any country that is relative to the ellipisoid.  Note that
>   water does not flow "downhill" when "down" means to a lower value of
>   HAE.  Water is hugely important in elevation and mapping.
>
>   height above geoid, or height above a reference equal-gravity surface,
>   or height above sea level.  (Yes, I realize that "sea level" is a huge
>   can of worms.)   This is more or less what every height system uses or
>   intends to use.
>
>
> In WGS84, one gets from the base computation lat/lon and a height above
> the ellipsoid.  This is purely a geometric answer and is totally
> disconnected from grravity.  Then, GPS receivers use a gravity model to
> compute the offset from the ellipsoid and the reference gravity surface
> (which is more or less the "sea level surface"), and they them use that
> to get a "height above sea level".  Receivers that display to humans
> display this sea level height.  NMEA has that same sea level height.
>
> (Android stands alone in that the API returns height above ellipsoid.
> That's not wrong, but it is unusual.  IMHO how Android defines an
> interface is irrelevant to OSM's definitions.)
>
>
> When people say "WGS84 altitude", they mean the height above the WGS84
> equal-gravity surface as computed from the ellipsoidal height and the
> gravity model.  This is sort of 0m at sea level.  Note that the
> ellipsoid can be 100m different from this equal-gravity surface, and is
> often significantly different.  It's ~30m in Boston and I hear it's 50m
> in Switzerland.  Nobody who says "WGS84 altitude" really means "WGS84
> ellipsoidal height".  If they did, they would say "WGS84 ellipsoidal
> height".
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> I’m asking for comments on 
> https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional

Two big comments:

  First, the current wiki documentation about ele and Altitude should be
  really straigthened out, so that we have a basis for what we are
  comparing to.

  Second, the notion of a single regional vertical datum doesn't really
  work.  In the US, that could be the old NGVD29, or the current NAVD88.
  Plus, we are about to get NATRF2022.  However, all of these are within
  a meter or so, and in terms of vertical data in OSM, that's not really
  a big problem.  So if there is going to be precision, then we should
  follow GIS and have an explicit datum.  I would say an EPSG code is
  sensible -- see the proj package for canonical values.



As for ele/Altitude, there is great confusion out there about "WGS84"
and two separate concepts:

  height above the ellipsoid.  Often written HAE. The ellipsoid is a
  mathematical surface that is NOT a surface of equal gravity.  While
  geodesists and geodetic surveyors use it, and while it's part of the
  calculations within GPS, I am not aware of a single vertical datum in
  use in any country that is relative to the ellipisoid.  Note that
  water does not flow "downhill" when "down" means to a lower value of
  HAE.  Water is hugely important in elevation and mapping.

  height above geoid, or height above a reference equal-gravity surface,
  or height above sea level.  (Yes, I realize that "sea level" is a huge
  can of worms.)   This is more or less what every height system uses or
  intends to use.


In WGS84, one gets from the base computation lat/lon and a height above
the ellipsoid.  This is purely a geometric answer and is totally
disconnected from grravity.  Then, GPS receivers use a gravity model to
compute the offset from the ellipsoid and the reference gravity surface
(which is more or less the "sea level surface"), and they them use that
to get a "height above sea level".  Receivers that display to humans
display this sea level height.  NMEA has that same sea level height.

(Android stands alone in that the API returns height above ellipsoid.
That's not wrong, but it is unusual.  IMHO how Android defines an
interface is irrelevant to OSM's definitions.)


When people say "WGS84 altitude", they mean the height above the WGS84
equal-gravity surface as computed from the ellipsoidal height and the
gravity model.  This is sort of 0m at sea level.  Note that the
ellipsoid can be 100m different from this equal-gravity surface, and is
often significantly different.  It's ~30m in Boston and I hear it's 50m
in Switzerland.  Nobody who says "WGS84 altitude" really means "WGS84
ellipsoidal height".  If they did, they would say "WGS84 ellipsoidal
height".


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

sent from a phone

> On 3. May 2020, at 15:23, Jarek Piórkowski  wrote:
> 
> What happens when the sign is replaced or removed?


if the information on the sign is replaced you should obviously update the 
value, when it disappears I would not act, but I imagine the purist answer 
would be to remove the tag.

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Jarek Piórkowski]

On Sun, 3 May 2020 at 08:16, Martin Koppenhoefer  wrote:
> > On 3. May 2020, at 13:06, Volker Schmidt  wrote:
> > When I see an elevation value on the ground I do not see any reference to 
> > the reference system, so I cannot know, as a mapper, what reference system 
> > is at the base of the informaton that I find on the ground. In that respect 
> > the proposal is not at all  from a practical perspective
>
> the idea is you do not even have to know, simply copy the value from the sign.

What happens when the sign is replaced or removed?

You might want to change the wiki description to be much more explicit
that this is only what is given on a sign and not a "regionally common
reference system".

--Jarek

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

sent from a phone

>> On 3. May 2020, at 12:51, Andrew Harvey  wrote:
> There is an EPSG code https://spatialreference.org/ref/epsg/5711/ for the 
> datum, perhaps ele:epsg:5711= is better then.


A system like this would probably be ignored by 85-98% of our mappers, although 
I would encourage to use it if you know this.

Cheers Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

sent from a phone

> On 3. May 2020, at 13:06, Volker Schmidt  wrote:
> 
> When I see an elevation value on the ground I do not see any reference to the 
> reference system, so I cannot know, as a mapper, what reference system is at 
> the base of the informaton that I find on the ground. In that respect the 
> proposal is not at all clear from a practical perspective


the idea is you do not even have to know, simply copy the value from the sign. 

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Colin Smale]

On 2020-05-03 13:05, Volker Schmidt wrote:

> Martin 
> I am not an expert, but it looks as if the Wiki page Key:ele [1] is not 
> up-to-date. 
> I thought that WGS84 uses the EGM96 Geoid, named "WGS84 EGM96 Geoid".  Hence 
> there should be no difference between WGS84 and EGM96 elevations. 
> 
> Also it would be helpful, f you could give examples of local elevation 
> systems which would need explicit tagging. 
> When I see an elevation value on the ground I do not see any reference to the 
> reference system, so I cannot know, as a mapper, what reference system is at 
> the base of the informaton that I find on the ground. In that respect the 
> proposal is not at all clear from a practical perspective.

I think most countries with a coastline commonly use "sea level" as the
vertical basis. The definition of "sea level" differs from country to
country of course. NL uses "NAP" (Normaal Amsterdams Peil; normal
Amsterdam level) whereas Belgium uses "TAW" (Tweede Algemene
Waterpassing; second general water-levelling) as its basis. The
difference is 2.33m, which might not be so important for the heights of
mountains but along the coast it is critical for the correct
understanding of water depths, tides etc. The Westerschelde estuary
flows through NL until just before it reaches Antwerp (Belgium). To
avoid expensive misunderstandings it is essential that all bathymetric
data, tidal data, bridge heights etc be very clearly labelled with their
datum. 

  

Links:
--
[1] https://wiki.openstreetmap.org/wiki/Key:ele___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Volker Schmidt]

Martin
I am not an expert, but it looks as if the Wiki page Key:ele
 is not up-to-date.
I thought that WGS84 uses the EGM96 Geoid, named "WGS84 EGM96 Geoid".
Hence there should be no difference between WGS84 and EGM96 elevations.

Also it would be helpful, f you could give examples of local elevation
systems which would need explicit tagging.
When I see an elevation value on the ground I do not see any reference to
the reference system, so I cannot know, as a mapper, what reference system
is at the base of the informaton that I find on the ground. In that respect
the proposal is not at all clear from a practical perspective.

Yours confused
Volker

On Sun, 3 May 2020 at 12:06, Martin Koppenhoefer 
wrote:

> I’m asking for comments on
> https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional
>
> Cheers Martin
>
> sent from a phone
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Andrew Harvey]

I'm all for specifying elevation of mountain peaks etc in other datum which
may work better than WGS:84.

I think it's better to specify which datum the value is in, it'll be a
nightmare over time working out which datum the original mapper intended as
new datums are rolled out and are upgraded, and leaves confusion if there
are multiple datum in use.

ele:=value

Where  is the height datum.

Next question is then how to specify , in Australia we commonly use
https://www.ga.gov.au/scientific-topics/positioning-navigation/geodesy/ahdgm/ahd,
so could use ele:ahd but that probably collides with other anachronisms
globally so is not ideal. There is an EPSG code
https://spatialreference.org/ref/epsg/5711/ for the datum, perhaps
ele:epsg:5711= is better then.

I'm not sure if there are any issues legally using EPSG codes, but presume
it's okay.

On Sun, 3 May 2020 at 20:06, Martin Koppenhoefer 
wrote:

> I’m asking for comments on
> https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional
>
> Cheers Martin
>
> sent from a phone
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging