date:20200504

On Mon, 4 May 2020 at 22:59, Marc M.  wrote:

> Le 04.05.20 à 23:19, Paul Allen a écrit :
> >
> > Except we don't all agree that they are for the same thing,
> > not even phone and contact:phone
>
> The only solution is to create other tags to better describe
> this difference.
>

That can work.  It can also mean we end up with four different tags
for the same two things.

>
> > I've added URLs for historic buildings
> > that give more information about the building.
>
> as for the plate, imho I would use website, but maybe url=*
> you said you added an url :)
>

I tend to use website when it's for the main page of a website and URL
for a page within a website.  Technically they're both URLs but we
don't have a webpage tag and I feel uncomfortable calling a single
page which is part of a much larger website a website.

>
> but if it's a valid argument, let's split the issue in 2 :
> for all poi (shop, office, craft, bar, restaurant), does phone
> and contact:phone have the same meaning or you have another undocumented
> meaning that explain it's not the same ?
>

For me, they're the same thing.  Others have different opinions on that.
And,
as Phil pointed out, we use phone for phone boxes.  Even if you managed to
persuade everyone to use contact:phone for everything else, we'd need
phone for phone boxes where there is nobody to contact.

and email<>contact:email ?
>

 There are email addresses that aren't for contacting human beings.  The
address to unsubscribe from this list is one such.  I can't think of any
reason we'd need to map that type of address, but my imagination is
limited.  So contact:email is fine by me.  But probably not by others.

Facebook is more problematic.  I've encountered facebook pages
which are just a way of getting a free web presence and are not
used as a way of contacting the organization.  From my
perspective, contact:facebook would only be applicable to
the m.me/user style URLs that fire up messenger.  But that's
just me.

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

Le 05.05.20 à 00:05, Martin Koppenhoefer a écrit :
>> On 4. May 2020, at 23:59, Marc M.  wrote:
>> for all poi (shop, office, craft, bar, restaurant), does phone
>> and contact:phone have the same meaning or you have another undocumented
>> meaning that explain it's not the same ?
> for me a phone booth is a poi. 

ok, rewording :
for all shop, office, craft, bar, restaurant,
does phone and contact:phone have the same meaning ?

> Are you proposing different tags for phone numbers, depending on the kind of 
> object they get tagged to?

I haven't proposed anything yet, I asked a question about
the meaning of the phone tag according to the context.
feel free to reply to the question :)

Regards, Marc

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme



sent from a phone

> On 4. May 2020, at 23:59, Marc M.  wrote:
> 
> for all poi (shop, office, craft, bar, restaurant), does phone
> and contact:phone have the same meaning or you have another undocumented
> meaning that explain it's not the same ?


for me a phone booth is a poi. Are you proposing different tags for phone 
numbers, depending on the kind of object they get tagged to?

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

Le 04.05.20 à 23:19, Paul Allen a écrit :
> On Mon, 4 May 2020 at 21:59, Marc M. wrote:
> 
> - avoid having 2 tags for the same thing.
> it's bad for both contributors and data-uses.
> 
> Except we don't all agree that they are for the same thing, 
> not even phone and contact:phone

read the page about forests (or the current discussion on
leisure=common): it doesn't matter *anymore* if some contributors make
a difference between the 2, in the end it's impossible to separate the
different meanings.
The only solution is to create other tags to better describe
this difference.

> I've added URLs for historic buildings
> that give more information about the building.

as for the plate, imho I would use website, but maybe url=*
you said you added an url :)

but if it's a valid argument, let's split the issue in 2 :
for all poi (shop, office, craft, bar, restaurant), does phone
and contact:phone have the same meaning or you have another undocumented
meaning that explain it's not the same ?
and email<>contact:email ?

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

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 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] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Philip Barnes



On Monday, 4 May 2020, Paul Allen wrote:
> On Mon, 4 May 2020 at 21:59, Marc M.  wrote:
> 
> >
> > - avoid having 2 tags for the same thing.
> > it's bad for both contributors and data-uses.
> >
> 
> Except we don't all agree that they are for the same thing, not even phone
> and contact:phone  That's one of the reasons this argument goes around and
> around.

Exactly, we add phone to phoneboxes, but its not the number to call to contact 
someone about the phonebox.

Phil (trigpoint)

> The other is that those who agree they are the same thing cannot agree on
> which
> of the two to use.
> 
> >
> > - using namespace for contact: (like we do with addr:) it's useful for
> > the use of the data (you can group them without having to hard-code
> > all the possible variants that may exist in the world).
> >
> 
> But not all of them are necessarily contacts.  I've added URLs for
> historic buildings that give more information about the building.  There is
> nobody to talk to about it.  I've added websites for companies; there is
> a contact page on that website but the URL I've given is for the company
> website as a whole.
> 
> -- 
> Paul
>

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

