Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging) - Cancelled

[Sören Reinecke via Tagging]

Due to your feedback I will cancel the proposal. AGAIN: What you say is
100% correct. This proposal's purpose was just to simplify what seems
unclear to many (not all) mappers.

But keep you eyes on the following unsolved scenario:
---
How should the following scenario be tagged:
Playground https://www.openstreetmap.org/way/320398422 just has one
equipment (sandpit) and this equipment (sandpit) fills up the whole
area of the playground. The tagging used here is as follow:
(access=yes)  reluctant for our purpose
leisure=playground
playground=sandpit

Helpful resources:
https://wiki.osm.org/Key:playground:
https://wiki.osm.org/Key:playground
---

Summary about what you said about this case:
> Re: > This would allow to map playgrounds and their equipment in
situations where a playground just has one equipment and this
equipment fills up the whole area of the playground.

> Mappers can tag "leisure=playground" + "playground=structure"  on the
same node or area in this case, right?


My answer: > The Wikipage for "Key:playground" says the following: "It
should be
tagged to separate objects within the area of a playground". An
exception is given with "Only when the position of the individual
objects cannot be mapped yet" at the really end of the page. But for
such cases where we cannot map playground equipment as an extra object
we have the Key:playground:* .

> Well the equipment in this case is playground=sandpit.
As the outline of the sandpit is identical with the outline of the
leisure=playground, why would
this be wrong?


My answer: Theoretically you need to create an object for the
playground itself
and another object for the playground equipment. Both then will share
the same geometries (outline). In practical meaning you normally won't
map it this way because it is idiotic. My proposal also reflects that
and provides a way to map such cases without having to do it the
theoretical way.


We should clarify how to handle such cases in the wiki

Cheers

Sören Reinecke alias Valor Naram
-Original Message-
From: Sören Reinecke via Tagging 
Reply-To: "Tag discussion, strategy and related tools" <
tagging@openstreetmap.org>
To: tagging@openstreetmap.org
Cc: Sören Reinecke 
Subject: [Tagging] Feature Proposal - RFC - (Unifying playground
equipment tagging)
Date: Mon, 30 Mar 2020 16:43:59 +0200

Hey,
a new RFC for 
https://wiki.openstreetmap.org/wiki/Proposed_features/Unifying-playground-equipment-tagging

Purpose:Simplified tagging of playground equipment on the playground
itself oras separate object. Both schemes already exist and I want to
combinethem to help to decrease tagging errors.
Proposal:I propose the key playground to be deprecated and the use of
keyplayground:* instead. That would mean that on both playground
andplayground equipment objects in OSM the key playground:* applies.
Thisthen would also allow to map playgrounds and their equipment
insituations where a playground just has one equipment and this
equipmentfills up the whole area of the playground.



What I feel:I know many of you do not want developers to speak about
how you shoulddo things. But I think a dialogue is necessary and also
good for us alland we can learn from each other: Mappers know the
philosophy of OSM,the mapping, tagging and the QA, they know what to
achieve how.Developers know the philosophy of orthogonality and
nornmalisation ofthings and can help mappers to make OSM more useful.
I am the developer of Babykarte. Babykarte follows what I want
topropose for a quite long time already with some extra
specificationswhich enables it to be quite flexible in interpreting the
tagging. Thismakes Babykarte a really good interpreter of the tagging
of playgroundequipment. This is necessary to do for us developers (we
would be happyif all mappers would stick to the specs) because some
mappers decidednot to read the wiki carefully or not at all but instead
to actuallymap without knowing how. So developers always need to do
someinterpreting and thinking of all the possibilities people do not
map inaccordance with the spec. This makes us to create our own spec
thatbuilds on the official one because people aren't following
thecommunity's specs.





signature.asc
Description: This is a digitally signed message part
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)

[Sören Reinecke via Tagging]

> You are proposing to abandon the distinction between playgrounds and
implicit features on them (properties) and things on a playground
(explicitly mapped playground equipment as a feature).

Not really, playground equipment (tagged with 'playground:') on a
feature tagged with its main tag 'leisure=playground' indicates that
the feature is a playground. The key 'playground:' on that feature
describes just its properties. The distinction is being done by
'leisure=playground'.

