Re: [Tagging] Should admin_level=1 tag be applied to EU?

[Sören alias Valor Naram]

> Quitting the EU if you don't like it is much easier thanseceding from a country.I don't follow this reasoning since some people will always leave their country behind and begin a new life somewhere else. That was just how the US was founded, founded by ones from Europe mostly who broke up with their formally country in the hope of a better life.And quitting the EU is not easy because in a democracy it is not easy to gain the single vote of a majority e.g. to leave the EU. And also the complexity of the contracts with the EU don't make this easy. See United Kingdom and they don't have the problem of having to switch currency since they use their own one already.I would rather say that the EU is a suber administrative boundary which belongs to OSM as a relation with admin_level=1 with all the EU countries as its members.~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Should admin_level=1 tag be applied to EU?From: Frederik Ramm To: tagging@openstreetmap.orgCC: Hi,On 30.07.20 13:32, Colin Smale wrote:> The EU is «composed-of» whole member states. It has all the attributes> of a governmental administrative body - with the executive, parliament> and justicial branches impacting citizens directly.To me as a citizen of a EU country it does not feel like the EU is ahigher-level administrative body than the country. Yes, countries havedecided to contractually transfer some rights and responsibilities tothe EU but that doesn't (in my mind) mean the EU is some form ofsuper-state. Quitting the EU if you don't like it is much easier thanseceding from a country.I would prefer to map the EU as a contract than as an administrativeboundary. There are many such contracts around the world, where smallercountries pool their defense or other typically national capabilities,and I would not be surprised if there were situations where countriespool their defense with one group, and their currency with another.Mapping these things as "areas on the map" is old-style cartographicthinking. We can do better than that.Even *if* a boundary was mapped, it would probably more pragmatic to mapthe outer boundary of the Schengen region than the outer boundary of theEU states.ByeFrederik-- Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"___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

[Valor Naram via Tagging]

Hi,

I was busy and couldn't participate in this very interesting
discussion.

My proposal:
- Moving all social media keys like `facebook`, `twitter`, `whatsapp`,
`telegram` etc. to a `socialmedia` namespace like
`socialmedia:facebook`, `socialmedia:twitter`, `socialmedia:whatsapp`,
`socialmedia:telegram` etc.
-  Enriching the definition of `phone` and therefore `contact:phone`
(because they mean the same): "If the `phone` key is mapped on an
object with `amenity=telephone` then `phone` is the phone number of the
telephone box and not the phone number of the operator."
- `phone` --> `contact:phone`
- `email` --> `contact:email`

Now the difficult part begins because no "mechanical edit" is possible
(or at least very difficult and error-prone) here:
- `contact:website`: Only websites to be used for contacting purpose
only (and having little or no information character).
- `website`: All the other websites of a POI not fitting in the
definition of `contact:website`. So providing valuable information
about the POI.

Cheers

Sören Reinecke alias Valor Naram


-Original Message-
From: Martin Koppenhoefer 
Reply-To: "Tag discussion, strategy and related tools" <
tagging@openstreetmap.org>
To: Cj Malone 
Cc: tagging@openstreetmap.org
Subject: Re: [Tagging] Remove non-prefixed versions of 'contact:'
scheme
Date: Mon, 11 May 2020 00:01:33 +0200


sent from a phone
> On 10. May 2020, at 23:55, Cj Malone  wrote:
> I think we should actively encourage more precise tags
> likecontact:phone when it's a contact number.

why is this “more precise”? What about even “more precise” tags,
likecontact:phone:business_hours=contact:phone:reservations=even
better?
IMHO dataconsumers find the tags easiest if they use the same key, if
they have to search for the keys it will make everyone’s life harder
not better.
Cheers Martin ___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] Remove non-prefixed versions of 'contact:' scheme

[Sören alias Valor Naram]

Hey,I am a "data customer", see https://babykarte.OpenStreetMap.de . That's why I initiated this discussion because this is important for me. But mappers are not listening to data customers and think they know how a database works (only few of them know that and those come from a technical field).~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Remove non-prefixed versions of 'contact:' schemeFrom: Richard Fairhurst To: Tagging@openstreetmap.orgCC: I love the fact that we are now 50 messages into discussing, for the secondtime, a change that would be made ostensibly for the benefit of dataconsumers, and yet no one has asked any actual data consumers.https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_Ship_BRichard--Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html___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