On Mon, 4 May 2020 at 21:59, Marc M.  wrote:

>
> - avoid having 2 tags for the same thing.
> it's bad for both contributors and data-uses.
>

Except we don't all agree that they are for the same thing, not even phone
and contact:phone  That's one of the reasons this argument goes around and
around.
The other is that those who agree they are the same thing cannot agree on
which
of the two to use.

>
> - using namespace for contact: (like we do with addr:) it's useful for
> the use of the data (you can group them without having to hard-code
> all the possible variants that may exist in the world).
>

But not all of them are necessarily contacts.  I've added URLs for
historic buildings that give more information about the building.  There is
nobody to talk to about it.  I've added websites for companies; there is
a contact page on that website but the URL I've given is for the company
website as a whole.

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

Re: [Tagging] RFC ele:regional

2020-05-04 Thread 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] Remove non-prefixed versions of 'contact:' scheme

Hello,

Le 04.05.20 à 14:48, Paul Allen a écrit :
> I haven't seen them.

the two reasons are:

- avoid having 2 tags for the same thing.
it's bad for both contributors and data-uses.

- using namespace for contact: (like we do with addr:) it's useful for
the use of the data (you can group them without having to hard-code
all the possible variants that may exist in the world).
it's obviously also useful for an editor (it could display a preset
listing all the contact keys:* without having to hard-code them in
the preset).

Regards,
Marc

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

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.  

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

2020-05-04 Thread 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] Doorzone bicycle lanes

2020-05-04 Thread Volker Schmidt

You are right that in case of cycling infrastructure tagged on the road
(like typically cycling lanes) we need a way to indicate to which part of
the road it refers, in addition to the type of haxard.


Il lun 4 mag 2020, 18:35 Jan Michel  ha scritto:

> On 03.05.20 19:16, Volker Schmidt wrote:
> > I would advocate a more generic approach that remains open to other
> > types of hazards (there are many, unfortunately).
> > A generic
> >
> hazard:bicycle=yes|dooring|pedestrians_on_cycleway|dangerous_exit|whatever
>
> I agree, but I would rather use
> cycleway:(left|right|both|):hazard
> 'hazard:bicycle' suggests that it is an hazard to all bicycles, but it's
> more like an hazard that is a "feature" of the cycleway. Everybody close
> to the cycleway is part of the hazard (whether active or passive) but
> bicycles in other places of the road are not affected.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/taggingäaa
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

2020-05-04 Thread 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] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread s8evq

I think you're exaggerating here. Just press 'delete' on you mail client if the 
discussion doesn't interest you and that's it.

On Mon, 4 May 2020 06:13:42 -0700 (MST), Richard Fairhurst 
 wrote:

> As someone with admin access over this mailing list, I request that you do
> not keep bringing back proposals which were extensively debated beforehand
> and generally rejected. It wastes everyone's time.
> 
> I don't particularly want to start banhammering people from the list but
> will do so if necessary.
> 
> Thank you.
> 
> Richard
> 

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

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 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] Doorzone bicycle lanes

2020-05-04 Thread Jan Michel


On 03.05.20 19:16, Volker Schmidt wrote:
I would advocate a more generic approach that remains open to other 
types of hazards (there are many, unfortunately).
A generic 
hazard:bicycle=yes|dooring|pedestrians_on_cycleway|dangerous_exit|whatever


I agree, but I would rather use
cycleway:(left|right|both|):hazard
'hazard:bicycle' suggests that it is an hazard to all bicycles, but it's 
more like an hazard that is a "feature" of the cycleway. Everybody close 
to the cycleway is part of the hazard (whether active or passive) but 
bicycles in other places of the road are not affected.



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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Sören alias Valor Naram via Tagging

> It is clear that "contact:" despite what the wiki says, will always mean "contact", while websites, facebook pages and whatever else is suggested to be put under "contact" will not always have a contacting possibility (and will often have a broader scope than just "contact").Then we can deprecate contact:facebook, contact:twitter and the other social media platforms inside the `contact` prefix? If they have a broader scope than just "contact" this should be fine no? And then deprecating Key:phone, Key:email and Key:website in favor of their sisters should be no problem. The keys can be translated via a mechanical edit.~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Remove non-prefixed versions of 'contact:' schemeFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: Am Mo., 4. Mai 2020 um 17:46 Uhr schrieb Sören alias Valor Naram :> because some will feel that A and contact:A are not the same thingWell, the specification says that they are the same thing by mentioning both are used to tag contact information. If they're not the same thing then the ones saying that should explain why and name some examples so we can discuss and find a solution for these cases (if any). But also from these people I did not get any input.please read up the former discussion, this was already discussed. It is clear that "contact:" despite what the wiki says, will always mean "contact", while websites, facebook pages and whatever else is suggested to be put under "contact" will not always have a contacting possibility (and will often have a broader scope than just "contact").CheersMartin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Dave F via Tagging