> Wouldn't this move make it actually harder, rather than simpler, to
understand what is represented?

No because the keys 'playground' and 'playground:' are not describing
the feature itself but are describing what the feature has:

leisure=playground
playground:*= yes

as I suggest describes a playground with its properties (playground
equipment) on it. Playground equipment tagged as feature (separate
object) would then be tagged like this:

playground:*=yes
...
(not containing 'leisure=playground')

> Usually we are advocating for the contrary: using different keys for
features provided by other features (properties) and features mapped
explicitly. In this case, it is already like this, and you do not
provide (IMHO) sufficient arguments to change it.

I know and I love this way of handling. I can just give one example of
how people are using the 'playground' key wrongly on a feature tagged
as 'leisure=playground':

http://www.openstreetmap.org/node/6323927215
  leisure=playground
  playground=structure

correct would be

http://www.openstreetmap.org/node/6323927215
  leisure=playground
  playground:structure=yes

That's why I think the actual way is to confusing. I am personally
total fine with the situation as it is now because it makes *sense*.

> Redefining tags that are in use (properties for playgrounds then could
also represent explicit features) is generally problematic, why aren't
you proposing different tags as an attempt to avoid confusion?

Because the key 'playground' mapped on a playground equipment (explicit
feature) is also being used on playground features with
'leisure=playground'. This is wrong and leads also to confusion. That's
why I want to propose the other way around to hopefully solve the
problem of using semicolons on the 'playground' key to indicate
multiple equipment as it is here 
http://www.openstreetmap.org/way/166629582 . Normally I would run a
world wide Overpass Query for such cases and would convert it to the
'playground:*' scheme as a QA attempt.

> I do not understand why this would make mapping easier or less error
prone. You will find tags that are not used as documented for any
feature.

See my examples.

-- 
Sören Reinecke alias Valor Naram 



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

Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)

[Sören Reinecke via Tagging]

> Well the equipment in this case is playground=sandpit.
As the outline of the sandpit is identical with the outline of the
leisure=playground, why would
this be wrong?

Theoretically you need to create an object for the playground itself
and another object for the playground equipment. Both then will share
the same geometries (outline). In practical meaning you normally won't
map it this way because it is idiotic. My proposal also reflects that
and provides a way to map such cases without having to do it the
theoretical way.


-- 
Sören Reinecke alias Valor Naram 



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

Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)

[Sören Reinecke via Tagging]

> The current system seems to make sense.

It makes sense but it seems that it is also much error-prone because it
is easy to oversee one sentence in the wiki of Key:playground:* and
Key:playground that makes the difference (pointing the case where the
key should be applied)


> If you have a leisure=playground feature, probably mapped as an area,
you can tag it with a list of tags like "playground:slide=yes",
"playground:swing=yes", to show what equipment is available.

> If you want to map a slide or a swing as a separate feature, you tag
it "playground=slide", or "playground=swing"

> What is the problem with this?

No problem with it. This is alright. But Key:playground shouldn't
combined with Tag:leisure=playground .

> Re: > " I want to combine them to help to decrease tagging errors."

> How will that help? What errors are you commonly finding?

For example: https://www.openstreetmap.org/way/137931618 . In this case
Key:playground was used to tag playground equipment on the playground
object itself. But for such cases we use Key:playground:* . This is one
example of many.


> Re: > This would allow to map playgrounds and their equipment in
situations where a playground just has one equipment and this
equipment fills up the whole area of the playground.

> Mappers can tag "leisure=playground" + "playground=structure"  on the
same node or area in this case, right?

The Wikipage for "Key:playground" says the following: "It should be
tagged to separate objects within the area of a playground". An
exception is given with "Only when the position of the individual
objects cannot be mapped yet" at the really end of the page. But for
such cases where we cannot map playground equipment as an extra object
we have the Key:playground:* .

Cheers

Sören Reinecke alias Valor Naram


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

[Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)

[Sören Reinecke via Tagging]

Hey,

a new RFC for 
https://wiki.openstreetmap.org/wiki/Proposed_features/Unifying-playground-equipment-tagging