[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 <valin...@gmx.net>:> 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

[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

[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

[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

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

[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] Feature Proposal - Voting - (phone)

[Valor Naram via Tagging]

Will come, will come, please be patient. This is on ny ToDo list.~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - Voting - (phone)From: MARLIN LUKE To: Martin Koppenhoefer ,"Tag discussion, strategy and related tools" CC: 



Given the comments, wouldn't it make sense to reopen at the opposite, i.e legitimating contact:phone over phone?




The idea of having only one instead of two tags was apparently quite approved in itself.



De : Martin Koppenhoefer 
Envoyé : mardi 5 novembre 2019 22:29
À : Tag discussion, strategy and related tools 
Objet : Re: [Tagging] Feature Proposal - Voting - (phone)
 



sent from a phone

On 5. Nov 2019, at 14:05, Valor Naram  wrote:





Hey,


it's over. I closed the vote with 61 votes against and 46 votes for my proposal.
My proposal has been rejected by community members: 
https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone





that’s a notable participation, compared to average tag votings in the OpenStreetMap wiki, interestingly, as an approval would probably have had the same effect than the rejection ;-)




Cheers Martin 





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

Re: [Tagging] Feature Proposal - Voting - (phone)

[Valor Naram]

Hey,

it's over. I closed the vote with 61 votes against and 46 votes for my
proposal. My proposal has been rejected by community members:
https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone



--
Cheers

~ Sören Reinecke alias Valor Naram


Developer of the Babykarte - https://babykarte.github.io
Participating in MapDiscover project - https://mapdiscover.org
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (phone)

[Valor Naram via Tagging]

Hi,the vote is running out on 5th Novembre 2019. Please vote for "Yes" and make life easier for both mappers and developer.https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phoneMy mission is to clean up the "mess" from the past. My mission is to prepare OSM for Mainstream entry. My mission is to make understanding and using OpenStreetMap easier for data users and potencial new mappers.Things like "Two Tags For The Same Purpose" prevents that. Supporting two tags causes more work and pain to all: for developers, researchers, for mappers, for the OpenStreetMap Community and of course for customers.~ Sören Reinecke alias Valor Naram Original Message Subject: [Tagging] Feature Proposal - Voting - (phone)From: Valor Naram via Tagging To: tagging@openstreetmap.orgCC: Valor Naram Hey,I finally opened the voting "Make `phone` Tag default for taggingtelephone numbers in OSM and deprecating contact:phone`. Please placeyour voice at https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone. The Voting will be closed at 5th Novembre 2019. Please read the Proposal page carefully before waiting because the specification (everything in the `content` section) there will be the specification shown in https://wiki.openstreetmap.org/wiki/Key:phoneProposal description:This proposal tends to make Key:phone the officialtag for tagging phone numbers and to deprecate the tag contact:phonewhich is used less. It's bad to have two keys for the exact samepurpose in use.--Cheers~ Sören Reinecke alias Valor Naram,Developer of the Babykarte - https://babykarte.github.ioParticipating in MapDiscover project - https://mapdiscover.org___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 - Voting - (phone)

[Valor Naram via Tagging]

nt: I do not make changes to the specifications of
the `phone` key. I just do a re-wording.

To your last statement: Apparently you aren't a developer who wants to
use/uses data from the OpenStreetMap project. E.g. we need to check, if
`phone` and `contact:phone` are equal or not. That takes time. Time we
could have spend on other (useful) things, if the OSM community had not
done this. And if we detect that they are equal like in this case, we
will need to develop a replacement function which we hate because
normally you wouldn't do such crazy things like having two tags for the
same purpose.



--
Cheers

~ Sören Reinecke alias Valor Naram,


Developer of the Babykarte - https://babykarte.github.io
Participating in MapDiscover project - https://mapdiscover.org
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (phone)

[Valor Naram via Tagging]

> Valor Naram, could you clarify what specific changes will be made to> the page, based on approval of this proposal? Is it just rewording, or> are there any significant changes to how the tag is used?Basically it's just a rewording and redesign but actually there are some minor differences.Specifications I did not include:- If your country does not use area codes, that part should be left out.- Note that for phone numbers that are in international E.164 format, space (or even hyphen) separators are not significant, but the convention is to use a separator at least between the ITU-T country code and the rest of the phone number. The other groupings are optional: area codes should preferably be separated only in countries where they are still used distinctly for domestic calls; in other countries, the groupings are just kept by convenience and according to local usages in phone books or as shown in amenities (these groupings may vary for mnemonic reasons only, there's no requirement to suppress these group separators even if they are ignored when dialing). - Some mappers started to add emergency numbers to police stations, hospitals and fire stations. This is fine as long as local numbers are used and the number is really bound to the object. You should not map objects with universal emergency numbers (e.g. 911 / 110 / 112) for local objects since this could result in non emergency calls blocking real emergency calls when people try to reach a local police station, hospital or fire station with non emergency matters.- In NANPA countries such as the United States and Canada, businesses commonly use phonewords in posted phone numbers. phone=* should contain the numeric, fully resolved phone number for machine readability. Phonewords seen on signage etc. can go in phone:mnemonic=*, which could help search engines display the phone number more memorably. For example, "710-555-BEEF" would be tagged phone=+1-710-555-2333 phone:mnemonic=+1-710-555-BEEF and "55-KLICK" within the 710 area code would be tagged phone=+1-710-555-5425 phone:mnemonic=+1-710-55-KLICK.- "How to map" section- Italy does not omit the 0 in the international format like many countries do (the "0" default trunk prefix may be replaced by a "trunk selection code" in calls from within the country, but only for phone numbers that have this selection feature enabled: not all national phone numbers have a trunk selection code, and some ranges of "short" numbers, not starting with the default "0" trunk code, may also be called internationally; so this default "0" trunk code must still be used when calling from abroad). So the Milan number 02.724261 becomes phone=+39 02 724261 in OSM. A few other countries are doing the same and require dialing the national trunk selection code when calling them from abroad. - The phone numbers in the United States and Canada consist of the following four elements: "+" (plus sign), the international country code (1), the area code and the local telephone number (written in two memorable blocks). A locally formatted US number may look like this: (303) 555-1765 (without the international area code). The same phone number in E.164 format would be: +1 303 555 1765. However, the NANP notation (+1-303-355-1765) is used as a quasi-standard based on the local notation (see Usage section). - "Parsing phone numbers" sectionSummary: I removed all sections which interfere with the international code or sections which support the international code because its specific at the beginning. I also assume that mappers leave `` out in countries that do not have area codes.~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - Voting - (phone)From: Joseph Eisenberg To: "Tag discussion, strategy and related tools" CC: > Whatever else may have been changed in this proposal, the number formatwasn't one of those changesSorry, I didn't realize this. I was reading the proposal and assumedthat the "Content" section was supposed to be different.Valor Naram, could you clarify what specific changes will be made tothe page, based on approval of this proposal? Is it just rewording, orare there any significant changes to how the tag is used?- JosephOn 10/21/19, Paul Allen  wrote:> On Mon, 21 Oct 2019 at 00:58, Warin <61sundow...@gmail.com> wrote:>>> On 21/10/19 09:52, Joseph Eisenberg wrote:>> >>> > For example, requiring the country code in all phone numbers would not>> > be standard practice in Indonesia or the USA, since people in these>> > countries very rarely make phone calls to other countries.>>>> It is not 'standard practice' in Australia, New Zealand either.. but it>> is>> what is done in OSM to enable people from outside that country to call>> that>> numbe

[Tagging] Feature Proposal - Voting - (phone)

[Valor Naram via Tagging]

Hey,

I finally opened the voting "Make `phone` Tag default for tagging
telephone numbers in OSM and deprecating contact:phone`. Please place
your voice at 
https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone. 
The Voting will be closed at 5th Novembre 2019. Please read the Proposal page 
carefully before waiting because the specification (everything in the `content` 
section) there will be the specification shown in 
https://wiki.openstreetmap.org/wiki/Key:phone

Proposal description:
This proposal tends to make Key:phone the official
tag for tagging phone numbers and to deprecate the tag contact:phone
which is used less. It's bad to have two keys for the exact same
purpose in use.

--
Cheers

~ Sören Reinecke alias Valor Naram,


Developer of the Babykarte - https://babykarte.github.io
Participating in MapDiscover project - https://mapdiscover.org


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

Re: [Tagging] Feature Proposal - RFC - (Phone)

[Valor Naram]

`contact:phone` and `phone` are exactly for the same purpose, no differences just different names.See https://wiki.osm.org/Key:contact~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (Phone)From: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: sent from a phoneOn 8. Oct 2019, at 15:40, Colin Smale via Tagging <tagging@openstreetmap.org> wrote:In that case it makes perfect sense to consolidate onto one or the other. But if there are any perceived semantic differences, however subtle, then either we find some way to represent that using other tagging, or we accept that a certain nuance will be lost.
there could be phone numbers with automatic announcements, so “phone” will still be valid, but contact:phone would not suit well. To give an example. It cannot be seen from the “phone”-key that this is the case though. I’m happy with loosing the subtle differences that may make  “contact:”-prefixed tags slightly more specific, in exchange for more universally usable “almost-equal” more generic tags without the prefix.Cheers Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Phone)

[Valor Naram]

A short summary of what we have so far:- Deprecation of `contact:phone` has some advantages: Key `phone` is used far more often, Key `phone` is shorter to write and better to find in word completion functions of editors like iD, Data users don't have to support two methods of tagging phone numbers.- Deprecation of `contact:phone` has one disadvantage: It's not grouped anymore and we have to solve this by creating a new wikipage which lists all keys that can be used for contacting purposes (e.g. throw a contact tab like the Babykarte has).~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (Phone)From: Joseph Eisenberg To: "Tag discussion, strategy and related tools" CC: Re: “if you want to display a tab with all the means of contact, you just have to look for contact:”That doesn’t work, because “phone=“ is much more popular and probably always will be, and  the “contact:” prefix is not used terrible consistently (is a website actually a way to contact a feature? Usually not)Keys should be designed for the convenience and ease of use by mappers, because the time of individual mappers is by far the greatest value input into Openstreetmap. Database users and developers (myself included) need to do a little more work sometimes, to give thousands of mappers a little less work and a little more fun.I support deprecating “contact:phone” and just using “phone=“
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Phone)

[Valor Naram]

> let’s us all save a lot of typing and let’s bury the contact: - prefix.The time will come at least I will try to accomplish this.~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (Phone)From: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: sent from a phone> On 7. Oct 2019, at 22:40, Kevin Kenny  wrote:> > I think that's a claim that needs to be demonstrated. Certainly, the> complexity of the contact:* schema and the variety of both editors and> data consumers has proven to be a barrier to widespread acceptance.frankly I am an old fashioned contributor and do not like presets. When I am going to add tags, I type them, the beginning, and usually tag completion will have the correct tag after 1-4 key strokes. I am sure there are more people like me, maybe we‘re a minority, but if we are I bet it’s significant. Now for this kind of workflow, namespaces are problematic. I already dislike farmyard and farmland for the 5 characters required, not to speak about addr:housenumber and addr:housename (the latter is mostly useless but as a is before u, this often forces me to type 12 characters before I can hit return). I have made peace with these tags as they are around for a long time, but they clearly aren’t the direction I would want the project to go more to. let’s us all save a lot of typing and let’s bury the contact: - prefix.Cheers Martin ___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 - (Phone)

[Valor Naram]

> One problem with enforcing a single tag by mappers or preprocessing> data before putting it in the database is that if there are subtle distinctions they are> forever lost.Sven gave us a list of tags which have exact meaning. So no distinctions. No differences, just another names.e.g. `phone` is the same like `contact:phone`. You could just find one difference: The name. And to have just the names different is a bad thing. In such cases we can make life a lot easier by just using one tag AND NOT two tags for the same purpose!~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (Phone)From: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Sun, 6 Oct 2019 at 20:35, Sven Geggus <li...@fuchsschwanzdomain.de> wrote:
I fully agree with this.  In opencampingmap POI database I currently do a
replacement of the following tags during database import:

booking -> reservation
contact:phone -> phone
contact:fax -> fax
contact:website -> website
contact:email -> email 

Would be nice to get rid of stuff like this.Maybe, maybe not (I'm on the fence).  I doubt you'll manage to.  There are too manyon both sides who insist that their way is the one true way.  It's possible that yourkluge is actually the best way of handling things like this.  Data consumers can translatecontact:phone to phone or phone to contact:phone or leave both untouched as theychoose.  One problem with enforcing a single tag by mappers or preprocessingdata before putting it in the database is that if there are subtle distinctions they areforever lost.  You can always scramble an egg but you can't unscramble one.-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Phone)

[Valor Naram]

Are you a datauser Paul Allen? Because I hate doing replacements, they ugly and they are work I hate. Replacements make Queries more ugly and longer.Replacements also make the database less reliable, that's literally the opposite of what OSM mappers actually want.ANDEXAMPLE SCENARIO: I look for a way to list all pois with phones. I find the wikipage for the `contact:phone` key. I start to use it in my query. I do not get all data and I think OSM has not good coverage for phone numbers as I thought. In this situation OSM is less reliable to me.My example scenario shows a datauser (in this example myself) who missed out the wikipage "phone" and just took the first one "contact:phone". That means some data is hidden from me. And datausers don't have the idea to search for a second wikipage which describes another way of tagging phone numbers because it's logial to have one aggreement on storing data and not one. Two or more ways of storing literally the same thing is what I call inconsistent and bad for database usage.~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (Phone)From: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Sun, 6 Oct 2019 at 20:35, Sven Geggus <li...@fuchsschwanzdomain.de> wrote:
I fully agree with this.  In opencampingmap POI database I currently do a
replacement of the following tags during database import:

booking -> reservation
contact:phone -> phone
contact:fax -> fax
contact:website -> website
contact:email -> email 

Would be nice to get rid of stuff like this.Maybe, maybe not (I'm on the fence).  I doubt you'll manage to.  There are too manyon both sides who insist that their way is the one true way.  It's possible that yourkluge is actually the best way of handling things like this.  Data consumers can translatecontact:phone to phone or phone to contact:phone or leave both untouched as theychoose.  One problem with enforcing a single tag by mappers or preprocessingdata before putting it in the database is that if there are subtle distinctions they areforever lost.  You can always scramble an egg but you can't unscramble one.-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Phone)

[Valor Naram]

I moved the content of my proposal to
https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone
because I don't work with categories and therefore I did not realize
the problem of two proposal in one page. As you can see I did not
stayed into the "Proposed_features" Schema because I do not propose a
feature. I propose the deprecation of a feature. This is a difference!

The content there tends to document the de-facto described at
https://wiki.openstreetmap.org/wiki/Key:phone but shorter and in my
opinion a bit more clear and faster to read except the last points I
simply copied from the source wiki page. I hope I documented the de-
faction well enough for you. If not, feel free to chance and improve it
but do not mark your changes as minor edit. I want to keep track on the
changes made to the page I created so I can use these changes to handle
the upcoming discussion here. As a reminder: The pre-discussion took
place in thread
https://lists.openstreetmap.org/pipermail/tagging/2019-September/048339.html
and the outcome was to deprecate "contact:phone"

MY OWN OPINION: I personally think that "contact:phone" is
schematically better but I also agree that "phone" is better because
it's a shorter key, better to find in the wiki and used widely among
the community. So I propose deprecating "contact:phone" for the reason
why I think "phone" will win (or has already won according to its
sightly more usage).

Cheerio

Sören Reinecke alias Valor Naram

On Sat, 2019-09-28 at 10:31 +0200, Valor Naram wrote:
> Hey,
>
> now I'm ready to open a new proposal which you can see here
> https://wiki.openstreetmap.org/wiki/Proposed_features/Phone#Second_proposal_.28pending.29
>
> I use the old proposal page for that but seperated content into
> section
> to keep the history intact. The content is based on the discussion at
> https://lists.openstreetmap.org/pipermail/tagging/2019-September/048339.html
>
> . It tends to deprecate `contact:phone` in favor of the more used de-
> facto `phone` tag. It's awful that we have two tags for the same
> puropose in our database and that makes it more difficult for
> developers and researchers to work with our data.
>
> Cheers
>
> Sören Reinecke alias Valor Naram
>
>
> ___
> 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] Strange tags

[Valor Naram]

But as datauser I won't use that data. We need to find a way to make the tags more useful in global scope. That can be done by translating to widely supported tags etc.~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Strange tagsFrom: ael To: tagging@openstreetmap.orgCC: On Sun, Sep 29, 2019 at 07:24:16PM +0200, Jan Michel wrote:> On 29.09.19 17:07, Paul Allen wrote:> > > > Really?> > > > There are people who are VERY interested in these things.  People who> > want to know where> > Munros, Donalds, Grahams, Marilyns, TuMPs, etc. are.> > Well... There is no documentation of these tags in the OSM wiki.While that is certainly desirable, it is not necessary, especially wherethe terms are well known - at least in the relevant region.> > These seem to be very local terms that are not used outside of Scotland> (British Isles?). In general we oppose such local terms as keys because they> won't be of any use outside a small area.Who are "we" who oppose such terms? OSM is trying to be the best map possible, and the map should be usefulin small areas (like the UK) as well as more globally.Even if one local mapper with special local knowledge tags somethingonly understood in a very small area, it is still improving the map.ael___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Strange tags

[Valor Naram via Tagging]

Be sure that almost no data user will evaluate these tags~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Strange tagsFrom: ael To: tagging@openstreetmap.orgCC: On Sun, Sep 29, 2019 at 09:09:16PM +0700, Dave Swarthout wrote:> donald=yes> ele=821> graham=no> man_made=cairn> munro=no> name=White Coomb> natural=peak> note=cairn yes> source=local_knowledge> wikidata=Q7994603> wikipedia=en:White CoombThese are well known terms in the UK, so I would think they are validand useful tags.ael___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 - (Phone)

[Valor Naram]

You forget that `phone` is identical to `contact:phone` except the name. It's just not similar, it's the same by 99,99%.For example:Researchers will wonder why are there not so many data for tag `contact:phone`. Researchers might not know that there are two ways of tagging phone numbers. So they don't get the most data because they don't notice the `phone` key which is used more widely. Do you really want that? There is no logical reason to have two tags for the same purpose.Another thing: You speak about "similiar purpose" and I speak about "same purpose". This is a big difference.~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - (Phone)From: Chris Hill To: tagging@openstreetmap.orgCC: I disagree with this idea that we must remove similar tags for the sake of it.Anyone who actually uses OSM data (rather than people who just imagine using it) know that there are many steps and choices to make to achieve the end result. Often this involves combining data with various tags that fit the requirements of the analysis, render, routing or whatever, so combining data from similar tags is normal, not hard to do and once done is repeatable over and over. It is not awful to have two tags for a /similar/ purpose at all.Removing seemingly similar tags and so homogenising the OSM database is a very risky path to take. We risk removing subtlety and obscuring mappers' real intent. The world we live in and try to represent with map data is a muddled, mixed-up, jumble of human-made stuff that includes many contradictions and minutely different things. One great strength of OSM tagging is that mappers can find ways to represent this. If we march down the homogenisation highway much of that strength will be lost.I oppose deprecating contact:phone=*-- cheersChris Hill (chillly)On 28/09/2019 09:31, Valor Naram wrote:> Hey,>> now I'm ready to open a new proposal which you can see here> https://wiki.openstreetmap.org/wiki/Proposed_features/Phone#Second_proposal_.28pending.29> I use the old proposal page for that but seperated content into section> to keep the history intact. The content is based on the discussion at> https://lists.openstreetmap.org/pipermail/tagging/2019-September/048339.html> . It tends to deprecate `contact:phone` in favor of the more used de-> facto `phone` tag. It's awful that we have two tags for the same> puropose in our database and that makes it more difficult for> developers and researchers to work with our data.>>___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (Phone)

[Valor Naram]

Hey,

now I'm ready to open a new proposal which you can see here
https://wiki.openstreetmap.org/wiki/Proposed_features/Phone#Second_proposal_.28pending.29
I use the old proposal page for that but seperated content into section
to keep the history intact. The content is based on the discussion at
https://lists.openstreetmap.org/pipermail/tagging/2019-September/048339.html
. It tends to deprecate `contact:phone` in favor of the more used de-
facto `phone` tag. It's awful that we have two tags for the same
puropose in our database and that makes it more difficult for
developers and researchers to work with our data.

Cheers

Sören Reinecke alias Valor Naram


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

Re: [Tagging] [Key:phone] - Suggesting wiki page changing

[Valor Naram]

That is definitely not what I want. I was just picking up the suggestions made from within this list.Yes, the current Key:phone wiki page provides a way to tag those cases we're talking about which I am going to describe further:- `phone:` Phone number that can be reached from just within the country `` e.g. `phone:de=4445 747268`- `phone` Phone number in international format which can be called from abroad and not just from country `` e.g. `phone=+49 4341 747268`I also incorporated it into my spec for Key:phone (see the initial e-mail of this thread) because I want to clean up the mess from the wiki page. I don't bother to delete `phone:emergency` and so on from my spec.~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] [Key:phone] - Suggesting wiki page changingFrom: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Wed, 25 Sep 2019 at 18:08, Valor Naram <valin...@gmx.net> wrote:So you suggest `phone:international` and `phone` beside of the other keys `phone:press`, `phone:night`, `phone:emergency`?Every time somebody suggest that we don't need all the phone variants that can befound in the wild, you pop up interpreting that person as suggesting we need even more.What Colin suggested was that PERHAPS we need to deal with the situation where thephone has one number when dialled from within the same country but a different numberwhen dialled internationally.  What he failed to notice is that the wiki already suggests away of dealing with this (and it doesn't use phone:international).You appear to be just flinging variants of phone at the wall in the hope some will stick, possiblyso you can use those as a wedge to get whatever variant it is that you really want.  If that iswhat you're doing, I don't think it's helping your case because I'm rapidly tiring of it and itappears that many people think we don't need all the variants we already have.-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Key:phone] - Suggesting wiki page changing

[Valor Naram]

So you suggest `phone:international` and `phone` beside of the other keys `phone:press`, `phone:night`, `phone:emergency`?~ Sören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] [Key:phone] - Suggesting wiki page changingFrom: Colin Smale To: tagging@openstreetmap.orgCC: 
On 2019-09-25 18:02, Paul Allen wrote:


On Wed, 25 Sep 2019 at 17:00, Valor Naram <valin...@gmx.net> wrote:

We should not talk any longer about charging plans (which provider and when will apply different charges to whom) because we're difting off --> going Off-Topic.
 
It is very much on topic because it is the basis of whether or not there is any point in making
a distinction between a mobile and a landline.  If there are no charge differences then they're
both just phone numbers and we don't need a special tag for mobile phones.
 





And the charge for dialling a given number is not simply a function of that number, but many other factors (source provider, time of day, day of week, source network, contract terms, ) It is hopeless to even think of capturing that in OSM. Let's just stick to a simple number.
 
One distinction that may be useful, is whether the number is universally dialable. Some numbers (often short codes) may only be dialable from phones on the same MCC or MCC+MNC in the IMSI or connected to the same MNO. Is the number dialable from a random phone in a different country? Or does it only work if you have (e.g.) a UK phone?
 
I think it would make sense to prefer universally dialable numbers. Often organisations have a free/premium number AND a normal number for "if you are abroad." The latter would get my vote if we can only have a single number. Otherwise we need some subtag so we can encode both?
 
 



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

Re: [Tagging] [Key:phone] - Suggesting wiki page changing

[Valor Naram]

We should not talk any longer about charging plans (which provider and when will apply different charges to whom) because we're difting off --> going Off-Topic.CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] [Key:phone] - Suggesting wiki page changingFrom: Colin Smale To: tagging@openstreetmap.orgCC: 
On 2019-09-25 16:08, Paul Allen wrote:



In the UK, people can tell that from the area code.

 
What about the cases where calls to customers on the same provider are free? In general you have no way of knowing who is on which provider. And thanks to number portability it is getting shuffled at a few percent a year anyway.
 
 
 
 




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

Re: [Tagging] [Key:phone] - Suggesting wiki page changing

[Valor Naram]

So we're good to keep `phone:mobile` for mappers who know if the number is a mobile one or landline.We can keep `phone:mobile` for explicit ones where you can say to 100% this is a mobile phone number and will be *generally* charged as such.CheersSören Reinecke alias Valor NaramPS: Don't be confused. I do not even bother, if we differenciate between mobile numbers and landlines or not. Original Message Subject: Re: [Tagging] [Key:phone] - Suggesting wiki page changingFrom: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Wed, 25 Sep 2019 at 09:04, Martin Koppenhoefer  wrote:I don't see the problem, can you explain?[Note: some simplifications ahead.  Broadly true but there are many exceptions inreality.]In the UK, calling rom landlines, calls to mobile numbers are more expensive than calls to landlines.  These days, not by much but in the past the difference was large.  BT's prices are a 23p call setup charge then 15p/minute to landlines and 18p/minute to mobiles.  Unless you have one of their packages that give you free calls to landlines (not even a setup charge) but9p/minute to mobiles (with the 23p setup).There are no guarantees that this won't change in the future:  Maybe for the better, maybe for theworse.If you're calling from a mobile phone then the charging situation is complex.  Depending onwhich MNO or MVNO you're using, it may be very complex (although it's not as bad as it usedto be).  Generally it has been the case in the past that if you were calling from a mobile it was cheaper to call another mobile than a landline,  These days there's either no difference orit's small, but that could change.Fortunately, in the UK, mobile numbers start with a 7 and non-mobile numbers do not (otherpotentially-expensive calls have different prefixes).The situation is different elsewhere in the world, of course.  In the US it's the callee, notthe caller, who pays the call charges for calls to mobiles.  Oh the joys of living in a countrywhere you not only get junk advertising calls on your mobile, but you have to pay to receivethem. By the way, this is not about Italy. In Germany [1] and likely in many other places you can also get your landline number on a mobile phone. I'm using a German landline number for almost 20 years on my desktop and for 10 years on my mobile. It is not new technology, and it can be used everywhere, not just in Italy.  Another possibility would be call redirect. No way to tell where a number will be routed to (if you aren't a telco).Number remapping, of one form or another, has been around for a long time.  But 20 years agoit was expensive and rare.  After regulations requiring number portability for mobile ownersswitching between carriers, the technology became cheaper to implement.  I'm not sure if UKcompanies offer anything other than redirection when it comes to terminating a landline on amobile or a mobile on a landline but if they do I'd expect call charges to be appropriate tothe number prefix.So people do find it useful to know if a phone number is to a landline or a mobile.  Less sothan in the past, because the cost difference is smaller, but still useful.  However, in the UKwe can tell by inspecting the number: if it starts with a 7 it's a mobile.  So in the UK we don'tneed a tag to tell us.  This isn't true of all countries: in the US you can't tell if you're callinga landline or a mobile, but you don't care because the person receiving the call is paying.-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Key:phone] - Suggesting wiki page changing

[Valor Naram via Tagging]

So the distinction of mobile and landline is a problem. Is there any possibility to distinct between landline and mobile also in Italy?CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] [Key:phone] - Suggesting wiki page changingFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: sent from a phone> On 23. Sep 2019, at 16:19, Volker Schmidt  wrote:> > Here in Italy you may dial a number that looks like a landline but is in reality a mobile number.> I would very much prefer a list of numbers, and not have to do tricks like phone_1, phone_2 ... but also not to have to specify if a number is mobile or landline.+1,with phone numbers you can currently still see how it used to work in the analog times (e.g. shops in the same area still have mostly the same initial local digits), but these are clearly traces of the past that will sooner or later vanish, with modern equipment you can have (at least theoretically) any number routed anywhere. For example SIP based phone numbers often look like local numbers of a specific area, but in fact are routed via the internet and the actually connected device could be anywhere on earth.Cheers Martin ___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Key:phone] - Suggesting wiki page changing

[Valor Naram via Tagging]

> What about the other less frequently used duplicates contact:website, contact:email and contact:fax? Wouldn't it make more sense to deprecate them all instead of just one?At least `contact:email` will come. I prefer to work step for step.CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] [Key:phone] - Suggesting wiki page changingFrom: Markus To: "Tag discussion, strategy and related tools" CC: On Sat, 21 Sep 2019, 20:51 Valor Naram via Tagging, <tagging@openstreetmap.org> wrote:I want to change the wiki page
https://wiki.openstreetmap.org/wiki/Key:phone throw a Proposal process
to do certain things:
  - Deprecating `contact:phone`What about the other less frequently used duplicates contact:website, contact:email and contact:fax? Wouldn't it make more sense to deprecate them all instead of just one?Is there a possibility to use Markdown in our wikiNone that i know of.or to convert Markdown into
wiki formatting?https://pandoc.org, according to its homepage, but i've not tried it myself.Regards,Markus

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

[Tagging] [Key:phone] - Suggesting wiki page changing

[Valor Naram via Tagging]

I want to change the wiki page
https://wiki.openstreetmap.org/wiki/Key:phone throw a Proposal process
to do certain things:
  - Deprecating `contact:phone`
  - Promoting `phone`
  - Extending `phone`
  - Protecting the wiki page against "wild changes" in the interest of
the community (to maintain a consistent use of `phone` because as one
of the most used keys on OSM we cannot use `phone` differently or not
following the specification at all. We simply cannot do that because
apps working this that key need a consistent tagging scheme.)

But before I do that, I will hear your voices. I included a Markdown
file with this e-mail and want to know what you think. Is there a
possibility to use Markdown in our wiki or to convert Markdown into
wiki formatting?

Cheerio

Sören Reinecke alias Valor Naram
# Usage

## Format of phone numbers

Phone numbers should be always in the following format ([ITU-T E.123](http://en.wikipedia.org/wiki/E.123 "wikipedia:E.123") and [DIN 5008](http://en.wikipedia.org/wiki/de:DIN_5008 "wikipedia:de:DIN 5008")):

+  

or ([RFC 3966](https://www.ietf.org/rfc/rfc3966.txt)/[NANP](http://en.wikipedia.org/wiki/NANP "wikipedia:NANP"))

+--

Both in [ITU-T E.164](http://en.wikipedia.org/wiki/E.164) format

## Usage

| Key   | Description| Example   | Notes   |
| - | -- | - | --- |
| `phone`   | Put in the phone number under which the facility which runs that POI can be contacted  | `phone=+49 3316 769689`   | |
| `phone:press` | Phone number for press inquiries   | `phone=+49 3316 76968901` | |
| `phone:night` | Phone number to be called at night (local time of the place the facility is in)| `phone=+49 157 3929054`   | |
| `phone:emergency` | Phone number to be called in case of emergency | `phone=+49 157 3929054`   | |
| `phone:`| Phone number to be called just from a person who lives or has a stay in  (country). Please ommit the country code in the phone number when the number can only be called from within that country specified in ``. | `phone:FR=+33 6 12654478` or `phone:BE=+32 5753 6245` | See the _Tagging different numbers for different countries_ section for better explanation. |
| `phone::mobile` | Mobile phone number to be called from a person who lives or has a stay in (country). Please ommit the ``when the number can only be called from within that country specified in ``. | `phone:FR:mobile=3000`| See the _Tagging different numbers for different countries_ section for better explanation. |

### Subkeys

This tagging supports the use of subkeys. Subkeys are in the following format:

phone:

For Example:

phone:press

| Subkey   | Description  | E

Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose

[Valor Naram via Tagging]

Let me summarizeWhy `phone`:- It's more used- It's shorter- Better to find in wikiWhy `contact:phone`:- It's more structured because it's a subkey of `contact`- It's better to find in wiki (for people who think in a "more structured" way)- It's the approved oneBoth let us add more subkeys like `emergency`CheerioSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purposeFrom: Colin Smale To: tagging@openstreetmap.orgCC: 
On 2019-08-26 15:53, Martin Koppenhoefer wrote:

sent from a phoneOn 25. Aug 2019, at 18:06, Andy Mabbett <a...@pigsonthewing.org.uk> wrote: there are at least two possibilities:phone= phone:emergency= phone:staff= and:phone= emergency:phone= staff:phone= Neither of which requires "contact:" exactly, I was about to reply the same, it is not an issue for more specific tags that there is also a generic tag.

So will we now have the OSM-style discussion about which phone number to put in the generic tag? All numbers are equal, but one is slightly more equal than the rest...
 
 

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

Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose

[Valor Naram]

https://wiki.openstreetmap.org/wiki/Key:phone and https://wiki.openstreetmap.org/wiki/Key:contact don't provide any tagging method to tag numbers for emergency, general enquiries etc. Both keys just allow the tagging of one phone number on one object.But feel free to write a proposal to extend the tagging scheme of `phone` to:- `phone`- `phone:emergency`- `phone:night`- `phone:press`Feel free also to extend the `email` tag:- `email`- `email:press`- `email:legal`But we're drifting away from the topic "Multiple tags for one purpose". We should discuss the problem of "fragmentation" in general. But deprecating `contact:phone` in favor of `phone` can be the logical step.CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purposeFrom: Colin Smale To: tagging@openstreetmap.orgCC: 
Your model (using only phone=*) only allows an object to have a single phone number. How do you propose modelling multiple phone numbers on a single object? For example, one for general enquiries, one for emergencies, one for staff,...
Note I am not talking about tagging here, but trying to discuss the underlying data model.
 

On 2019-08-25 17:11, Valor Naram wrote:

> What about deprecating the contact: prefix, at least for phone? It doesn't seem it will ever make it and is basically a deliberate tag fragmentation.Yes, I recommend deprecating `contact:phone`
 Original Message Subject: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purposeFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: 
sent from a phone> On 25. Aug 2019, at 07:20, Warin wrote:> > Type 'phone' into the OSMwiki search box and you get redirected to the key 'phone=*'.> This gets preferential treatment to the key 'contact:phone=*'.seems fair that "key:phone" shows up first for a search for "phone", it's straightforward, and it's also the most used tag for phone (numbers).The contact prefix is pointless, why would we make everybody who doesn't use presets type longer key names when there are no alternatives which would require to distinguish the tag from? People who do use presets don't have to care for tag names anyway.If you search for "contact phone" the first hit is key:contact, one could argue a better result would be showing key:phone first for this search term as well, as it is the mostly used tag for a generic phone number.What about deprecating the contact: prefix, at least for phone? It doesn't seem it will ever make it and is basically a deliberate tag fragmentation.Cheers Martin ___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging


___ 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] phone vs contact:phone WAS Re: Multiple tags for one purpose

[Valor Naram]

> What about deprecating the contact: prefix, at least for phone? It doesn’t seem it will ever make it and is basically a deliberate tag fragmentation.Yes, I recommend deprecating `contact:phone` Original Message Subject: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purposeFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: sent from a phone> On 25. Aug 2019, at 07:20, Warin <61sundow...@gmail.com> wrote:> > Type 'phone' into the OSMwiki search box and you get redirected to the key 'phone=*'.> This gets preferential treatment to the key 'contact:phone=*'.seems fair that “key:phone” shows up first for a search for “phone”, it’s straightforward, and it’s also the most used tag for phone (numbers).The contact prefix is pointless, why would we make everybody who doesn’t use presets type longer key names when there are no alternatives which would require to distinguish the tag from? People who do use presets don’t have to care for tag names anyway.If you search for “contact phone” the first hit is key:contact, one could argue a better result would be showing key:phone first for this search term as well, as it is the mostly used tag for a generic phone number.What about deprecating the contact: prefix, at least for phone? It doesn’t seem it will ever make it and is basically a deliberate tag fragmentation.Cheers Martin ___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Add amenity=childcare to Map Features?

[Valor Naram]

why not. Babykarte has also support for `amenity=childcare` Original Message Subject: [Tagging] Add amenity=childcare to Map Features?From: Joseph Eisenberg To: "Tag discussion, strategy and related tools" CC: The tag amenity=childcare is fairly popular (used 17,000 times), andit's supported by the iD editor and the Openstreetmap-carto rendering.Should this tag be added to the wiki page Map Features?The original proposal wasn't supported because some people thoughtthat amenity=kindergarten should be used for all types of childcare,not only preschools/kindergartens. This seems to be the commonsituatoin in Germany, but may not match they types of daycare /childcare / preschool facilities available in other countries. Forexample, in the USA most preschools do not take older children afterschool; such after-school care is usually provided by separateprograms.Wiki page:  https://wiki.openstreetmap.org/wiki/Tag:amenity%3DchildcareProposal:  https://wiki.openstreetmap.org/wiki/Proposed_features/childcareCompare to Kindergarten:https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dkindergarten___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Multiple tags for one purpose

[Valor Naram]

And do you have any idea how to handle that problem? Supporting two or more tags meaning the same thing is dirty and results in longer queries.I might have an idea: Getting in dialogue with developers and mappers (users of one key, users of another key). Naming the problem and working alltogether to solve it. Goal: To deprecate one tag in favor of the other one. Developing a strategy.Best regardsSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Multiple tags for one purposeFrom: Joseph Eisenberg To: "Tag discussion, strategy and related tools" CC: Getting back to the original example, phone=* was proposed first andvoted on in 1/2008 - seehttps://wiki.openstreetmap.org/wiki/Proposed_features/Phone - the tagwas rejected. Some people at the time did not think that OSM shouldcontain phone numbers, others preferred something like contact:phone.However, starting in mid-2008 the tag started to be used anyway.I don't think there was every a proposal from contact:phone. Itstarted being used in mid-2009, but was never more popular thanphone=* (except for 2 months in 2008, after a small import or switchof tags to contact:phone), according tohttps://taghistory.raifer.tech.Over the past 12 months (8-2018 to 8-2019), contact:phone=* hasincreased by 50k from 260k to 310k, while phone=* increased by 200k,from 1200k to 1400k. So phone=* is clearly preferred by about a 4 to 1ratio, even though the original proposal was rejected.This is a good example of the "problem": the smaller group of peoplewho votes on tags does not always pick tags to approve which thegeneral mapping community will use, and sometimes rejects tags whichlater become the "de facto" standard.- JosephOn 8/25/19, Valor Naram  wrote:> That's why I want to involve all user groups. Mappers, developers and local> communities.>> Cheerio>> Sören Reinecke alias Valor Naram>>>  Original Message > Subject: Re: [Tagging] Multiple tags for one purpose> From: marc marc> To: tagging@openstreetmap.org> CC:>>>> Le 24.08.19 à 18:04, Valor Naram a écrit :>> > why we have two tags for one purpose sometimes?>>>> many (almost all bad) reasons can explain it :>>>> - one key exist, a new schema is born with a new tag for the same>> feature/meaning, but the new schema never got a proposal or the proposal>> never go into voting or the accepted proposal doesn't said enought "this>> tag is depreced" (ex : phone <> contact:phone) or the new tag have some>> issue and therefore some mapper want a new schema that solve everything>> before dropping the first one (source:maxspeed <> maxspeed:type)>>>> - some key have high usage and a part of the community is unwilling to>> apply some lifecycle to tag, hoping that one day, "the invisible hand of>> the community" (parody of the concept of the invisible hand in>> economics) will solve the problem while we bury our heads in the sand>> to deny the problem it creates (for ex building=cooling_tower <>>> tower:type=cooling)>>>> - 2 key exist, one use by one editor, other rejetected by this editor>> but used by all-expet-one (ex : crossing=marked)>>>> - 2 key exist but the exact meaning vary according to who used it.>> at the end, the only usable meaning is the same for both key (ex :>> landuse=forest <> natural=wood)>>>> - only one tag exist at the begining but the but the key is in>> contradiction with the meaning/logic of the key and therefore some>> have created a more structured alternative. however this alternative>> is rejected by the default rendering because the other key has>> a more important use. it is the problem of the egg and the hen.>> (ex: landuse=grass with have a clear meaning which is not a landuse)>>>> - all those involved in this ml and/or in a voting agree that a key>> should be depreciated, but someone thinks it would take hundreds of>> voters when there are not hundreds of participants. so motivated people>> go their way and the problem remains (see the discussion this summer...>> I don't remember the tag concerned)>>>> - some depreciated tags can't be converted automaticly because the tag>> have 2 meanings (ex power=sub_station). not enough mapper review those.>>>> - some proposal "hides" a depreciated tag into several other good stuff.>> at the end the proposal got rejected or some disagree to use "the vote".>> imho a "proposal to depreciate a tag" need to be as small as possible>>>> therefore the default osm.org editor think it must take the lead to>> decide what to depreciated and do a distributed automated edit.>> sometime

Re: [Tagging] Multiple tags for one purpose

[Valor Naram]

That's why I want to involve all user groups. Mappers, developers and local communities.CheerioSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Multiple tags for one purposeFrom: marc marc To: tagging@openstreetmap.orgCC: Le 24.08.19 à 18:04, Valor Naram a écrit :> why we have two tags for one purpose sometimes?many (almost all bad) reasons can explain it :- one key exist, a new schema is born with a new tag for the same feature/meaning, but the new schema never got a proposal or the proposal never go into voting or the accepted proposal doesn't said enought "this tag is depreced" (ex : phone <> contact:phone) or the new tag have some issue and therefore some mapper want a new schema that solve everything before dropping the first one (source:maxspeed <> maxspeed:type)- some key have high usage and a part of the community is unwilling to apply some lifecycle to tag, hoping that one day, "the invisible hand of the community" (parody of the concept of the invisible hand in economics) will solve the problem while we bury our heads in the sandto deny the problem it creates (for ex building=cooling_tower <> tower:type=cooling)- 2 key exist, one use by one editor, other rejetected by this editor but used by all-expet-one (ex : crossing=marked)- 2 key exist but the exact meaning vary according to who used it.at the end, the only usable meaning is the same for both key (ex : landuse=forest <> natural=wood)- only one tag exist at the begining but the but the key is in contradiction with the meaning/logic of the key and therefore somehave created a more structured alternative. however this alternativeis rejected by the default rendering because the other key hasa more important use. it is the problem of the egg and the hen.(ex: landuse=grass with have a clear meaning which is not a landuse)- all those involved in this ml and/or in a voting agree that a key should be depreciated, but someone thinks it would take hundreds of voters when there are not hundreds of participants. so motivated people go their way and the problem remains (see the discussion this summer... I don't remember the tag concerned)- some depreciated tags can't be converted automaticly because the tag have 2 meanings (ex power=sub_station). not enough mapper review those.- some proposal "hides" a depreciated tag into several other good stuff.at the end the proposal got rejected or some disagree to use "the vote".imho a "proposal to depreciate a tag" need to be as small as possibletherefore the default osm.org editor think it must take the lead to decide what to depreciated and do a distributed automated edit. sometimes it corresponds to the opinion of the community, sometimes not, and in this case the community has lost control and the automated editis poorly documented and sometime wrong. it sometimes leads to edit wars or an unpleasant discussions, it further cools down people who want to make another depreciation of a tag, or it motivates them to do so via a ticket for an editor since if the dev agrees, it will happen even if the community is against.possible solutions based on my limited experience :- talk to choice the better tag between 2 need to be done at the global level, arguments must be listened but ignore noice like "the wrong tag is too important to change"- making mecanical edit to migrate a depreciated/bad tag to its new value works well at the local (coutry) level, the discussion take place with the local community, without being polluted by "opponents in principle". several of us do that kind of thing.- probably we should make a "network" to share the proposals, this would have a global impact perhaps enought to progress on some tags while "opponents in principle" continue to have no solution to the problems exposed.- it is only when several local communities have agreed on the same choice and the countries in question have accepted a mass edition that it is possible to risk such a demand at the global level.I only did 3 at the global level, 2 to fix a bug in an editor,a third to migrate a marginal key.in 2 of the 3 cases, I had requests for explanations after the fact despite it was discussed wherever I thought it was necessary. I learned that next time, we will have to discuss even more and be even more square about where the discussion is taking place and about the documentation (one was not sufficiently documented when it begging).I am well aware of the unpleasant tone of my message, but I have not found a way to describe facts objectively while pointing out the problems that have persisted for years.Regards,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] Multiple tags for one purpose

[Valor Naram]

> Editors won't (in general) implement tags in presets unless they're widely used.  Unless editors and carto support tags, they won't get widely used, so editors and carto won't support them.  Chicken and egg.Yes, you're right. But I was the author of "changing_table" and the guy who lead it throw the proposal process and also Moderator of the discussion and votes. And contacting all the editors was no problem and they implemented "changing_table" and deleted "diaper" presets. See JSOM, OSMand, Vespucci and also iD. My effort shows that working together with different groups works.I would highly appreciate it when you give me a chance. In real life people are revelling their secrets to me because they trust me and I give them the feeling of being accepted as they are. It includes my talks with people from different worlds. More-Than-One-World Secrets. This connection I can try to create also among OSM folks (societies).Best regardsSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Multiple tags for one purposeFrom: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Sat, 24 Aug 2019 at 17:06, Valor Naram <valin...@gmx.net> wrote:In my opinion this is a topic we should consider working on and creating a wikipage to describe the "defragemtation" process in general.Doing so is probably not going to achieve much.  First we need to defragment OSM itself.It doesn't matter what wonderful tags we come up with here, if carto refuses to render themthen they won't get used.  It doesn't matter what wonderful tags we come up with here, if editorsdon't implement them as presets they won't get used.Carto won't (in general) render a tag unless it's widely used.  Editors won't (in general)implement tags in presets unless they're widely used.  Unless editors and carto supporttags, they won't get widely used, so editors and carto won't support them.  Chicken and egg.There are complications (of course).  Carto (in general) refuses to implement aliases, sowhatever the merits of deprecating landuse=grass in favour of landcover=grass, carto willrefuse to render landcover=grass.  Editors don't (in general) like implementing aliaseseither.  So however much we wish to try to fix bad tags, which are frequently misusedbecause the name or value was a bad choice, it probably won't happen.  Some editorsoccasionally decide they'll ignore the list, the wiki, and carto, and go their own way(sometimes they get their way and sometimes they get a slap on the wrist).So what we need at this stage is not a defragmentation process but joined-up thinkingbetween the various groups.  I'm not holding my breath on that one.-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Multiple tags for one purpose

[Valor Naram via Tagging]

The tagging Community (this list) will negotiate it and it's the office at the same time. The process should be like the process for proposals but only discussion and vote.RegardsSören Reinecke alias Valor Naram Original Message Subject: Re: [Tagging] Multiple tags for one purposeFrom: Peter Elderson To: "Tag discussion, strategy and related tools" CC: Valor Naram <valin...@gmx.net> het volgende geschreven:We need a system to prevent or instinct the usage of two or more tags for one purpose. I suggest the following behaviour:1. Negotiating which key can be considered as official.Who will negotiate, what do they have to negiate with?What office makes it official? What process?Chances are you will never get consensus. ___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Multiple tags for one purpose

[Valor Naram]

Hey,

some long time ago I wondered why we have two tags for one purpose
sometimes? For example: A mapper can use either the tag `contact:phone`
or `phone` to add a phone number to the database. I think this makes
the database dirty and for developers - like me - it's annoying to
support two or more tags for one purpose.

We need a system to prevent or instinct the usage of two or more tags
for one purpose. I suggest the following behaviour:
1. Negotiating which key can be considered as official.
1.1. A key which has been approved should be the official key but other
factors like usage or improving can be considered.
2. Deprecating the other key by following the introductions on the
https://wiki.openstreetmap.org/wiki/Deprecated_features page.
2.1. Opening issues for incorporating the official key into presets and
removing presets with the old key:
2.1.1. https://github.com/openstreetmap/iD/issues
2.1.2. https://josm.openstreetmap.de/newticket
2.1.3. https://github.com/westnordost/StreetComplete/issues
2.1.4. https://github.com/osmandapp/Osmand/issues
2.1.5. https://github.com/simonpoole/beautified-JOSM-preset/issues
2.1.6. ...
2.2. See how much the official key is used among mappers on
https://taginfo.openstreetmap.org/ and also see the usage count for the
old key. (For a period of 2-3 month)
2.2.1. If things are developing well and the official key gets more
usage and the old key less usage then we won't need a mechanical edit.
2.2.2. If things aren't working for some reasons like there are not
many real objects that can be tagged with the official key then we will
do a mechanical edit but keeping the `check_date` and
`review_requested` keys intact.

I also had an interesting talk with Quincy Morgan at
https://github.com/openstreetmap/iD/issues/6529#issuecomment-524437983
about "fragmentation" as Morgan calls it.


In my opinion this is a topic we should consider working on and
creating a wikipage to describe the "defragemtation" process in
general.

Cheers,

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

Re: [Tagging] Feature Proposal - RFC - amenity=power_supply

[Valor Naram via Tagging]

Like your message (+1) marc marc Original Message Subject: Re: [Tagging] Feature Proposal - RFC - amenity=power_supplyFrom: marc marc To: tagging@openstreetmap.orgCC: I think you were badly inspired when you listened to the supportersof the mega proposals that fail to pass the vote (see history of police=* diaper=* and many other).I think the first version of your proposal was good, just focus on anew tag, without including the unfinished debate on a common scheme for plugs/sockets/cables, without any depreciated tags. these 2 points are big enough in themselves to make each one a next proposal.Le 03.07.19 à 22:18, Michael Brandtner via Tagging a écrit :> I have now canceled the proposal. I really just wanted to establish a > tag for the shore power devices in front of my workplace. I don't have > enough interest and motivation to try to fit at least four different > kinds of power-providing devices into one tag. And I also can't think of > a way to prevent overlap in case of different tags for them.> > > Am 25.06.2019 um 13:32 schrieb Michael Brandtner via Tagging:>> I've now rewritten the whole proposal. To prevent overlap, the idea is >> now to incorporate all devices that provide electrical power under the >> same main tag. A problem I have not solved yet is how to incorporate >> the sub-tags of the tags that would be marked as deprecated?? (mainly >> amenity=charging_station). Am Samstag, 22. Juni 2019, 17:41:08 MESZ hat Michael Brandtner via >> Tagging  Folgendes geschrieben:>> Thank you for your comments so far. I've now written a proposal. https://wiki.openstreetmap.org/wiki/Proposed_features/amenity%3Dpower_supply >> The definition (wording can surely be improved):>> "??A place where you can get electrical power." I've not taken into account your discussion about different socket >> types. This would be the topic for a different proposal about >> improving the power_supply= sub-tag. But this proposal is only about >> establishing the new main tag. I'm looking forward to your comments!??>> ___>> Tagging mailing list>> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging>> ___>> Tagging mailing list>> Tagging@openstreetmap.org>> https://lists.openstreetmap.org/listinfo/tagging> > > ___> 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] Idea for a new tag: amenity=power_supply

[Valor Naram via Tagging]

> Looks good to me, except that the tag name should really be something like "power_supply:socket_type" rather than the over-generic "power_supply".+1___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wheelchair = hiking

[Valor Naram via Tagging]

This is a good point and should be the preferred way. For your purpose you should usehighway=pathwheelchair=designated.This tells mappers and other users of OSM data that the highway is a path https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath and designated for wheelchair users https://wiki.openstreetmap.org/wiki/Key:wheelchairCheerioSören alias Valor Naram Original Message Subject: Re: [Tagging] wheelchair = hikingFrom: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Tue, 18 Jun 2019 at 15:32, Andreas Lattmann <andrea.lattm...@ga-2.it> wrote:Is there any reason not to use the existing wheelchair=yes|no|limited|designated tags?  If you addwheelchair=yes to a hiking trail it is implicit that it is for hiking in a wheelchair.   A problem withadding wheelchair=hiking is that people may then misapply it (because it would be available ineditor drop-downs) to other ways where wheelchair=yes ought to be used.-- Paul-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] About the diaper key

[Valor Naram]

Oh thanks. Corrected it
https://wiki.openstreetmap.org/wiki/Key:changing_table and I also
notified all downstream users that this feature replaces Key:diaper

On Wed, 2019-06-12 at 16:28 +, marc marc wrote:
> I was looking at the proposal and diaper page :)
> somes changes
> diaper=bench -> changing_Table=limited
>
> diaper=room -> changing_table=yes + changing_table:location=room
> (you
> can't assume that the room is dedicated)
>
> Le 12.06.19 à 18:10, Valor Naram a écrit :
> > Hi marc,
> >
> > you can find the conversion table at
> > https://wiki.openstreetmap.org/wiki/Key:changing_table
> >
> > I promised to create such a table and I am not one who breaks his
> > promises
> >
> > On Wed, 2019-06-12 at 14:41 +, marc marc wrote:
> > > Hello,
> > >
> > > Le 12.06.19 à 16:14, Valor Naram a écrit :
> > > > "What do we do with the POIs having the Key:diaper?"
> > >
> > > I had proposed that a conversion table be added,
> > > this would have avoided reopening the thread :)
> > >
> > > imho the best thing to do, in order:
> > > - create the wiki page(s) for the new key(s) and values
> > > - add in the wiki page diaper the correspondence table and have
> > > a quick talk here to make sure everyone agrees.
> > > - inform all project that declare using it. ideally their preset/
> > > validator /datause could take into account both for example 1
> > > month,
> > > time for everyone to adapt the code and publish it (often
> > > monthly)
> > > - post a message on talk for "mecanical edit request"
> > > - pray that there is no opponent who would need to split
> > > the operation to take into account his opposition
> > > - pray that a editor will not secede by considering
> > > that the community choice is stupid
> > > - wait for code update for projects
> > > - do the mecanical edit
> > > - inform all project it's done
> > >
> > > Regards,
> > > Marc
> > > ___
> > > Tagging mailing list
> > > Tagging@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/tagging
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
> ___
> 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] About the diaper key

[Valor Naram]

Hi marc,

you can find the conversion table at
https://wiki.openstreetmap.org/wiki/Key:changing_table

I promised to create such a table and I am not one who breaks his
promises

On Wed, 2019-06-12 at 14:41 +, marc marc wrote:
> Hello,
>
> Le 12.06.19 à 16:14, Valor Naram a écrit :
> > "What do we do with the POIs having the Key:diaper?"
>
> I had proposed that a conversion table be added,
> this would have avoided reopening the thread :)
>
> imho the best thing to do, in order:
> - create the wiki page(s) for the new key(s) and values
> - add in the wiki page diaper the correspondence table and have
> a quick talk here to make sure everyone agrees.
> - inform all project that declare using it. ideally their preset/
> validator /datause could take into account both for example 1 month,
> time for everyone to adapt the code and publish it (often monthly)
> - post a message on talk for "mecanical edit request"
> - pray that there is no opponent who would need to split
> the operation to take into account his opposition
> - pray that a editor will not secede by considering
> that the community choice is stupid
> - wait for code update for projects
> - do the mecanical edit
> - inform all project it's done
>
> Regards,
> Marc
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

[Tagging] About the diaper key

[Valor Naram]

Hey,

the proposal at
https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table
has been accepted now and I can start with the post-vote process and creating a 
wiki page. The property Key:changing_table success the Key:diaper for now but 
we or at least I have to deal with the question "What's going on with the 
diaper key". The answer seems clear: Key:diaper is now superseded by 
Key:changing_table. While it's the part you CAN definetly answer with ease. The 
second part properly not. "What do we do with the POIs having the Key:diaper?"

I am very excited about hearing your ideas since some of you noted that
just replacing the diaper key and its values with the key and the
values of the new key can be problematic.

Cheerio

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

Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

[Valor Naram]

Yes it would work and I would highly appreciate it because it's easier for me to maintain a discussion page than a discussion on a mailing list. A discussion page gives me more control of the discussion itself which is needed for moderating.CheersSören alias Valor Naram Original Message Subject: Re: [Tagging] A modest proposal to increase the usefulness of the tagging listFrom: Graeme Fitzpatrick To: "Tag discussion, strategy and related tools" CC: Maybe we don't hold discussions on the list, but only have them on the discussion page of the proposal?Post to the list to say:Title: Proposal re I've come up with a proposal for Link: yPossibly include a brief synopsis of the proposal, but that should be on the proposal itself, so maybe not required?Then everybody comments on the discussion page.That page could get quite long, but should also be able to be laid out so that comments are grouped togetherPart AMy explanation    Your comment          My reply                Their comment                         Your response                               My amendmentPart BMy explanation      Etc2 weeks later, reply to your own original post to say "Voting now open - link x"Carrying on with that idea, if you've come up with possible changes to an existing tag, then post as Proposed changes to xxBrief explanationLinkSo if anybody is interested in telephone lines, underground waterways, police facilities etc, they can go to that page & discuss it, but if they're not, they don't!The mailing list should then become a concise index of what proposals are going through.Would that all work?ThanksGraeme

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

Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

[Valor Naram]

We should also remember ourselves that we want to talk objectively about topics as often as possible and avoiding debates that are driving too emotional. Sure, everyone is free to express his/her subjective view but it shouldn't enlarge to a emotional debate like in thread https://lists.openstreetmap.org/pipermail/tagging/2019-May/045707.html and ongoing. I am talking about iD's validation rules and the discussion about it. At the end it drove to a emotional debate about how someone should behave and such debates aren't helpful in my point of view. Original Message Subject: Re: [Tagging] A modest proposal to increase the usefulness of the tagging listFrom: Christoph Hormann To: "Tag discussion, strategy and related tools" CC: On Sunday 02 June 2019, Simon Poole wrote:>> - not posting more than 30 times per month (the 30 comes from the WMF> mailing lists, where it seems to work quite well)>> - not more than one proposal per person per month>> - not more than 4 new proposals per month in totalNote there have been in the past opinions that documenting a new tag without creating a proposal is not desirable (see the "motorcycle:scale" thread earlier this year).  If you combine that with the limitation of the number of proposals that can be made you would essentially limit our base principle of "Any tags you like".In other words:  Any rate limitation to the proposal process would IMO need to go with a clear agreement that the proposal process is optional for creating a new tag.In the past i usually preferred the wiki for bringing up and discussing questions related to specific tags especially because it allowed for more selective participation in discussion.  But the introduction of bot edits into the wiki to me largely burnt the whole thing.  A clear agreement that the tagging documentation part of the wiki is humans only without using mechanical tools would therefore also help a lot. ;-)My own observation regarding the tagging list is that endless threads are much more annoying than the overall number of new subjects opened.  So having as a guiding principle the rule not to post more than two or three replies on the same subject could be useful.  It would encourage everyone to contemplate their replies more thoroughly and not engage in back-and forth two person dialogs - for which this kind of mailing list with a large number of subscribers is not really the ideal place.-- Christoph Hormannhttp://www.imagico.de/___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting - changing table

[Valor Naram]

Hey,

I am encouraging you to vote for the Proposal at https://wiki.openstree
tmap.org/wiki/Proposed_features/changing_table a second time. I'm in
hope to get that approved.

I want to see your choices.

Best regards

Sören alias Valor Naram

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

Re: [Tagging] Feature Proposal - RFC - changing table - self referencing description

[Valor Naram]

Did it, see https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing table - self referencing descriptionFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: sent from a phone> On 27. May 2019, at 04:42, Warin <61sundow...@gmail.com> wrote:> > Almost agree :)> > "A surface for replacing the nappy (diaper) of an infant or young child"> > Might remove the "young child" for brevity?> > Martin?I agree with Joseph‘s wife, as it is about a property. Young child could be removed, typically children get rid of their nappies at around 1,5-3 years, this is perfectly covered by „baby“Cheers, Martin ___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 - changing table - self referencing description

[Valor Naram]

Did ithttps://wiki.openstreetmap.org/wiki/Proposed_features/changing_table"A place for replacing the nappy/diaper of very young children." Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing table - self referencing descriptionFrom: Warin <61sundow...@gmail.com>To: tagging@openstreetmap.orgCC: On 25/05/19 17:15, Valor Naram wrote:> Hey all,>> something else that needs to be discussed/improved before starting the > second voting?>https://wiki.openstreetmap.org/wiki/Proposed_features/changing_tableKey:baby_changing_table Definition: Provides a place for changing the nappy/diaper of babies or young children.Pedantic hat on.Self references:babies ... plural  of babychanging - repeated'Provides' not needed.--- What I would do?Delete Provides.Change 'changing' to 'replacing'delete 'babies' and add description to young children of 'very'Key:baby_changing_table Definition: A place for replacing the nappy/diaper of very young children. ???___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 - changing table - self referencing description

[Valor Naram]

Hey all,something else that needs to be discussed/improved before starting the second voting?CheerioSören alias Valor Naram Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing table - self referencing descriptionFrom: Valor Naram To: "Tag discussion, strategy and related tools" CC: Ok. Changed itSee https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing table - self referencing descriptionFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: Am Do., 23. Mai 2019 um 10:52 Uhr schrieb Valor Naram <valin...@gmx.net>:I have changed the description for the proposal at https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table as suggested.current description reads: "Provides the infrastructure for changing the nappy/diaper of babies or young children"I think this is too inclusive, to me it would suggest that everything that is needed will be provided (like in the german drugstore example, they provide tissue, nappies, a sheet of paper underneath, disinfectant for the parents). What should be described is the minimum. IMHO this is a horizontal surface suitable to change a baby, i.e. sufficient light should be provided, wind should be shielded, possibility to wash your hands would make perfectly sense but is not always available). If this is a property, the description could be as simple as "provides a place to change a baby's nappy".Cheers,Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Investigation between iD developers and OSM community

[Valor Naram]

Hi guys,

I can do the investigation process ( https://lists.openstreetmap.org/pi
permail/tagging/2019-May/045523.html ). It may be helpful when you
concentrate on the purpose for which the thread "iD adding
highway=footway to all railway/public_transports_platform ways and
relations" ( https://lists.openstreetmap.org/pipermail/tagging/2019-May
/045462.html ) was created. You drifted far away from the threads'
topic. I also noticed that the purpose of the original thread ("solving
iD conflict" is NOT the original thread) has been forged. It has been
manipulated/forged to fit in the emotion costume but it should have
been lead to a objective discussion with searching and providing
solutions in order to solve the problem.

If you want an investigation for clearing things out, I will do that.
But I won't use this mailing list for that.

Cheers

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

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

[Valor Naram]

I could try to investigate and I am neutral because I don't have an opinion on that topic yet. You have just to say it and I will prepare an investigation like pointing out my role in this process and some other things that needs to be done beforehand.Great wishes bySören alias Valor Naram Original Message Subject: Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)From: Nick Bolten To: "Tag discussion, strategy and related tools" CC: This is a pretty good example of some of that unhelpful behavior I mentioned...There is a toxic habit that's far too common on this mailing list to speculate about bad intentions and then state them as if they are fact. It serves no purpose other than to divide and denigrate and has no place in a community-oriented project.On Fri, May 24, 2019, 4:55 AM Paul Allen <pla16...@gmail.com> wrote:On Fri, 24 May 2019 at 09:56, Simon Poole <si...@poole.ch> wrote:
  

  
  I think if you investigate, you will find that invariably such
  complaints (including the predictably, invariably going to be
  used,"toxic"), originate with people that didn't get their way, or
  associates of them ("didn't get their way" as in: there was a
  substantial body of opinions that disagreed with what ever they
  were proposing). And some of those people will then go on to say that a particular forum [where nobody agreed withthem, because everybody else is marching out of step] needs to be replaced with a different type of forum.  A moderated forum.  It is never explicitly stated, but may be inferred, that they'd like those moderators to be people who agree with them, or for they, themselves, to actually be the moderators.For bonus points, they may state (without providing names or evidence) that people on the forum accuse them of acting in bad faith.  Which may be true, even though I don't recallseeing that particular accusation on this list while I've been here.  Or it may be subtlypoisoning the well: those who disagree with me are obviously acting in bad faith because theyaccuse me of acting in bad faith [but no evidence of such accusations is provided].-- Paul
___
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] Feature Proposal - RFC - changing table - self referencing description

[Valor Naram]

Ok. Changed itSee https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing table - self referencing descriptionFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: Am Do., 23. Mai 2019 um 10:52 Uhr schrieb Valor Naram <valin...@gmx.net>:I have changed the description for the proposal at https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table as suggested.current description reads: "Provides the infrastructure for changing the nappy/diaper of babies or young children"I think this is too inclusive, to me it would suggest that everything that is needed will be provided (like in the german drugstore example, they provide tissue, nappies, a sheet of paper underneath, disinfectant for the parents). What should be described is the minimum. IMHO this is a horizontal surface suitable to change a baby, i.e. sufficient light should be provided, wind should be shielded, possibility to wash your hands would make perfectly sense but is not always available). If this is a property, the description could be as simple as "provides a place to change a baby's nappy".Cheers,Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki for documentation, ML for discussion | Re: solving iD conflict

[Valor Naram]

When I came to OSM I started mapping my house number. Then I don't participated for 3 years until I came back and I hadn't had any problems of whom to ask. I edited something and then iD lead me to the "OSM_de" group on Telegram. Original Message Subject: Re: [Tagging] Wiki for documentation, ML for discussion | Re: solving iD conflictFrom: Kevin Kenny To: "Tag discussion, strategy and related tools" CC: On Fri, May 24, 2019 at 10:20 AM Rory McCann  wrote:> Isn't this a case of using the wrong t̶o̶o̶l̶ community for the task?> The mailing list are for discussion. We have help.openstreetmap.org for> Q, and the wiki for documentation. "The ML makes a poor documentation"> well yes of course it does?>> Did someone point you to the tagging ML to answer beginner questions? I> agree that's not a good suggestion.We've already identified resource discoverability as an issue. I was abeginner, and we don't really make it easy for a beginner to find outwhom to ask. "Tag discussion, strategy and related tools" seemed aplace where such a question would be on topic. I already mentionedthat I'd read the Wiki. I also have extensive prior experience in howWikis work, so also read the talk page and consulted Overpass to get afeel for whether the Wiki article reflected actual practice. From thecontentious talk page and the fact that I found no examples in about a100-km radius of where I was mapping, I arrived at the wrongconclusion about the acceptance of the tag.In any case, I think the experience that the tagging ML was the wrongtool for that job is a key observation. The presents and taggingrecommendations in iD are essentially the aggregation of answers to agreat many beginner questions - it is, after all, supposed to be anentry-level tool. Just as that single question didn't elicit arelevant answer, a large number of similar questions, in theaggregate, are likely not to get relevant answers. Just as the taggingML is unfit for the purpose of answering a single beginner question,it's unfit for the broader purpose of answering many such questions_en masse._ It doesn't have to be characterized as 'toxic' or'hostile,' simply 'irrelevant to the task at hand.'  iD'srecommendations should reflect broadly accepted current practice, andthis mailing list is not a good place to discover what that is.___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

[Valor Naram]

> +1, though it would be tricky to find someone both interested in doing this, with time to do that, and not already involved in a poor wayI can do that but I am not quite sure about my social skills. But I will take it seriously as I always do when I am moderating or organising.CheersSören alias Valor Naram Original Message Subject: Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)From: Mateusz Konieczny To: CC: "Tag discussion, strategy and related tools" 
  

  
  
23 May 2019, 18:32 by o...@westnordost.de:reverse this development.Yes, it would be great. There is plenty of negative emotion on both sides and itwould be great to reverse this (for example title that I used was frankly stupidwhat I realized after sending the message).I had to rewrite this last paragraph several times, but, well, I hope this does not come across the wrong way...it can certainly not continue like this, so ... why not interview him, honestly and with open outcome, how should the collaboration and communication in OSM happen in the future from his point of view? Would he rather feel relieved or rather feel betrayed if the gatekeeping (~deployment) is done by other people? Does he really feel alienated (because I assumed it) from the community and if yes, why? And most importantly, what would it take to reverse this?+1, though it would be tricky to find someone both interested in doing this, with time to do that,and not already involved in a poor way  

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

Re: [Tagging] Feature Proposal - RFC - changing table - self referencing description

[Valor Naram]

I have changed the description for the proposal at https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table as suggested. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing table - self referencing descriptionFrom: marc marc To: tagging@openstreetmap.orgCC: Le 23.05.19 à 01:03, Warin a écrit :> https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table> 'self referencing description'> So what is a better description for OSM use?> "an aid to replacing human, usually babies, nappies/diaper"someone in the profession pointed out that there is no adult table,even in a specialized environment, I don't see the pointin keeping a confusion in the description.proposal:an infrastructure adapted to change nappies/diapers for babiesor young children___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 - changing table

[Valor Naram]

Yes, right. Sry for this. I learnt that "floor" means "Flur" in german language. Seems to be incorrect. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing tableFrom: Michael Brandtner via Tagging To: tagging@openstreetmap.orgCC: Michael Brandtner 
I think that this is a language issue and the hallway (German "Flur") is meant, not the floor.





Am Dienstag, 21. Mai 2019, 03:11:32 MESZ hat marc marc  Folgendes geschrieben:



Hello, > https://wiki.openstreetmap.org/wiki/Proposed_features/changing_tablequestions / minor suggestions :in changing_table:location=room what's the usecase of :"or the floor to the toilets" ? maybe just drop it.if someone wants to put their child on the floor, I don't see howwe could describe that this floor is adapted but not this other onethe first sentence of the tagging paragraph is about the rational (why some other existing tag doesn't fit the need),drop or move it to the rational paragraphRegards,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] Feature Proposal - RFC - changing table

[Valor Naram]

then it's a property Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing tableFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: Am Mo., 20. Mai 2019 um 12:36 Uhr schrieb Valor Naram <valin...@gmx.net>:> [...] so if you intend to replace this, yours would likely become a property (only) as wellOk. Does it matter? From what I understood so far most wiki pages describe `properties` e.g.: Key `highway`the difference of a feature and a property is that a property cannot be tagged alone, it requires a feature (e.g. "surface", or "oneway", or "height"). On the other hand, a feature is defining a "thing", e.g. a highway defined through the tag "highway". It is not a property, but a feature (and the values are different "classes" of this feature).OSM does actually not explicitly make this distinction (AFAIK), but it is implicit in how people are using the tags.Cheers,Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - changing table

[Valor Naram]

> [...] so if you intend to replace this, yours would likely become a property (only) as wellOk. Does it matter? From what I understood so far most wiki pages describe `properties` e.g.: Key `highway`CheerioValor Naram alias Sören Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing tableFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: Am Mo., 20. Mai 2019 um 11:00 Uhr schrieb Valor Naram <valin...@gmx.net>:> From what I understand, the tag seems to be intended as a property only (requires a "feature" to add to), right?It intends to deprecate the diaper key which is currently used for tagging changing tables. To be precise, the page first pretends to be either tagging "changing tables" or "separated rooms" (I guess it should be "separate rooms"?), but the way the tag is structured it is the presence of a changing table that is tagged, not the table itself. Then the diaper key is defined as a property ("in combination with..."), so if you intend to replace this, yours would likely become a property (only) as well"A key for diaper changing tables
 or separated rooms (sometimes known as a parents room) include a 
nappy/diaper changing table; in combination with toilets, shops, 
restaurants, service areas or something like that."Cheers,Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - changing table

[Valor Naram]

> From what I understand, the tag seems to be intended as a property only (requires a "feature" to add to), right?It intends to deprecate the diaper key which is currently used for tagging changing tables. I will deprecate the key for some reasons:- Key `diaper` is poor documented- Key `diaper` didn't go through the proposal process- Key `diaper` does not support shematic tagging- Key `diaper` leads to confusion of what it intends to tag- Key `diaper` does not allow us to tag changing tables inside a restroom for wheelchair users- Its subkey `diaper:wheelchair` is used but not documented yet and its meaning remains unclear. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing tableFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: Am Mo., 20. Mai 2019 um 07:07 Uhr schrieb Valor Naram <valin...@gmx.net>:What do you mean with "feature"? Do you mean the whole proposal? Do you mean the "feature" subtag ( changing_table:features )? "feature" is referring to whatever thing you are intending the tag for, or "property" if it is intended as a property for some other "feature".I see you have now added "A tag for tagging changing tables." ,which is fine, I found the former, generic description "A tag to mark the possibility to change the baby's nappy." confusing, and would suggest to remove it (because "a possibility to ..." is much broader in meaning than just a changing table).From what I understand, the tag seems to be intended as a property only (requires a "feature" to add to), right?Cheers,Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - changing table

[Valor Naram]

What do you mean with "feature"? Do you mean the whole proposal? Do you mean the "feature" subtag ( changing_table:features )? Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing tableFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: sent from a phone> On 19. May 2019, at 20:31, Valor Naram  wrote:> > I have rewritten my proposal to hopefully please the critic. Please check it out: https://wiki.openstreetmap.org/wiki/Proposed_featu res/changing_table> > Author: Valor Naram> Definition: A tag to mark the possibility to change the baby's nappy. It makes tagging of changing tables possible. See https://en.oxforddict ionaries.com/definition/changing_table for the definition.IMHO you should provide a definition for the feature in the proposal and be explicit if this is for a “possibility to change the baby’s nappy” or more specifically a “changing table”. Cheers, Martin ___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - changing table

[Valor Naram]

Hey guys,

my first proposal has been rejected for some reason. I have rewritten my 
proposal to hopefully please the critic. Please check it out: 
https://wiki.openstreetmap.org/wiki/Proposed_featu res/changing_table

Author: Valor Naram
Definition: A tag to mark the possibility to change the baby's nappy. It makes 
tagging of changing tables possible. See https://en.oxforddict 
ionaries.com/definition/changing_table for the definition.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - changing table

[Valor Naram]

Hey guys,

my first proposal regarding changing tables were rejected because of
being "too complex". I will give it a second chance and provide you
with the v2.0 of it: https://wiki.openstreetmap.org/wiki/Proposed_featu
res/changing_table

Author: Valor Naram
Definition: A tag to mark the possibility to change the baby's nappy.
It makes tagging of changing tables possible. See https://en.oxforddict
ionaries.com/definition/changing_table for the definition.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Valor Naram]

The voting process ended with 13 votes. This proposal has been rejected with 9 voices approval and 4 voices denial. While there are more yes than no votes, the amount of approval votes are under the 74% mark. Original Message Subject: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Valor Naram To: tagging@openstreetmap.orgCC: Definition: A tag to mark the possibility to change the baby's nappy Proposal page: https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tablesPlease join the discussion and I will spend time to make changes.CheerioSören alias Valor Naram
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting - (changing table)

[Valor Naram]

Hi there,


Definition: A tag to mark the possibility to change the baby's nappy
Author: Valor Naram


the discussion has been closed by me and we can vote on my proposal.
Please give me your voice at https://wiki.openstreetmap.org/wiki/Propos
ed_features/changing_table so we can get rid of the `diaper` key. I am
quite excited about seeing the vote results.

Keep going

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

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Valor Naram]

Did it.See http://wiki.osm.org/wiki/Proposed_features/changing_table Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: bkil To: "Tag discussion, strategy and related tools" CC: I recommend that we rename the proposal to the following:https://wiki.openstreetmap.org/wiki/Proposed_features/changing_tableThen we can create a redirect from the old URL so that all links mentioned in this thread and elsewhere will work indefinitely. Please verify that both the main page and the talk page redirects.On Mon, Apr 29, 2019 at 7:50 PM Valor Naram <valin...@gmx.net> wrote:> and that’s why the page is called “baby changing table”?Because someone noted that there exist changing tables for adults. But they're not widespread nor specified enough. No one has the knowleadge to implement it in OSM. But we didn't go further so we agreed on "changing_table" without the "baby" prefix. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: sent from a phone> On 29. Apr 2019, at 14:24, Valor Naram  wrote:> > where I explain there's no doubt of using "changing table" because it means what it means without confusion.and that’s why the page is called “baby changing table”?Cheers, Martin ___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
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] Feature Proposal - RFC - Baby changing table

[Valor Naram]

> and that’s why the page is called “baby changing table”?Because someone noted that there exist changing tables for adults. But they're not widespread nor specified enough. No one has the knowleadge to implement it in OSM. But we didn't go further so we agreed on "changing_table" without the "baby" prefix. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: sent from a phone> On 29. Apr 2019, at 14:24, Valor Naram  wrote:> > where I explain there's no doubt of using "changing table" because it means what it means without confusion.and that’s why the page is called “baby changing table”?Cheers, Martin ___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 - Baby changing table

[Valor Naram]

I will put an end to the discussion of the chosen name and will just link to https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/baby_changing_tables#Statement_from_the_author where I explain there's no doubt of using "changing table" because it means what it means without confusion. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Sun, 28 Apr 2019 at 09:20, bkil  wrote:
Our word for changing_table=* is something like "diaper changer
[place]" ("pelenkázó") or more like "a place where you change
diapers", the word itself weakly implicates a separate room, although
this should not cause confusion. Interestingly, the dictionary
definition suggests a translation "pelenkáz" = "changing the baby",
but the term itself does not narrow this down to babies and it is
applicable to all age groups.

Do you know a language where this could cause an issue for real?Magyar might be one.  :)  I have been led to believe that in Magyar the term for this facilityloosely translates as "diaper changer [place]."  I do not know what percentage ofHungarian mappers would infer, without looking it up, that "changing table" meant"diaper changer [place]."I would guess that any language that refers to such facilities by including that language's wordsfor "baby," "diaper," or "napkin" might have that problem.  In English, through common usage,we just use "changing table" but 20 years ago (when it wasn't common usage) I would have wondered what it meant and what was being changed (I still feel a little uneasy with it).-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Valor Naram]

I now splited the table into two parts so you can see how the wiki will look like (not equal)Seehttps://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables#Tagging Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Valor Naram To: "Tag discussion, strategy and related tools" CC: I've already made a suggestion to split the wiki pages into two parts:The first one describes the key "changing_table" as a replacement for "diaper". This section will compare the old tagging with the new tagging without introducing new subkeys.The second one describes the extensions (adding of more information which are fully optional to provide) Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: marc marc To: tagging@openstreetmap.orgCC: no:) (or more exactly: it has been said but I say it againin case you missed it)I notice that the page has almost doubled in size :(I wonder if you shouldn't split the proposal into two:a minimalist proposal that takes the rela data from the diaper=* tagand provides a better schema to encode it, an idea that I fully support.another proposal to promote all other information (fee: there are really paid changing tables in the free toilets ? presence of straps ora pillow: there is really a parent who will base his choice on this criterion ? changing_table:wheelchair:description:xx : there is reallya utility that a contributor describe in his own language that the changing table is inaccessible like all those I have seen ?maybe my experience is not diversified enoughfurthermore the proposal was based on the principle of harmonizing tags with what is done for other objects, but now it introduces inconsistencies (features=bench <> bench=yes for example)Le 25.04.19 à 19:16, Valor Naram a écrit :> There's no discussion concerning the proposal of "baby changing table" > anymore. What's happening? Should I start the voting process? Are all > words said?> > Answer "no" (with or without any reason) and I won't start the voting.> > > Cheers> > Sören alias Valor Naram> > >  Original Message > Subject: [Tagging] Feature Proposal - RFC - Baby changing table> From: Valor Naram> To: tagging@openstreetmap.org> CC:> > > *Definition:* A tag to mark the possibility to change the baby's nappy> *Proposal page:*> https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables> > Please join the discussion and I will spend time to make changes.> > Cheerio> > Sören alias Valor Naram> > > ___> 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] Feature Proposal - RFC - Baby changing table

[Valor Naram]

I've already made a suggestion to split the wiki pages into two parts:The first one describes the key "changing_table" as a replacement for "diaper". This section will compare the old tagging with the new tagging without introducing new subkeys.The second one describes the extensions (adding of more information which are fully optional to provide) Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: marc marc To: tagging@openstreetmap.orgCC: no:) (or more exactly: it has been said but I say it againin case you missed it)I notice that the page has almost doubled in size :(I wonder if you shouldn't split the proposal into two:a minimalist proposal that takes the rela data from the diaper=* tagand provides a better schema to encode it, an idea that I fully support.another proposal to promote all other information (fee: there are really paid changing tables in the free toilets ? presence of straps ora pillow: there is really a parent who will base his choice on this criterion ? changing_table:wheelchair:description:xx : there is reallya utility that a contributor describe in his own language that the changing table is inaccessible like all those I have seen ?maybe my experience is not diversified enoughfurthermore the proposal was based on the principle of harmonizing tags with what is done for other objects, but now it introduces inconsistencies (features=bench <> bench=yes for example)Le 25.04.19 à 19:16, Valor Naram a écrit :> There's no discussion concerning the proposal of "baby changing table" > anymore. What's happening? Should I start the voting process? Are all > words said?> > Answer "no" (with or without any reason) and I won't start the voting.> > > Cheers> > Sören alias Valor Naram> > >  Original Message ----> Subject: [Tagging] Feature Proposal - RFC - Baby changing table> From: Valor Naram> To: tagging@openstreetmap.org> CC:> > > *Definition:* A tag to mark the possibility to change the baby's nappy> *Proposal page:*> https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables> > Please join the discussion and I will spend time to make changes.> > Cheerio> > Sören alias Valor Naram> > > ___> 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] Feature Proposal - RFC - Baby changing table

[Valor Naram]

There's no discussion concerning the proposal of "baby changing table" anymore. What's happening? Should I start the voting process? Are all words said?Answer "no" (with or without any reason) and I won't start the voting.CheersSören alias Valor Naram Original Message Subject: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Valor Naram To: tagging@openstreetmap.orgCC: Definition: A tag to mark the possibility to change the baby's nappy Proposal page: https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tablesPlease join the discussion and I will spend time to make changes.CheerioSören alias Valor Naram
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Why should we avoid overusage of amenity=* tag?

[Valor Naram]

To your 4.: We need to get the developers to change their presets beforehand. Original Message Subject: Re: [Tagging] Why should we avoid overusage of amenity=* tag?From: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Wed, 24 Apr 2019 at 10:16, Valor Naram <valin...@gmx.net> wrote:Deprecating "amenity" would hurt because it's a very important key. But I have some suggestions:There are cases where amenity is an appropriate tag.  Such as for amenities. 1. Keeping the "amenity" wiki page intact.2. Creating/extending pages for new keys e.g. Key:education3. Suggesting "education=*" instead of "amenity=education" on the "amenity" wiki page.3.5 Persuading developers of editors to prefer education=* to amenity=* when mappersselect "school," "university," etc.  Many mappers rely on editor presets and will only over-ridewhat those presets offer if they disagree with the tags the editor gives them.4. A transition period for changing the database and to aware other mappers of it.4 is feasible ONLY if the new education=* offers are 1-for-1 correspondence withamenity=* for educational facilities.  That is amenity=school can be directly and unambiguously replaced with education=* (possibly with sub-tags).  There can beno "it depends" situations if a bulk edit is to take place.  Otherwise it would have to bedone on a case-by-case basis.-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Why should we avoid overusage of amenity=* tag?

[Valor Naram]

Good reasons were given here. I changed also my mind but there's the problem of how to deal with this problem.Deprecating "amenity" would hurt because it's a very important key. But I have some suggestions:1. Keeping the "amenity" wiki page intact.2. Creating/extending pages for new keys e.g. Key:education3. Suggesting "education=*" instead of "amenity=education" on the "amenity" wiki page.4. A transition period for changing the database and to aware other mappers of it. Original Message Subject: Re: [Tagging] Why should we avoid overusage of amenity=* tag?From: 石野貴之 To: "Tag discussion, strategy and related tools" CC: Thank you for the reply.> These difficulties, and opposing ideas on how to deal with existing tags, make it hard to change established tagging schemes. But I am strongly in favour of not establishing new amenity=* for hitherto unmapped facilites, but rather use new tags altogether, whose use can then be expanded into proper tagging schemes.I support your idea using new tags altogether with existing tags.Then, how about the following examples? Do you think them good ideas?   (a) office=educational_institution and education=cram-school for Japanese jukus aimed for entrance examinations.  (b) shop=computer and education=specialty if a computer shop provides a workshop to learn how to use computers.Takayuki Ishinoyumean1...@gmail.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Valor Naram]

It could be added to the "features" key as "adjustable_height" value. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: bkil To: "Tag discussion, strategy and related tools" CC: To aid those with achondroplasia, I think it would also be useful to indicate whether adjustable_height is a feature of the table, though I guess they are already prepared to use the floor anyway.On Mon, Apr 22, 2019 at 2:22 PM Paul Allen  wrote:On Mon, 22 Apr 2019 at 00:50, marc marc  wrote:
if the goal is to talk about accessibility, then use the wheelchair tag.That just says if you can get a wheelchair into the toilet. 
but if by measuring the height of the table, you think you have done 
what it's need to inform accessibility, you are wrong, this detail is 
almost anecdotal in accessibility.No more anecdotal than anything else anybody maps. for all the others, no need to have a meter in your pocket,
it's wheelchair=no, no need to fill heigh=1 or 1.05 or .95 except for 3DAnd how about those with achondroplasia?To be honest, I doubt many mappers would bother mapping the height and it'sprobably not all that useful in most situations.  But the fact that somebody heresuggested it means it is likely that somebody will decide to map the height, in whichcase let's decide how to do it now.
>     same thing for the description key, I can't imagine when it's useful to
>     describe the table with words so I find it not very useful to promote itSecurity through obscurity doesn't work.  As for promoting it or not, it depends very much onwhat editors offer in their presets.the question is "can we expect to have changing tables on a regular 
basis that are different from what we can expect with other tags,
which would justify encouraging people to put a description ?Actually, no.  It's can we expect it on an irregular basis.  Because description is only rarelynecessary for anything.
access=* don't said anything about public view.
changing tables in a private area does not mean that your child
is protected from a public view (I know a changing table in
the private part of the maternity just in front of a windows
with a public corridor)
a changing table in a public toilet can be in a room that
is respectful of privacy.
if you want to inform this kind of info, it's probably better
to make another proposal for another key in stead of promoting
to hijack the access key to talk about public view when using
the feature.I already suggested that in private mail  to Valor for other reasons.  The developers ofsome editors don't like re-using keys with a subset of values and remove such usage frompresets.  If offering the full list of values doesn't make sense they either have to hard-code theexceptions or refuse to implement it in a preset, and these days it's usually refusal.  And, asyou've pointed out, not only does the syntax differ (only a subset of values make sense) so doesthe semantics.  So changing_table:access would be better.-- Paul
___
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] Feature Proposal - RFC - Baby changing table

[Valor Naram]

I need to clarify the access=* key for my proposal to pleace this discussion.changing_table:access=yesThe changing table is accessible to the public. This means you can change the nappy of your baby without being a customer. This happens rarely.changing_table:access=noThe changing table isn't also accessible for the customers. We should leave this value anyway because parents don't have any doubt of asking. It applies also for rooms for which you need a key.changing_table:access=customersThe changing table is only accessible for customers. This is a value that applies to most POIs.changing_table:access=permissiveThe use of the changing table is accessible to the public but access can be revoked at any time for just one or few individuals while some are allowed.In fact: We can delete this subkey because the most changing tables in POIs are for customers only and permission of using it by others may be given out on a individual basic. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Mon, 22 Apr 2019 at 00:50, marc marc  wrote:
if the goal is to talk about accessibility, then use the wheelchair tag.That just says if you can get a wheelchair into the toilet. 
but if by measuring the height of the table, you think you have done 
what it's need to inform accessibility, you are wrong, this detail is 
almost anecdotal in accessibility.No more anecdotal than anything else anybody maps. for all the others, no need to have a meter in your pocket,
it's wheelchair=no, no need to fill heigh=1 or 1.05 or .95 except for 3DAnd how about those with achondroplasia?To be honest, I doubt many mappers would bother mapping the height and it'sprobably not all that useful in most situations.  But the fact that somebody heresuggested it means it is likely that somebody will decide to map the height, in whichcase let's decide how to do it now.
>     same thing for the description key, I can't imagine when it's useful to
>     describe the table with words so I find it not very useful to promote itSecurity through obscurity doesn't work.  As for promoting it or not, it depends very much onwhat editors offer in their presets.the question is "can we expect to have changing tables on a regular 
basis that are different from what we can expect with other tags,
which would justify encouraging people to put a description ?Actually, no.  It's can we expect it on an irregular basis.  Because description is only rarelynecessary for anything.
access=* don't said anything about public view.
changing tables in a private area does not mean that your child
is protected from a public view (I know a changing table in
the private part of the maternity just in front of a windows
with a public corridor)
a changing table in a public toilet can be in a room that
is respectful of privacy.
if you want to inform this kind of info, it's probably better
to make another proposal for another key in stead of promoting
to hijack the access key to talk about public view when using
the feature.I already suggested that in private mail  to Valor for other reasons.  The developers ofsome editors don't like re-using keys with a subset of values and remove such usage frompresets.  If offering the full list of values doesn't make sense they either have to hard-code theexceptions or refuse to implement it in a preset, and these days it's usually refusal.  And, asyou've pointed out, not only does the syntax differ (only a subset of values make sense) so doesthe semantics.  So changing_table:access would be better.-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] diaper subkey for wheelchair toilets including a changing table

[Valor Naram]

 changing_table:location=unisex_toilet;wheelchair_toilet Original Message Subject: Re: [Tagging] diaper subkey for wheelchair toilets including a changing tableFrom: bkil To: "Tag discussion, strategy and related tools" CC: Well, the place I had in mind only had a unisex toilet - a single, unsegregated entrance with possible multiple booths. In this case, the two are equivalent. If there exist two entrances: one unisex and one wheelchair, then it is reasonable to differentiate the two.On Mon, Apr 22, 2019 at 12:27 AM marc marc  wrote:Le 20.04.19 à 00:36, bkil a écrit :
> Is it correct that nappy_changing:location=toilets is equivalent to 
> nappy_changing:location=unisex?

not really, having a changing table somewhere in the toilet area doesn't 
give any information about whether these toilets are unisex or not
___
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] Feature Proposal - RFC - Baby changing table

[Valor Naram]

+1 I agree with Paul Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Sun, 21 Apr 2019 at 22:56, marc marc  wrote:
however I wonder if it's useful to promote changing_table:height
is there really any use for this tag ?A parent in a wheelchair might find that useful information, although it would only influence adecision if there were similar facilities nearby.
same thing for the description key, I can't imagine when it's useful to 
describe the table with words so I find it not very useful to promote itDescription is a standard tag applicable (at least in theory) to all objects and used wherethere is something that distinguishes the object from others in its class or where it differssignificantly from what might otherwise be expected.  It's rare that I use description=* forany object, but occasionally it is useful.
I also ask where a changing_table:access=private or =no may be usefull
I think the reasoning used for toilets should also apply to equipment 
such as a changing_table: if it is totally private, such as the changing 
table in your home bathroom, it is not necessary to add in osm.Some people may feel uncomfortable changing their baby in public view.  Especially ifa down-market tabloid newspaper recently fuelled fear of paedophiles to boost itscirculation.
even access=permissive seems strange to me for this kind of equipment,
I don't know of any law instituting a right to the changing table, so 
all those who are access=yes are access=permissive because their
owner has the right to change their mind without asking someone elseNot sure about this one.  There are all sorts of fine distinctions.  A cafe might have a changingtable for use by customers, or may permit non-customers to use it if they ask.
changing_table:location=dedicated_room
if the purpose is to change the key diaper=room to diaper=yes + 
diaper:location=dedicated_room I think this value is an too precise 
assumption. the few changing tables I met in a room separate from the 
toilets were not in a dedicated room. it was often in the room with
the sinks, the entrance hall of the different toilets or in a 
multi-purpose room.If you never encountered a changing table in a dedicated room then don't map it as such.I have no problem with future-proofing a proposal.  Because eventually somebody will encountera changing table in a dedicated room and wonder how to map it.  Let's decide on a sensible way ofdoing it now rather than regretting we had not done so after somebody invents an ad-hoc way oftagging it.
since this proposal is to replace an existing key, it is useful
to make a short list of current usage and their new key/valueGood point. 

don't be afraid of the suggestion list, they are only suggestions to 
discuss in order to try to make the proposal as useful as possible.Don't say that!  You/ll make us seem warm and cuddly.  I've worked hard over many decades toappear curmudgeonly.-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Valor Naram]

The name of the key has been changed to "changing_table"
On Sat, 2019-04-20 at 17:12 +0200, Valor Naram wrote:
> Definition: A tag to mark the possibility to change the baby's nappy 
> Proposal page: https://wiki.openstreetmap.org/wiki/Proposed_features/
> baby_changing_tables
>
> Please join the discussion and I will spend time to make changes.
>
> Cheerio
>
> Sören alias Valor Naram
> ___
> 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] Feature Proposal - RFC - Baby changing table

[Valor Naram]

> Here are some alternatives, do share your concerns with each:: )1) I am not on the same opinion concerning the name "nappy_changing" or something like nappy:1.1. We've had heard about changing tables for adults hence the name "baby_changing_table" in order to distinguish between changing tables for changing nappies of babies and changing nappies of adult. My idea is that a future proposal could easily adapt from mine. So a "adult_changing_table" key could co-exist with "baby_changing_table".1.2. We could of course name the key "baby_nappy_changing_table" or something like that but it think this would lead to clustering and therefore to the key being harder to remember. Keep it simple ( KISS ) is my devise.2)> nappy_changing_place=*> nappy_changing_table=*> nappy_changing_room=*I don't consider it as good practise. We have the possibility to add subtags and should take use of that. So "place" is a subtag and belongs to "nappy_changing" hence it should be named "nappy_changing:place". Syntax: ":". The same goes for the other two. See also my concerns about the use of "nappy" ( "nappy_changing_table" ) in section 1) of this mail.3)> ... same with _change_ in place of _changing_I could imagine using "change" instead of "changing" e.g. "baby_change_table", "baby_change_table:location", ... Maybe there are some more (different) opinions out there since this discussion is meant to improve my proposal. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: bkil To: "Tag discussion, strategy and related tools" CC: Here are some alternatives, do share your concerns with each:nappy_changing=*nappy_changing_place=*nappy_changing_table=*nappy_changing_room=*... same with _change_ in place of _changing_Some I do not like as much:changing_table=*change_table=*baby_table=*diaper=*diaper_table=*nappy_table=*On Sun, Apr 21, 2019 at 2:07 AM Warin <61sundow...@gmail.com> wrote:
  

  
  
+1 for starting it.
  
  Think the name could be better .. sounds like a baby exchange :)
  
  On 21/04/19 04:59, bkil wrote:


  
  Thank you for taking the time to complete this nice
write up. I obviously support the proposed scheme. ;-)


I don't have strong feelings about the exact naming of the
  used key, as I mentioned previously.
  
  
  
On Sat, Apr 20, 2019 at 5:14
  PM Valor Naram <valin...@gmx.net> wrote:


  
Definition: A tag to mark the possibility to
  change the baby's nappy 
Proposal page: https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables


Please join the discussion and I will spend time to
  make changes.


Cheerio


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

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




  

___
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] Why should we avoid overusage of amenity=* tag?

[Valor Naram]

I agree since "amenity" is a good tag and there are many different types of facilities available. In my view introducing an own key for each possibility would be messy.Leaving it how it is now seems the best. Future proposals should just add a value to the "amenity" key Original Message Subject: Re: [Tagging] Why should we avoid overusage of amenity=* tag?From: Mateusz Konieczny To: "Tag discussion, strategy and related tools" CC: 
  
  
Apr 21, 2019, 3:55 AM by yumean1...@gmail.com:I think that our discussion about these tagging schemes is in very slow progress. In my opinion, a proposal on a new tag like amenity=educational_services is more effective rather than shifting to educational=* tagging schemes.I agree. Note that there are many people with conflicting opinions about how taggingshould work and how it should be changed.For example I see no problem with many features using amenity key.In some cases there are groups of people with completely opposing opinions and itis impossible to please both of them.  

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

[Tagging] Feature Proposal - RFC - Baby changing table

[Valor Naram]

Definition: A tag to mark the possibility to change the baby's nappy 
Proposal page: https://wiki.openstreetmap.org/wiki/Proposed_features/ba
by_changing_tables

Please join the discussion and I will spend time to make changes.

Cheerio

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

Re: [Tagging] diaper subkey for wheelchair toilets including a changing table

[Valor Naram]

Then wait for me. It will take me some time to write a proposal. Original Message Subject: Re: [Tagging] diaper subkey for wheelchair toilets including a changing tableFrom: bkil To: "Tag discussion, strategy and related tools" CC: It is perfectly acceptable to come up with better tagging for established things and deprecate the old one, if we also invite downstream users from the start of the process (anyone?).I didn't recall commenting on the talk page but looks like I had pretty good arguments. To accommodate rooms, perhaps we could use nappy_changing=yes. Its scheme would then be:1) If both toilets are mapped as a separated node:amenity=toiletswheelchair=designatednappy_changing=yesamenity=toiletswheelchair=nonappy_changing=no2) if both toilets are mapped as a single node:amenity=toiletswheelchair=yesnappy_changing=yesnappy_changing:location=room/toilets/female_toilets/maie_toilets/wheelchair_toilets3) if toilet that belongs to an amenity or a building doesn't have it's own object, for ex with a bar:amenity=bartoilets:wheelchair=yesnappy_changing=yesnappy_changing:location=room/toilets/female_toilets/maie_toilets/wheelchair_toiletsOther possible tags:nappy_changing:for="">nappy_changing:capacity=nappy_changing:fee=*nappy_changing:access=*nappy_changing:height=*nappy_changing:vending/dispensing=nappies;rash_cream;powder;wet_wipe;gloves;hand_sanitizer;pad;motrin;tylenol;...nappy_changing:services=bench;shelf;potty;pillow;pad;...Is it correct that nappy_changing:location=toilets is equivalent to nappy_changing:location=unisex?On Fri, Apr 19, 2019 at 11:20 PM Michael Brandtner via Tagging <tagging@openstreetmap.org> wrote:
I’m not a native speaker but I don’t think there will be any confusion when using changing_table. I don’t know of any changing tables for adults outside of nursing homes. In case of need we can add changing_table:for="">Am Freitag, April 19, 2019, 11:06 PM schrieb marc marc <marc_marc_...@hotmail.com>:I encourage you to make a proposal if you want.in reality the problem #1 is that some members of the community are very cautious when there is a 1:1 change proposal to replace a bad "not-low-usage" key with a new better key, including those who have never filled one of this object in osm nor used the data about this object :(Maybe your proposal will pass sucess due it is changing one keywith several others.the problem of existing applications (there are only 4 reported on taginfo) is not a problem. it is possible to ask it to support the 2 keys for 1 month and to make a mass edition in the middle of the month. but here again the problem is the timidity of some membersthe small question that remains, should the key be called baby_changing_table or changing_table? some people talkedabout adult tables (I have a little trouble imagining an adulton a table). that could avoid confusionLe 19.04.19 à 22:46, Valor Naram a écrit :> You (Warin) and marc marc made some suggestions on how to improve this > key. I also found a workaround for the problem of> >  > [r]eplacing the key `diaper` with `changing_table` [or some other key > or by any other changings how to tag changing tables] without or with > the consens of the others of the community would hurt apps like AndOSM > and other platforms working with the `diaper` key e.g. Babykarte.> > I will write a proposal or should I first discuss my ideas with you instead?> > Cheers> > Sören alias Valor Naram> > >  Original Message > Subject: Re: [Tagging] diaper subkey for wheelchair toilets including a > changing table> From: Warin <61sundow...@gmail.com>> To: tagging@openstreetmap.org> CC:> > >     On 19/04/19 05:21, Paul Allen wrote:>>     On Thu, 18 Apr 2019 at 19:54, Valor Naram <valin...@gmx.net>>     valin...@gmx.net>> wrote:>>>>>>         https://wiki.openstreetmap.org/wiki/Proposal_process#Proposal_list>>         guided me to you. I have the following situation: I want to tag a>>         changing table but this changing table is in the toilet room for>>         wheelchair users. The page at>>         https://wiki.openstreetmap.org/wiki/Key:d>>         iaper states tagging for changing tables is just available in>>         toilets>>         for women,-men and unisex but not in toilets for wheelchair users.>>>>>>     At first glance I thought you wanted to tag places where people in>>     wheelchairs>>     could change their own diapers.  Then I checked with the wiki page and>>     realized what you mean.>>>>     And then I realized diaper=* is not a good idea for a key.  In>>     British English we call>>     them nappies (singular nappy), not diapers.   And what the toilet>>     has is not a supply>>     of nappies (diapers) but

Re: [Tagging] diaper subkey for wheelchair toilets including a changing table

[Valor Naram]

You (Warin) and marc marc made some suggestions on how to improve this key. I also found a workaround for the problem of> [r]eplacing the key `diaper` with `changing_table` [or some other key or by any other changings how to tag changing tables] without or with the consens of the others of the community would hurt apps like AndOSM and other platforms working with the `diaper` key e.g. Babykarte.I will write a proposal or should I first discuss my ideas with you instead?CheersSören alias Valor Naram Original Message Subject: Re: [Tagging] diaper subkey for wheelchair toilets including a changing tableFrom: Warin <61sundow...@gmail.com>To: tagging@openstreetmap.orgCC: 
  
  
On 19/04/19 05:21, Paul Allen wrote:


  
  
On Thu, 18 Apr 2019 at 19:54, Valor Naram <valin...@gmx.net>
  wrote:


  

https://wiki.openstreetmap.org/wiki/Proposal_process#Proposal_list
guided me to you. I have the following situation: I want to
tag a
changing table but this changing table is in the toilet room
for
wheelchair users. The page at https://wiki.openstreetmap.org/wiki/Key:d
iaper states tagging for changing tables is just available
in toilets
for women,-men and unisex but not in toilets for wheelchair
users.
  
  
  
  At first glance I thought you wanted to tag places where
people in wheelchairs
  could change their own diapers.  Then I checked with the
wiki page and
  realized what you mean.
  
  
  And then I realized diaper=* is not a good idea for a
key.  In British English we call
  them nappies (singular nappy), not diapers.   And what
the toilet has is not a supply
  of nappies (diapers) but a CHANGING TABLE.  Which is what
you described it as,
  because that's what it is.  And had the key been
nappy_changing_table instead of diaper
   I wouldn't have (briefly) misunderstood what you wanted
to tag (a changing table in
  a toilet for wheelchair users, not a place where
wheelchair users can change their
  own nappy).

  


+1 ... change table! 

Wheelies (wheelchair users) also use catheters with bags. Much
easier to deal with compared to a diaper. 


  

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

Re: [Tagging] diaper subkey for wheelchair toilets including a changing table

[Valor Naram]

So you suggest to change the wiki via proposal? Then we have a problem which we should also be aware of. I quote myself:> Replacing the key `diaper` with `changing_table` [or some other key or by any other changings how to tag changing tables] without or with the consens of the others of the community would hurt apps like AndOSM and other platforms working with the `diaper` key e.g. Babykarte. Original Message Subject: Re: [Tagging] diaper subkey for wheelchair toilets including a changing tableFrom: marc marc To: tagging@openstreetmap.orgCC: Le 19.04.19 à 10:28, Valor Naram a écrit :>  > [...] documented values are mix of how many, what and where.> > Can you explain me in other words what do you mean please.check https://wiki.openstreetmap.org/wiki/Key:diaperexemple 1 diaper=yes  okexemple 2 diaper=number of changing tables -> it's "how many"exemple 3 diaper=bench  it's the quality of the infrastructureexemple 4 diaper=room it's the localisation (in another room)so the meaning of the diaper value is a mix, sometime the capacity, sometime the quality, sometime the localisation.if someone wanted to fill in all this information,it would be better to divide it into several tagsfor exemplediaper=yes / no / limited (for the bench or any other poor qualityof the infrastructure)diaper:capacity=number of changing tablesdiaper:location=where it's located > `diaper:wheelchair` is already in useyes but :wheelchair is often used to describe the accessibilityof a feature. :wheelchair=yes is not the same meaning a location=*___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] diaper subkey for wheelchair toilets including a changing table

[Valor Naram]

> And then I realized diaper=* is not a good idea for a key.But it is widely used (https://taginfo.openstreetmap.org/search?q=diaper#keys) and the only key I know for the purpose of tagging changing tables. I also discovered that my suggestion `diaper:wheelchair` is already in use (but not documented yet).> And what the toilet has is not a supply of nappies (diapers) but a CHANGING TABLE.I agree with you! I also wondered about this but I accepted `diaper` for this purpose. So what do you suggest? Replacing the key `diaper` with `changing_table` without or with the consens of the others of the community would hurt apps like AndOSM and other platforms working with the `diaper` key e.g. Babykarte. Original Message Subject: Re: [Tagging] diaper subkey for wheelchair toilets including a changing tableFrom: Warin <61sundow...@gmail.com>To: tagging@openstreetmap.orgCC: 
  

  
  
On 19/04/19 05:21, Paul Allen wrote:


  
  
On Thu, 18 Apr 2019 at 19:54, Valor Naram <valin...@gmx.net>
  wrote:


  

https://wiki.openstreetmap.org/wiki/Proposal_process#Proposal_list
guided me to you. I have the following situation: I want to
tag a
changing table but this changing table is in the toilet room
for
wheelchair users. The page at https://wiki.openstreetmap.org/wiki/Key:d
iaper states tagging for changing tables is just available
in toilets
for women,-men and unisex but not in toilets for wheelchair
users.
  
  
  
  At first glance I thought you wanted to tag places where
people in wheelchairs
  could change their own diapers.  Then I checked with the
wiki page and
  realized what you mean.
  
  
  And then I realized diaper=* is not a good idea for a
key.  In British English we call
  them nappies (singular nappy), not diapers.   And what
the toilet has is not a supply
  of nappies (diapers) but a CHANGING TABLE.  Which is what
you described it as,
  because that's what it is.  And had the key been
nappy_changing_table instead of diaper
   I wouldn't have (briefly) misunderstood what you wanted
to tag (a changing table in
  a toilet for wheelchair users, not a place where
wheelchair users can change their
  own nappy).

  


+1 ... change table! 

Wheelies (wheelchair users) also use catheters with bags. Much
easier to deal with compared to a diaper. 


  

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

Re: [Tagging] diaper subkey for wheelchair toilets including a changing table

[Valor Naram]

> imho diaper is a little ugly [...]Why?> [...] documented values are mix of how many, what and where.Sry, can't follow you. Can you explain me in other words what do you mean please. Original Message Subject: Re: [Tagging] diaper subkey for wheelchair toilets including a changing tableFrom: marc marc To: tagging@openstreetmap.orgCC: Le 18.04.19 à 20:53, Valor Naram a écrit :> I want to tag a changing table but this changing table> is in the toilet room for wheelchair users.imho diaper is a little ugly : documented values are mixof how many, what and where.if I wanted to fill this in as precisely as you do,I would do it like this :1) If both toilets are mapped as a separated nodeamenity=toiletswheelchair=designateddiaper=yesamenity=toiletswheelchair=nodiaper=no2) if both toilets are mapped as a single nodeamenity=toiletswheelchair=yesdiaper=yesdiaper:location=wheelchair_toilets3= if toilet that belongs to an amenity or a building doesn't have it's own object, for ex with a baramenity=bartoilets:wheelchair=yesdiaper=yesdiaper:location=wheelchair_toilets___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] diaper subkey for wheelchair toilets including a changing table

[Valor Naram]

Hello there,

https://wiki.openstreetmap.org/wiki/Proposal_process#Proposal_list
guided me to you. I have the following situation: I want to tag a
changing table but this changing table is in the toilet room for
wheelchair users. The page at https://wiki.openstreetmap.org/wiki/Key:d
iaper states tagging for changing tables is just available in toilets
for women,-men and unisex but not in toilets for wheelchair users.

My question is: Is there any possibility to tag a changing table in a
toilet for wheelchair users similiar or equal to
'diaper:wheelchair="yes"' I didn't find such specification at https://w
iki.openstreetmap.org/wiki/Key:diaper or it exists but isn't documented
yet. If such tagging doesn't exist, I will write a proposal for you to
discuss and vote on.


Cheerio

Sören alias Valor Naram.

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