Hi

 I request to replace all occurrence of the prefixed versions of the 
contact keys, as it adds no quality to the OSM database




On 04/05/2020 11:53, Valor Naram via Tagging wrote:

   I request to replace all occurrence of the non-prefixed versions of the 
contact keys like Key:phone, Key:email. Key:website to be replaced with the 
prefixed ones like Key:contact:phone, Key:contact:email, Key:contact:website . 
The current situation harms our database in a way that makes our data less 
useful. In order to be successful we need to standardize to the contact:
  prefix. No more multiple keys for the exact same purpose with just
different names!


But there would still be "multiple keys" (contact:phone, :contact:email etc)


  Make tagging more orthogonal! As someone who has
experience in database and normalisation it hurts to see that mappers
don't know how to take care of a database. It is time to take action and
  to clean up so OSM data gets more useful.


  * Normalisation of that data is required. Key:phone must be
translated to Key:contact:phone or backwards.


No it doesn't


  * Having two schemes leads to confusion of mappers (especially
for newbies) which they should use.


Then get rid the the 'contact' schema

DaveF

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

Am Mo., 4. Mai 2020 um 17:46 Uhr schrieb Sören alias Valor Naram <
valin...@gmx.net>:

> > because some will feel that A and contact:A are not the same thing
>
> Well, the specification says that they are the same thing by mentioning
> both are used to tag contact information. If they're not the same thing
> then the ones saying that should explain why and name some examples so we
> can discuss and find a solution for these cases (if any). But also from
> these people I did not get any input.




please read up the former discussion, this was already discussed. It is
clear that "contact:" despite what the wiki says, will always mean
"contact", while websites, facebook pages and whatever else is suggested to
be put under "contact" will not always have a contacting possibility (and
will often have a broader scope than just "contact").

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Sören alias Valor Naram

> - because too much use (saying that a problem that's too big doesn't need to be solved is pretty absurd).A mechanical edit could convert them to their respective `contact:` subkey sisters and solves that big problem. Also editor and customers changing their presets is not that difficult because in OSM new schemes are approved all the time and some others deprecated and translated to a new scheme (if possible and if it can be done securely then via mechanical edit)> because some will feel that A and contact:A are not the same thingWell, the specification says that they are the same thing by mentioning both are used to tag contact information. If they're not the same thing then the ones saying that should explain why and name some examples so we can discuss and find a solution for these cases (if any). But also from these people I did not get any input.~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Remove non-prefixed versions of 'contact:' schemeFrom: "Marc M." To: tagging@openstreetmap.orgCC: Hello,Le 04.05.20 à 12:53, Valor Naram via Tagging a écrit :> replace all occurrence of the non-prefixed versions of the contact keysalthough I totally agree with the idea, I can't imagine a global massagreement to make it happen.as in the previous version, you're going to have opinions against it:- because too much use (saying that a problem that's too big doesn'tneed to be solved is pretty absurd).- because some will feel that A and contact:A are not the same thingRegards,Marc___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Sören alias Valor Naram

> As an alternative, why not get rid of the contact:* versions since mostpeople are not using them?I tried this in the first round and people rejected it with the reason that this is the newer one which should be used~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Remove non-prefixed versions of 'contact:' schemeFrom: "Shawn K. Quinn" To: tagging@openstreetmap.orgCC: On 5/4/20 05:53, Valor Naram via Tagging wrote:> I request to replace all occurrence of the non-prefixed versions of> the contact keys like Key:phone, Key:email. Key:website to be> replaced with the prefixed ones like Key:contact:phone,> Key:contact:email, Key:contact:website . The current situation harms> our database in a way that makes our data less useful. In order to be> successful we need to standardize to the contact: prefix.> No more multiple keys for the exact same purpose with just> different names! Make tagging more orthogonal! As someone who has > experience in database and normalisation it hurts to see that> mappers don't know how to take care of a database. It is time to take> action and to clean up so OSM data gets more useful.As an alternative, why not get rid of the contact:* versions since mostpeople are not using them?-- Shawn K. Quinn http://www.rantroulette.comhttp://www.skqrecordquest.com___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Shawn K. Quinn

On 5/4/20 05:53, Valor Naram via Tagging wrote:
> I request to replace all occurrence of the non-prefixed versions of
> the contact keys like Key:phone, Key:email. Key:website to be
> replaced with the prefixed ones like Key:contact:phone,
> Key:contact:email, Key:contact:website . The current situation harms
> our database in a way that makes our data less useful. In order to be
> successful we need to standardize to the contact: prefix.> No more multiple 
> keys for the exact same purpose with just
> different names! Make tagging more orthogonal! As someone who has 
> experience in database and normalisation it hurts to see that
> mappers don't know how to take care of a database. It is time to take
> action and to clean up so OSM data gets more useful.