Purpose:
Simplified tagging of playground equipment on the playground itself or
as separate object. Both schemes already exist and I want to combine
them to help to decrease tagging errors.

Proposal:
I propose the key playground to be deprecated and the use of key
playground:* instead. That would mean that on both playground and
playground equipment objects in OSM the key playground:* applies. This
then would also allow to map playgrounds and their equipment in
situations where a playground just has one equipment and this equipment
fills up the whole area of the playground.




What I feel:
I know many of you do not want developers to speak about how you should
do things. But I think a dialogue is necessary and also good for us all
and we can learn from each other: Mappers know the philosophy of OSM,
the mapping, tagging and the QA, they know what to achieve how.
Developers know the philosophy of orthogonality and nornmalisation of
things and can help mappers to make OSM more useful.

I am the developer of Babykarte. Babykarte follows what I want to
propose for a quite long time already with some extra specifications
which enables it to be quite flexible in interpreting the tagging. This
makes Babykarte a really good interpreter of the tagging of playground
equipment. This is necessary to do for us developers (we would be happy
if all mappers would stick to the specs) because some mappers decided
not to read the wiki carefully or not at all but instead to actually
map without knowing how. So developers always need to do some
interpreting and thinking of all the possibilities people do not map in
accordance with the spec. This makes us to create our own spec that
builds on the official one because people aren't following the
community's specs.


-- 
~ 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] Feature Proposal - RFC - (changing_table:location)

[Sören Reinecke via Tagging]

I step back from my proposal 
https://wiki.openstreetmap.org/wiki/Proposed_features/Subkey:changing_table:location
which is totally fine because of less work. The webapp "Babykarte" by
the way supports semicolons as seperators so I do not have problems of
having semicolons in values.

Cheers

Sören Reinecke alias Valor Naram

-Original Message-----
From: Sören Reinecke via Tagging 
Reply-To: "Tag discussion, strategy and related tools" <
tagging@openstreetmap.org>
To: Tagging@openstreetmap.org
Cc: Sören Reinecke 
Subject: [Tagging] Feature Proposal - RFC - (changing_table:location)
Date: Thu, 05 Dec 2019 14:39:27 +0100

Hey all,

A new but small proposal to change the specification for subkey
`changing_table:location` because of a discussion yesterday about using
seperators in values. I totally agree that we should avoid using
seperators when possible.
Proposal: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Subkey:changing_table:location
Definition: Tagging of the location of the nappy changing facility in a
POI


Reason:
Someone pointed to the wikipage Semi-colon value separator as part of a
discussion of using semicolons as seperator of key values. In my
previous successful proposal the subkey
`changing_table:location'  allows to seperate the values by a
semicolon. While the support of a semicolon as seperator for this
subkey falls under the three exceptions ( 
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator ), I
want to give here the chance to change that because the subkey
changing_table:location is still not in widespread use.

Cheers

Sören Reinecke alias Valor Naram

___Tagging mailing 
listtagg...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Tagging] Feature Proposal - RFC - (changing_table:location)

[Sören Reinecke via Tagging]

Hey all,

A new but small proposal to change the specification for subkey
`changing_table:location` because of a discussion yesterday about using
seperators in values. I totally agree that we should avoid using
seperators when possible.
Proposal: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Subkey:changing_table:location
Definition: Tagging of the location of the nappy changing facility in a
POI

Reason:
Someone pointed to the wikipage Semi-colon value separator as part of a
discussion of using semicolons as seperator of key values. In my 
previous successful proposal the subkey `changing_table:location' 
allows to seperate the values by a semicolon. While the support of a
semicolon as seperator for this subkey falls under the three exceptions
( https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator ), I
want to give here the chance to change that because the subkey 
changing_table:location is still not in widespread use.

Cheers

S??ren Reinecke alias Valor Naram
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - park_drive

[Sören Reinecke via Tagging]

