Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

Le 03.05.20 à 20:54, Jean-Marc Liotier a écrit : > is it also used in other parts of the world ? the thread already all missuses all around the world. 2 in France : legal status https://www.openstreetmap.org/way/435015884 small area of grass between highway https://www.openstreetmap.org/way/232310

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 > https://wiki.openstreetmap.org/

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 of

[Tagging] leisure=common

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 d

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 the

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

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

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

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 "amenit

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

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 o

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 Germ

Re: [Tagging] leisure=common

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/Highwa

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

 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 situati

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

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

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 additi

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 agai

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

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

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

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 pr

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 mou

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

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

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 m

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

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 would

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 t

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

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

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 Zakharenko

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

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

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 usefu

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

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 situ

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

> 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: [

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

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

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 sa

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

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

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

> 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

Re: [Tagging] Doorzone bicycle lanes

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

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

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

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 s

Re: [Tagging] Doorzone bicycle lanes

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

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

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] 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 wit

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 in

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

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

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 T

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] 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 t

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 proposi

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

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

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

Re: [Tagging] Doorzone bicycle lanes

On Tue, 5 May 2020 at 02:35, Jan Michel wrote: > 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_

Re: [Tagging] Doorzone bicycle lanes

sent from a phone > On 5. May 2020, at 04:58, Andrew Harvey wrote: > > The third scenario for dooring is just a regular road with no bicycle > infrastructure, but parked cars can still lead to dooring eg > https://www.mapillary.com/map/im/6YlYnuZPdlziwUsF1m7yWA in this case arguably it’s u