As an alternative, why not get rid of the contact:* versions since most
people are not using them?

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

Am Mo., 4. Mai 2020 um 16:05 Uhr schrieb Sebastian Martin Dicke <
sebastianmartindi...@gmx.de>:

> The non prefixed tags should be replaced manually to avoid such
> problems. When a website is not a contact website then it should be
> prefixed with another suitable namespace. It would be more useful than
> just use always website.



if there was general agreement to add the prefix, there would be more
efficient means to do it. For example to my knowledge, both of the most
used editors, iD and JOSM, apply the shorter version of these tags in their
presets. Also many contributors add these shorter tags manually. The last
voting on the issue has demonstrated that there isn't a majority supporting
a transition to contact:-prefix. Your suggestion would only contribute to
more tag fragmentation.

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

On Mon, 4 May 2020 at 15:05, Sebastian Martin Dicke <
sebastianmartindi...@gmx.de> wrote:

> The non prefixed tags should be replaced manually to avoid such
> problems. When a website is not a contact website then it should be
> prefixed with another suitable namespace. It would be more useful than
> just use always website.
>

I'm trying to think of any website I have ever seen that ONLY provided
contact details.  I've seen web pages that are contact details only,
but those might better be tagged as URL.  Websites are the whole
enchilada, in my opinion.  A page of contact details is a page within
a website.

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

Am Mo., 4. Mai 2020 um 15:16 Uhr schrieb Richard Fairhurst <
rich...@systemed.net>:

> As someone with admin access over this mailing list, I request that you do
> not keep bringing back proposals which were extensively debated beforehand
> and generally rejected. It wastes everyone's time.
>


Thank you Richard! I much appreciate the way you exercise your admin
privileges here. Only in the extreme cases a call to reason.

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Sebastian Martin Dicke


The non prefixed tags should be replaced manually to avoid such
problems. When a website is not a contact website then it should be
prefixed with another suitable namespace. It would be more useful than
just use always website.


Regards


Sebastian


Am 04.05.20 um 13:48 schrieb Alexey Zakharenkov:


I agree that phone and contact:phone denote the same thing and should
be collapsed into one. But a website doesn't always contain contact
information like websites devoted natural/man-made features. IMO,
noone should convert 'website' tag for this memorial
https://www.openstreetmap.org/node/1416386078 into 'contact:website',
so global automatic tag replacement would be an error in this case.


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

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

2020-05-04 Thread 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

2020-05-04 Thread 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

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] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Richard Fairhurst

Soren Reinecke wrote:
> I request to replace all occurrence of the non-prefixed 
> versions of the contact keys like Key:phone, Key:email. 
> Key:website to be replaced with the prefixed ones like 
> Key:contact:phone, Key:contact:email, Key:contact:website

As someone with admin access over this mailing list, I request that you do
not keep bringing back proposals which were extensively debated beforehand
and generally rejected. It wastes everyone's time.

I don't particularly want to start banhammering people from the list but
will do so if necessary.

Thank you.

Richard

--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

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

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] Remove non-prefixed versions of 'contact:' scheme

On Mon, 4 May 2020 at 13:37, Sören alias Valor Naram 
wrote:

> I didn't heard any good reason why not to change to `contact:` scheme.
>

Because too many people disagree with you.

I'm not saying that they're right.  I'm not saying that you're wrong.  I'm
saying that they will vote against your proposal as they did before,
and it will fail (again).

It's not for them to convince you that they have a good reason not to
change it, it's for you to convince them that they are wrong.  You failed
the last time and I doubt you'll do any better this time.  Not unless
you have better arguments than you had last time, but if you do
I haven't seen them.

However irrational you think they are, however irrational they may
actually be, too many people disagree with you for this to happen.

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

Le 04.05.20 à 13:48, Alexey Zakharenkov a écrit :
> noone should convert 'website' tag for this memorial
> https://www.openstreetmap.org/node/1416386078 into 'contact:website'

indeed, it's not contact:website and but also not a website
it's just a picture and 2 lines of text as there are probably
a lot of them. it's not THE website of this object.
so the problem with this object is that it shouldn't have
a website tag at all :) image=* ?

vehicle=boat is also wrong. vehicle is an acces tag.
maybe memorial=sculpture or memorial=boat.

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Sören alias Valor Naram