> Forgive me, but this is my first time on that list.There's not much to know. Now the discussion part begins, be attentative. Usually the discussion ends after the two week period and then voting takes place.I do not quite understand the definition of your proposal. Allows the tag the mapping of carpool meeting points?CheersSören Reinecke alias Valor Naram Original Message Subject: [Tagging] Feature Proposal - RFC - park_driveFrom: Martin Scholtes To: tagging@openstreetmap.orgCC: Hello,I would like to inform you that I have made a suggestion about park anddrive. This resulted from a discussion in the OSM DE Telegram Chat.https://wiki.openstreetmap.org/wiki/Proposed_features/park_driveDefinition: Information that can be taken on this parking lot to form acarpool.I would be pleased about suggestions.Forgive me, but this is my first time on that list.GreetingsMartin___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (contact:phone)

[Sören Reinecke via Tagging]

Hello all,I step back from my proposal https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone_2 .CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (contact:phone)From: Sören Reinecke via Tagging To: "Tag discussion, strategy and related tools" CC: Sören Reinecke > (For deprecating a key  that is used 1 504 275 times with another one with the same meaning you need very very good reasons)As a reminder how you voted on https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone#Voting :I oppose this proposal. -- I am against deprecating a widely used tagging --voschix (talk) 17:27, 24 October 2019Note that I tried to deprecate "contact:phone" which is by the way used less but you and many others voted against my first proposal to deprecate "contact:phone".Now I try it the other way around: Deprecating "phone" tag.CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (contact:phone)From: Volker Schmidt To: "Tag discussion, strategy and related tools" CC: On Wed, 4 Dec 2019 at 13:42, Sören Reinecke via Tagging <tagging@openstreetmap.org> wrote:This proposal is different. It's about deprecating the `phone` key.-1 (For deprecating a key  that is used 
1 504 275 times with another one with the same meaning you need very very good reasons)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (contact:phone)

[Sören Reinecke via Tagging]

> And make sure osm wikidata handle namespace schemas?Implementing such handling can be done by the developers of mapping tools (JOSM, iD). I also thought about this: Editors converting wrong tags to the right tags e.g. `phone` to `contact:phone`. I'm also happy with shorthands as long as they are handled property; converting them. But this is one of the ideas behind presets. We can do a step further and can do that also for manual typing  of keys into a text field with the option to toggle this feature.CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (contact:phone)From: Topographe Fou To: "Tag discussion, strategy and related tools" CC:   I totally agree. Soren and all others members don't disserve such comment. OSM is a project where everyone can submit its point of view and ask for voting. Even if some think they own the truth.Having said that I think the main topic has not been adressed. For me contact is a namespace. I would prefer a proposition to say "phone key is a shortcut of contact:phone. (Same for email and others)". As such, they shall be handled the same." . And make sure osm wikidata handle namespace schemas ? LeTopographeFou   De: luke.mar...@viacesi.frEnvoyé: 4 décembre 2019 5:52 PMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: Re: [Tagging] Feature Proposal - RFC - (contact:phone)  
Hi there,


Disclaimer: 

-I don't have much experience with OSM.
-I find the proposition of unifying the usage quite logical. 

-Now that I've read some responses, I understand why the community could be against.


However:

I'm amazed at how harsh people are against Sören. He's been putting some time to help, and the reversal of the proposal made sense when considering the voters' explanations on the wiki page.



Reading a thread like this honestly won't encourage any participation from outsiders (myself included)
And I'm not speaking about the x-th response, the firsts were already aggressive.

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

Re: [Tagging] Feature Proposal - RFC - (contact:phone)

[Sören Reinecke via Tagging]

Welcome Martin,a mailing list like this is probably not the right place to get into the community. Instead head over to a group on Reddit, Telegram, Twitter, Facebook, Discord, IRC, Matrix etc.For Telegram see here: https://wiki.openstreetmap.org/wiki/List_of_OSM_centric_Telegram_accountsIf you tell me the country and the communication platform you prefer I can help you. Alternatively head over to https://wiki.osm.org and type in the country you're living in in the search bar. You probably find a list of local communities in your country there.My e-mail address: tilmanreine...@yahoo.deMy Telegram account: @valornaramMy OSM account: https://www.openstreetmap.org/user/Valor%20NaramCheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (contact:phone)From: MARLIN LUKE To: Sören Reinecke via Tagging CC: 



Hi there,




Disclaimer: 


