Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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.

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

> 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.

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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?

Re: [Tagging] RFC ele:regional

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:

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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.

Re: [Tagging] RFC ele:regional

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,

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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,

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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,

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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.

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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 >

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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. > >

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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,