I didn't heard any good reason why not to change to `contact:` scheme.~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Remove non-prefixed versions of 'contact:' schemeFrom: Marc Gemis To: "Tag discussion, strategy and related tools" CC: Are you planning on repeating this request every 5 months?I thought https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phonefailed.Wasn't the outcome about 50-50? How will you ever convince half of thevoters to accepts the other scheme?regardsmOn Mon, May 4, 2020 at 12:55 PM Valor Naram via Tagging wrote:>>>   I request to replace all occurrence of the non-prefixed versions of the contact keys like Key:phone, Key:email. Key:website to be replaced with the prefixed ones like Key:contact:phone, Key:contact:email, Key:contact:website . The current situation harms our database in a way that makes our data less useful. In order to be successful we need to standardize to the contact:>  prefix. No more multiple keys for the exact same purpose with just> different names! Make tagging more orthogonal! As someone who has> experience in database and normalisation it hurts to see that mappers> don't know how to take care of a database. It is time to take action and>  to clean up so OSM data gets more useful.>>> Having two keys for the same purpose (the current behaviour) has no advantages but many disadvantages:>  * Data customers need to be aware of both tags to cover all> requested and available information. So to get telephone numbers they> need to look for Key:phone and Key:contact:phone . This makes a bad> impression.>>  * Normalisation of that data is required. Key:phone must be> translated to Key:contact:phone or backwards. It is good to prevent the> need of normalisation through standardisation as far as possible to> prevent errors and misinterpretations from happening.>>  * Having two schemes leads to confusion of mappers (especially> for newbies) which they should use. Some need clear guidance ( e.g. On> request I created a translation table for mappers of the old diaper key> to help them to switch to the new Key:changing_table as you can see> here: https://wiki.openstreetmap.org/wiki/Key:changing_table#Comparison_with_the_deprecated_diaper.3D.2A_key . I also notified some of the mappers and stakeholders about that change)>> See also:> https://github.com/openstreetmap/iD/issues/7566> https://josm.openstreetmap.de/ticket/19184> OpenStreetMap contact schema unification>> --> ~ Sören Reinecke alias Valor Naram>>> Developer (not Founder) of the Babykarte: https://babykarte.github.io> Participating in "MapDiscover" project: https://mapdiscover.org> "Community Support" for Trufi Association:> https://trufi-association.org> Documentation for Trufi Communities on mapping bus routes:> https://github.com/trufi-association/mapping-documentation>>> Ein Gag zu Hamsterkäufen: https://klopapier.mapdiscover.de>>> ___> Tagging mailing list> Tagging@openstreetmap.org> https://lists.openstreetmap.org/listinfo/tagging___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

Hello,

Le 04.05.20 à 12:53, Valor Naram via Tagging a écrit :
> replace all occurrence of the non-prefixed versions of the contact keys

although I totally agree with the idea, I can't imagine a global mass
agreement to make it happen.
as in the previous version, you're going to have opinions against it:
- because too much use (saying that a problem that's too big doesn't
need to be solved is pretty absurd).
- because some will feel that A and contact:A are not the same thing

Regards,
Marc

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

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 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] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Marc Gemis

Are you planning on repeating this request every 5 months?

I thought 
https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone
failed.
Wasn't the outcome about 50-50? How will you ever convince half of the
voters to accepts the other scheme?


regards

m

On Mon, May 4, 2020 at 12:55 PM Valor Naram via Tagging
 wrote:
>
>
>   I request to replace all occurrence of the non-prefixed versions of the 
> contact keys like Key:phone, Key:email. Key:website to be replaced with the 
> prefixed ones like Key:contact:phone, Key:contact:email, Key:contact:website 
> . The current situation harms our database in a way that makes our data less 
> useful. In order to be successful we need to standardize to the contact:
>  prefix. No more multiple keys for the exact same purpose with just
> different names! Make tagging more orthogonal! As someone who has
> experience in database and normalisation it hurts to see that mappers
> don't know how to take care of a database. It is time to take action and
>  to clean up so OSM data gets more useful.
>
>
> Having two keys for the same purpose (the current behaviour) has no 
> advantages but many disadvantages:
>  * Data customers need to be aware of both tags to cover all
> requested and available information. So to get telephone numbers they
> need to look for Key:phone and Key:contact:phone . This makes a bad
> impression.
>
>  * Normalisation of that data is required. Key:phone must be
> translated to Key:contact:phone or backwards. It is good to prevent the
> need of normalisation through standardisation as far as possible to
> prevent errors and misinterpretations from happening.
>
>  * Having two schemes leads to confusion of mappers (especially
> for newbies) which they should use. Some need clear guidance ( e.g. On
> request I created a translation table for mappers of the old diaper key
> to help them to switch to the new Key:changing_table as you can see
> here: 
> https://wiki.openstreetmap.org/wiki/Key:changing_table#Comparison_with_the_deprecated_diaper.3D.2A_key
>  . I also notified some of the mappers and stakeholders about that change)
>
> See also:
> https://github.com/openstreetmap/iD/issues/7566
> https://josm.openstreetmap.de/ticket/19184
> OpenStreetMap contact schema unification
>
> --
> ~ Sören Reinecke alias Valor Naram
>
>
> Developer (not Founder) of the Babykarte: https://babykarte.github.io
> Participating in "MapDiscover" project: https://mapdiscover.org
> "Community Support" for Trufi Association:
> https://trufi-association.org
> Documentation for Trufi Communities on mapping bus routes:
> https://github.com/trufi-association/mapping-documentation
>
>
> Ein Gag zu Hamsterkäufen: https://klopapier.mapdiscover.de
>
>
> ___
> 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] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Alexey Zakharenkov

 04.05.2020, 13:54, "Valor Naram via Tagging" :  I request to replace all occurrence of the non-prefixed versions of the contact keys like Key:phone, Key:email. Key:website to be replaced with the prefixed ones like Key:contact:phone, Key:contact:email, Key:contact:website . The current situation harms our database in a way that makes our data less useful. In order to be successful we I agree that phone and contact:phone denote the same thing and should be collapsed into one. But a website doesn't always contain contact information like websites devoted natural/man-made features. IMO, noone should convert 'website' tag for this memorial https://www.openstreetmap.org/node/1416386078 into 'contact:website', so global automatic tag replacement would be an error in this case. Best regards,Alexey___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] leisure=common

2020-05-04 Thread Christoph Hormann

On Monday 04 May 2020, severin.menard via Tagging wrote:
>
> With this approach we would need to create a lot of new tags, eg for
> highways. Primary, secondary and tertiary are hierarchy based and
> does not mean the same reality everywhere, This is why
> https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa has been
> created. When you travel, roads, hospitals, schools, bakeries do not
> look the same but broadly intend to provide similar services.
> "publicly-accessible land worldwide" is the definition in the wiki
> for leisure=common and IMO it fits well for defining those kinds of
> pieces of lands you cannot miss on imagery and whose status/functions
> are not as precise as for parks, recreation grounds, etc.

Note there are real world features which are semantically very similar 
despite looking very different - imagine a soccer field in central 
Europe with green grass, one in subtropical Africa with bare ground, 
one in Greenland with artificial turf and one on a glacier in the 
Antarctic with compacted snow, all tagged leisure=pitch.  But there are 
also features which at a quick look have semantic similarities (public 
spaces in this case) but where this smallest common denominator is too 
broad for it to have much practical meaning and there are tons of 
features all over the world that fit that definition but for which 
there are many different existing and more precise tags.

We from our European/North American often without thinking try to apply 
our cultural perspective and classification to environments physically 
and culturally very different from our own.  We currently have almost 
zero tags with somewhat broader use in the OSM database that were 
invented outside of Europe and North America (counting Russia as Europe 
here - the Russian community is relatively active in establishing new 
tags).  That is not normal and indicates a serious inbalance.

I think - like often in tagging discussion - that too much focus is put 
on what tag to use and too little focus on what you actually want to 
map.  And i don't mean what object physically to map on the ground but 
what semantic aspect of it you want to map.  The problem here - and 
that already became clear with the initial post by Jean-Marc - is that 
there are a multitude of aspects that define these locations.  It would 
be appropriate to tag these aspects as such and not try to identify a 
specific combination of characteristics from a type locality and then 
try to apply this to other locations.  That is not very useful, in 
particular for cultural geography features - no matter if it is a new 
tag or it it locally re-purposes an existing tag.

So my suggestion how to proceed here:

* take a good look at the area you want to map things in.
* identify what specifically you want to map.
* formulate in an abstract form (i.e. not definition via examples) and 
avoiding weasel words like 'generally' 'typically' or 'usually' the 
common and verifiable aspects of what you want to map.  Such aspects 
can be physical (in case of areas of land:  state of the ground, what 
kind of objects are located on it etc.) or cultural (like what function 
the feature has for the locals, how it is used by humans etc.)
* look for existing tags that already indicate things you have 
formulated.  Invent new tags when needed.  Clarify documentation of 
existing tags when needed.

The third step - formulating your classification in abstract form 
*before* you assess if existing tags are suitable - is key here.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] RFC ele:regional

2020-05-04 Thread 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

[Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Valor Naram via Tagging

I request to replace all occurrence of the non-prefixed versions of the
contact keys like Key:phone, Key:email. Key:website to be replaced with the
prefixed ones like Key:contact:phone, Key:contact:email, Key:contact:website .
The current situation harms our database in a way that makes our data less
useful. In order to be successful we need to standardize to the contact:
prefix. No more multiple keys for the exact same purpose with just
different names! Make tagging more orthogonal! As someone who has
experience in database and normalisation it hurts to see that mappers
don't know how to take care of a database. It is time to take action and
to clean up so OSM data gets more useful.

Having two keys for the same purpose (the current behaviour) has no advantages
but many disadvantages:
* Data customers need to be aware of both tags to cover all
requested and available information. So to get telephone numbers they
need to look for Key:phone and Key:contact:phone . This makes a bad
impression.

* Normalisation of that data is required. Key:phone must be
translated to Key:contact:phone or backwards. It is good to prevent the
need of normalisation through standardisation as far as possible to
prevent errors and misinterpretations from happening.

* Having two schemes leads to confusion of mappers (especially
for newbies) which they should use. Some need clear guidance ( e.g. On
request I created a translation table for mappers of the old diaper key
to help them to switch to the new Key:changing_table as you can see
here:
https://wiki.openstreetmap.org/wiki/Key:changing_table#Comparison_with_the_deprecated_diaper.3D.2A_key
. I also notified some of the mappers and stakeholders about that change)

See also:
https://github.com/openstreetmap/iD/issues/7566
https://josm.openstreetmap.de/ticket/19184
OpenStreetMap contact schema unification

--
~ Sören Reinecke alias Valor Naram

Developer (not Founder) of the Babykarte: https://babykarte.github.io
Participating in "MapDiscover" project: https://mapdiscover.org
"Community Support" for Trufi Association:
https://trufi-association.org
Documentation for Trufi Communities on mapping bus routes:
https://github.com/trufi-association/mapping-documentation

Ein Gag zu Hamsterkäufen: https://klopapier.mapdiscover.de

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

Re: [Tagging] 'amenity:hospital' at university hospitals?

Am Mo., 4. Mai 2020 um 11:50 Uhr schrieb Lena Essig :

> Hello,
> during mapping hospitals I found some university hospitals which are
> inside a university terrain. They are tagged with "buidling:hospital" -
> without an amenity tag, and some which are tagged with "building:hospital"
> AND "amenity:hospital".
> In most cases the university terrain is used as the terrain outline of the
> hospital.
> Ususally hospitals should be tagged like this:
> - hospital building: "building:hospital"
> - hospital terrain outline: "amenity:hospital"
> Of course there can also be address informatione etc. ([1]
> )
>
> One example can be found in Heidelberg, Germany:
> https://www.openstreetmap.org/way/26946230#map=15/49.4194/8.6670
> There is only the university terrain (with amenity=university), and the
> hospital building is tagged as "building:hospital".
>
> They did it differently in Tübingen, Germany.
> All university campuses, which are spread over several locations, are in a
> relation
> https://www.openstreetmap.org/relation/8639592#map=15/48.5305/9.0585, and
> some pieces of them are tagged with "amenity:hospital":
> https://www.openstreetmap.org/way/89132589.
>
> Now what is the right way? 'amenity: university' on university campuses,
> and around the hospitals another campus with 'amenity: hospital'? Or both
> tags, 'amenity: hospital' and 'building: hospital', to the hospital
> building?
>


assuming you meant "=" rather than ":", there is generally a problem with
universities. You cannot assume "amenity=university" to mean 1 piece of
university (and for example expect that a city with 3 universities will
have 3 objects with the tag "amenity=university". In real osm tagging,
amenity=university means either a university or a part of an university,
and for amenity=hospital it is mostly the same.

The key "building" always refers _only_ to a building, and its
architectural type (if the value is different than yes or no). So
building=hospital means a building errected as hospital,
building=university means a university building. It hasn't implications on
the current use. The function "a working university" or "a working
hospital" are tagged with amenity tags (and should comprise the grounds).
Generally, "building=hospital" is never sufficient to represent a hospital,
you will always need amenity=hospital (or maybe some similar amenity or
healthcare tag like clinic), and the same holds true for universities (and
any other function).

I am fairly aware of the situation in Tübingen, and it is indeed
complicated. There are 2 main sites for the hospital (which is also part of
the university), the "Altklinikum" and the newer "Kliniken Berg", and there
are also more sites that are situated in yet different locations. Both
sites contain different hospitals (which have their own directors, but then
there is also a general director for everything). There are also facilities
which do not belong to a specific hospital, e.g. for washing, cooking,
power plants and heating, etc., and there are research facilities which
belong to the university and maybe (not sure about this) to a hospital, but
where no healthcare is provided.

Truth is we do not have good semantic tagging yet to represent and
distinguish these different levels and hierarchies.

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

Re: [Tagging] leisure=common

sent from a phone

> On 4. May 2020, at 10:27, severin.menard via Tagging 
>  wrote:
>
> With this approach we would need to create a lot of new tags, eg for 
> highways. Primary, secondary and tertiary are hierarchy based and does not 
> mean the same reality everywhere

they do mean the same: a primary is more important than a secondary
which is more important than a tertiary. This is how they are defined.
There are no global expectations for surface quality, road widths,
junction construction or similar physical properties.

Take a bakery: the tag is worldwide the same, but the kind of bread is
different according to the local culture.

Even natural features may differ a lot, e.g. natural=peak. It could be
snow covered the whole year, have steep sides leading to it, or be a
relatively warm place throughout the year, have flat sides etc. It
does not mean we would have to use different tags for these.

If the definitions have been drafted with the whole world in mind,
reduced to the minimum needed to characterize the core of the meaning
of the tag (and possibly refraining from "examples", which are only
limiting the idea into a certain direction and context), we won’t need
a new tag for every local occurrence of a thing.
On the other hand, we should never "re-use" a tag that is used for
something else (according to which property/ies the tag should
describe), just because we do not have the thing that the tag
originally describes, in our context (i.e. just because it is "free").

Cheers
Martin

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

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


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

[Tagging] 'amenity:hospital' at university hospitals?

2020-05-04 Thread Lena Essig

Hello,
during mapping hospitals I found some university hospitals which are inside
a university terrain. They are tagged with "buidling:hospital" - without an
amenity tag, and some which are tagged with "building:hospital" AND
"amenity:hospital".
In most cases the university terrain is used as the terrain outline of the
hospital.
Ususally hospitals should be tagged like this:
- hospital building: "building:hospital"
- hospital terrain outline: "amenity:hospital"
Of course there can also be address informatione etc. ([1]
)

One example can be found in Heidelberg, Germany:
https://www.openstreetmap.org/way/26946230#map=15/49.4194/8.6670
There is only the university terrain (with amenity=university), and the
hospital building is tagged as "building:hospital".

They did it differently in Tübingen, Germany.
All university campuses, which are spread over several locations, are in a
relation
https://www.openstreetmap.org/relation/8639592#map=15/48.5305/9.0585, and
some pieces of them are tagged with "amenity:hospital":
https://www.openstreetmap.org/way/89132589.

Now what is the right way? 'amenity: university' on university campuses,
and around the hospitals another campus with 'amenity: hospital'? Or both
tags, 'amenity: hospital' and 'building: hospital', to the hospital
building?

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

Re: [Tagging] RFC ele:regional

2020-05-04 Thread 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

[Tagging] leisure=common

2020-05-04 Thread severin.menard via Tagging

English below

Résumé pour les francophones de la discussion en anglais : Joseph estime que 
leisure=common est ambigu car utilisé pour décrire des situations différentes 
dans le monde et Marc renchérit en estimant que l'approche "tel tag a une 
signification 1 dans tel pays, une signification 2 dans tel autre, etc. est une 
mauvaise idée".

Pour ma part, j'estime que s'il n'était plus possible d’utiliser des attributs 
qui revêtent des réalités différentes selon les contextes, il nous faudrait en 
créer beaucoup de nouveaux. Exemple de la clé highway où les attributs primary, 
secondary et tertiary désignent une hiérarchie et ne correspondant pas partout 
à la même réalité, et c'est bien pour cela que 
https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa a été créée. Lorsqu'on 
voyage, les routes, les hôpitaux, les écoles, les boulangeries ne se 
ressemblent pas, mais visent globalement à fournir des services similaires. 
"publicly-accessible land worldwide" ("terres accessibles au public dans le 
monde entier") est la définition donnée dans le wiki pour leisure=common et à 
mon avis elle convient bien pour définir les types de terres qu on observe bien 
sur imagerie et dont le statut/les fonctions ne sont pas aussi précis que pour 
les parcs, les terrains de loisirs, etc.

Séverin


> Le 03.05.20 à 18:13, Joseph Eisenberg a écrit :
>
> > it is true that this tag (leisure=common)is ambiguous because it is
> > being used for totally different purposes in different countries.
>
> I think this argument is crucial.
> if more than one meaning exists for a tag, having a precise meaning for
> a country is useless, osm is a global base, it's a bad idea to hope a
> render style "tag A rendered as meaning1 in Africa, as meaning2 in
> Europe, as meaning3 in Asia".
> for quality, it is important to abandon multi-meaning tags and use
> new tags instead, one for each existing sense.
>
> as the subject said "leisure=common <...> need a replacement"
>
> several replacements.
>
> Regards,
> Marc


With this approach we would need to create a lot of new tags, eg for highways. 
Primary, secondary and tertiary are hierarchy based and does not mean the same 
reality everywhere, This is why 
https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa has been created. When 
you travel, roads, hospitals, schools, bakeries do not look the same but 
broadly intend to provide similar services. "publicly-accessible land 
worldwide" is the definition in the wiki for leisure=common and IMO it fits 
well for defining those kinds of pieces of lands you cannot miss on imagery and 
whose status/functions are not as precise as for parks, recreation grounds, etc.

Séverin

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

Re: [Tagging] RFC ele:regional

2020-05-04 Thread 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

2020-05-04 Thread 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] With leisure=common deprecated, Senegal & Mali need a replacement