-I don't have much experience with OSM.

-I find the proposition of unifying the usage quite logical. 


-Now that I've read some responses, I understand why the community could be against.




However:


I'm amazed at how harsh people are against Sören. He's been putting some time to help, and the reversal of the proposal made sense when considering the voters' explanations on the wiki page.





Reading a thread like this honestly won't encourage any participation from outsiders (myself included)

And I'm not speaking about the x-th response, the firsts were already aggressive.




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

Re: [Tagging] Feature Proposal - RFC - (contact:phone)

[Sören Reinecke via Tagging]

> What part of 'No' don't you understand?Everything. Again: I proposed the deprecation of "contact:phone" in first place which has failed because the major tagging community decided so.Everything went logical according to my statement. In this row I try to propose the deprecation of "phone" and now you're saying to me that OSM does not do deprecations of well-used tags? While this statement is completely understandable I do not understand why the community was against deprecating "contact:phone", can you tell me that?My statement: Two tags for the same purpose are not elegant and makes the use of OSM data harder.CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (contact:phone)From: Chris Hill To: tagging@openstreetmap.orgCC: On 04/12/2019 13:41, Sören Reinecke via Tagging wrote:> This proposal is different. It's about deprecating the `phone` key.>>OSM doesn't do deprecation of a well-used tag. It doesn't do homogenisation for the sake of it. It doesn't do a new dressed-up vote to get around a failed vote. You put it forward as a plan and it got rejected. To simply reverse the polarity of the vote and call it a new vote is a joke. Just let this go, please.What part of 'No' don't you understand?  --cheersChris Hill (chillly)___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (contact:phone)

[Sören Reinecke via Tagging]

> Others have also made sensible arguments against this.What kind of points? Am I something missing?Overview:- My first proposal: Deprecating "contact:phone"  - rejected by community- Reason: "contact" prefix is more orthogonal- My second proposal: Deprecating "phone"  - ongoing discussion- We can live with two keys which have the same purpose  - My response: Developers and data users need to write so called "schemes". The logic behind it: One scheme, one purpose. Two tags for the exactly same purpose destroys that idea and makes the use of OSM data harder. If we want to support two tags which are for the same purpose then we need to add every exception we can imagine. So we risk to reduce the quality of our development, bugs occur and it's simply not abstract working which is the idea behind programming and which makes programs more universal useable.  - "phone" is x-times more used than "contact:phone"- My answer: That's why I wanted to deprecate the less used "contact:phone" in first row and it failed due to to many oppose votes. Don't blame me with arguments why we should do not deprecate "phone". You had your chance to vote for the deprecation of "contact:phone" in favor of the more used "phone" key which I would have then promoted if my first proposal had succeeded.CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (contact:phone)From: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Wed, 4 Dec 2019 at 14:42, Martin Koppenhoefer  wrote:if it fails, will you try to deprecate both tags?If it wins, what do you expect would it mean in practical terms?Sensible points.  Others have also made sensible arguments against this.  There is nosign, from his responses, that any of this is getting through to him.  I suggest we stopresponding here, leave him to it, and then just vote against his proposal.  Either way, mostpeople ARE going to vote against it, but if we stop responding here that will keep the noisedown.-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (contact:phone)

[Sören Reinecke via Tagging]

> if it fails, will you try to deprecate both tags?This would be illogical. I think you did not get my point: I and others do not want multiple tags for one purpose. My goal therefore is to deprecate ONE of them. I do not care, if its "contact:phone" or "phone" we deprecate in the end.> If it wins, what do you expect would it mean in practical terms?In practical terms we make using OSM data one little step easier because they do not need to watch out for possible two or more keys and to risk to forget one.CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (contact:phone)From: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: Sören Reinecke Am Mi., 4. Dez. 2019 um 15:07 Uhr schrieb Sören Reinecke via Tagging <tagging@openstreetmap.org>:Now I try it the other way around: Deprecating "phone" tag.if it fails, will you try to deprecate both tags?If it wins, what do you expect would it mean in practical terms?CheersMartin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (contact:phone)

[Sören Reinecke via Tagging]

> (For deprecating a key  that is used 1 504 275 times with another one with the same meaning you need very very good reasons)As a reminder how you voted on https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone#Voting :I oppose this proposal. -- I am against deprecating a widely used tagging --voschix (talk) 17:27, 24 October 2019Note that I tried to deprecate "contact:phone" which is by the way used less but you and many others voted against my first proposal to deprecate "contact:phone".Now I try it the other way around: Deprecating "phone" tag.CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (contact:phone)From: Volker Schmidt To: "Tag discussion, strategy and related tools" CC: On Wed, 4 Dec 2019 at 13:42, Sören Reinecke via Tagging <tagging@openstreetmap.org> wrote:This proposal is different. It's about deprecating the `phone` key.-1 (For deprecating a key  that is used 
1 504 275 times with another one with the same meaning you need very very good reasons)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (contact:phone)

[Sören Reinecke via Tagging]

Some asked me to restore the old version, the new version which I want
to vote on can be found here: 
https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone_2
 id="-x-evo-selection-start-marker">

-Original Message-
From: S??ren Reinecke via Tagging 
Reply-To: "Tag discussion, strategy and related tools" <
tagging@openstreetmap.org>
To: Tagging@openstreetmap.org
Cc: S??ren Reinecke 
Subject: [Tagging] Feature Proposal - RFC - (contact:phone)
Date: Wed, 04 Dec 2019 10:02:42 +0100

Hello again,

now the other way around: 
https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone
. I did some changes on the content level following Martin
Koppenhoefer's suggestions ( 
https://lists.openstreetmap.org/pipermail/tagging/2019-October/048818.html
).

This proposal tends to make Key:contact:phone the official tag for
tagging phone numbers and to deprecate Key:phone which is not fitting
in the idea of grouping keys. Anyway it's bad to have two keys for the
exact same purpose in use.


Cheers

S??ren Reinecke alias Valor Naram

___Tagging mailing 
listtagg...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Feature Proposal - RFC - (contact:phone)

[Sören Reinecke via Tagging]

This proposal is different. It's about deprecating the `phone` key.

-Original Message-
From: Paul Allen 
Reply-To: "Tag discussion, strategy and related tools" <
tagging@openstreetmap.org>
To: "Tag discussion, strategy and related tools" <
tagging@openstreetmap.org>
Subject: Re: [Tagging] Feature Proposal - RFC - (contact:phone)
Date: Wed, 4 Dec 2019 13:25:14 +

On Wed, 4 Dec 2019 at 13:19, Andy Townsend  wrote:

>   
> 
>   
>   It'd also be good to see an explanation of why it's worth the
>   time even going through this again - haven't we all got better
>   things to do?
> 

+1

-- 
Paul



___Tagging mailing 
listtagg...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Feature Proposal - RFC - (contact:phone)

[Sören Reinecke via Tagging]

Did this, see 
https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone/content
and 
https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone
.

But anyway I'm not quite happy about the section 
https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone/content#Tagging_different_numbers_for_different_countries
. It's too long and maybe also too complicated and has two main
paragraphs which I want to boil down to what they mean. Any ideas?

Cheers

S??ren Reinecke alias Valor Naram
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (contact:phone)

[Sören Reinecke via Tagging]

Hi Martin and others,The new proposal overwrites the old one. There's just the new content except the section "Vote 1". What I can do is putting everything in the "content" section into a new page. It is what you - Martin - suggested, outsourcing the "content" section?CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (contact:phone)From: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: Sören Reinecke Sören, may I suggest you set up a new page for the new proposal? It is already a very long page, and readability would certainly benefit from a more streamlined proposal page.CheersMartin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (contact:phone)

[Sören Reinecke via Tagging]

Hello again,

now the other way around: 
https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone
. I did some changes on the content level following Martin
Koppenhoefer's suggestions ( 
https://lists.openstreetmap.org/pipermail/tagging/2019-October/048818.html
).

This proposal tends to make Key:contact:phone the official tag for
tagging phone numbers and to deprecate Key:phone which is not fitting
in the idea of grouping keys. Anyway it's bad to have two keys for the
exact same purpose in use.


Cheers

S??ren Reinecke alias Valor Naram
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging