Talk:Key:contact:*

From OpenStreetMap Wiki
(Redirected from Talk:Key:contact)
Jump to navigation Jump to search

Other tags that are already in use

User:Emka 19:10, 10 June 2009

Yes. I use 'phone' rather than 'contact:phone' because that's what most other mappers do. This is no coincidence. It's simpler. I generally disapprove of most proposals to introduce "namespaces". While they have the feel of something nice and rational and organised, that comes at a price. Tags are supposed to be simple. We're not developing a programming language here. New mappers have to learn to type these things in and remember them. The 'contact:' prefix offers very little real benefit but makes a tag much less simple.
(Copied from my diary I realised I should post this here)
-- Harry Wood 10:21, 25 August 2011 (BST)
Yes you are right, I also don't use the contact:-prefix, but afaik it is pushed by the JOSM default preset-template. --Fabi2 04:40, 17 March 2012 (UTC)

Types of phone numbers

What do you think about tagging various types of phone numbers? Like mobile phone (or cell phone), fixed phone or sip phone for example. I thought:

  • contact:phone:fixed=1234
  • contact:phone:mobile=1234
  • contact:phone:sip=1234@567.com

--Dirk86 15:12, 4 March 2010 (UTC)

I like it, especially mobile phones are in wide use and are often given together with a fixed phone number.--Scai 09:20, 22 September 2010 (BST)
Drowning in colon characters. How about good old simple tags like phone=* ...and maybe mobilephone=* ? -- Harry Wood 11:38, 22 September 2010 (BST)

More than one phone number

When a business has more than one phone number, what's the best way to capture this?

  • adding a contact:phone for each number
  • including all phone numbers in contact:phone

Mafeu 12:58, 26 October 2010 (BST)

you can't add several identical tags, so probably something like contact:phone=phone1;phone2;phone3 --Richlv 19:45, 17 December 2010 (UTC)
Each business has several phone numbers...This is usually solved by a central phone number. (Wow. What a low level of problem solving). --Lulu-Ann 12:40, 21 December 2010 (UTC)


More than 1 phone,fax,mobile number is entered by adding a semicolon after the first number followed by the 2nd number, semicolon, 3rd number and so on. Of course we do not forget to preface phone numbers in OSM with the international prefix and a space, such as contact:phone=+39 123 456 7890;+39 123 456 7891;+39 123 456 7892.

SekeRob 09:15, 22 August 2022 (CET)

Webcam?

A webcam shall be a means to contact somebody? What are you planning, jumping up and down in front of the webcam, hoping to catch some attention? Lulu-Ann

I confirm. Webcams are normaly not a communication-channel--CMartin (talk) 17:37, 26 August 2014 (UTC)

There is nothing wrong with contact:webcam=*. A 1-way contact can still be considered an opportunity through which the POI may push information to us. Just imagine a YouTube account URL - you usually go through their gallery or subscribe instead of sending videos as a reply yourself through that channel. It becomes much easier to visualize if you think about this tag being present on a public camera mounted on a pole outside. -Bkil (talk) 23:30, 16 May 2024 (UTC)

Youtube has its own key (contact:youtube=*) and is a "social" video-sharing and communication platform and not a webcam. Even the look out of you window will provide you some information, which maybe useful. The intention of this prefix seems to be to provide information about bi-directional communication channels, and not listing provided (more or less) broadcast media channels. So it will be better to use a key such as webcam=*. --Fabi2 (talk) 12:05, 18 May 2024 (UTC)

I hope nobody streams their webcams over YouTube. I was not talking about that. Please reread my answer. Also, not all contact channels are bidirectional: Template:Contact:website is also similarly about gathering information - it may or may not contain a PHP contact form itself. A webcam installed at a ski resort on next to a viewpoint may help you decide whether there is enough snow or not. If you used webcam as the key, how could you signal whether using webcams is not allowed on premise? Traditionally, the noun form of a word is used as an access restriction (more rarely, in context of sold or repaired items). Another concept of OSM is refinement. One imaginary tag may state that sells=webcam;camcorder;telescope and another tag could refine what kind of webcams are sold, such as webcam=ip;usb;wifi. So it is not obvious by just looking at the key that it should be containing a URL pointing to the camera stream. It may not be the best key ever, but I'm still waiting for better suggestions. -Bkil (talk) 12:42, 18 May 2024 (UTC)

Even if you stream a still image with music or your favorite slide show via Youtube, it is still contact:youtube=* and not contact:webcam=*! --Fabi2 (talk) 15:24, 19 May 2024 (UTC)

additional forms of communication

i think we could add some more forms of communication:

  1. contact:skype
  2. contact:twitter
  3. contact:facebook

what's your opinion?

I agree. Gallaecio 19:52, 27 July 2011 (BST)
I certainly agree for the Facebook page. Must have. These are now often used instead of a Website home page. --Neil Dewhurst, Lyon France (talk) 08:31, 18 September 2013 (UTC)
I propose to add a social network VKontakte with key contact:vk --Cvb (talk)

Contact:name?

Many small shop is known by owners name, I think contact:name would be the best way to tag. --BáthoryPéter 11:14, 28 July 2011 (BST)

Isn't operator=* usable? --phobie m d 21:49, 28 July 2011 (BST)

Deprecate this tag family

Stats (taginfo) and usage (editors presets) show that the old tags without the prefix "contact:" remain more popular even after two years of coexistence. After a discussion on the tagging list, I suggest to deprecate this tag serie on the wiki and recommand the old but simple keys.--Pieren 22:13, 1 May 2012 (BST)

AGREE! for the reasons given in the discussion above -- Harry Wood 01:41, 12 September 2012 (BST)
I think it is useful to maintain the namespace setaside, but NOT for general mapping use; rather as a reserved namespace to support content transformation, that is "contact:phone" as a synonym for "phone" for data conversion purposes but not for user mapping purposes. To this end, suggest creating a bot to revise instances of "contact:phone" to "phone" where "phone" is not currently in use, and to highlight where both are present for manual resolution. This would also mean retiring this page and creating a few wiki redirects. --Ceyockey (talk) 15:39, 3 April 2015 (UTC)
So what was decided? Did this even go through a voting process or so? Dhiegov (talk) 12:10, 10 February 2019 (UTC)
The situation is largely unchanged: Keys without a contact prefix remain far more commonly used (and are being added in greater numbers, too, so it's not just existing tagging), but there are mappers who really like the contact prefix and would oppose a deprecation. As far as I know, no one has attempted to put the issue to a vote. --Tordanik 20:52, 14 February 2019 (UTC)
I made the first step and explicitly described at Wiki page that alternative is considered as preferable by mappers Mateusz Konieczny (talk) 12:57, 19 September 2019 (UTC)
I want to add, the popularity is not really a good argument for anything here. Its not likely most new tags are 'chosen'. People just use whats available in iD most of the time and iD does not use the contact:*=* shemeat all. If iD decides to use that instead that "popularity" graph would change as well over time in my opinion. Negreheb 15:00, 11 Februar 2021 (UTC)

format inconsistency with the key “phone”

See [1]

contact:housenumber / Bremen Schema / extended Karlsruhe Schema

I recently started to discuss to introduce the tagging-scheme contact:housenumber as the extended Karlsruhe Schema. The Discussion is here Talk:Addresses#conact:housenumber_.2F_Bremen_Schema_.2F_extended_Karlsruhe_Schema. --Cracklinrain (talk) 00:50, 20 June 2013 (UTC)

Review websites

I have seen a few mappers adding contact:[ yelp | tripadvisor | foursquare ] to businesses. IMHO these are not means of contact, instead these are review website. While I personally think that we do not need them in OSM at all, they certainly do not belong in the contact:* namespace. --Polarbear w (talk) 21:03, 15 September 2017 (UTC)

In a discussion on the Tagging list, adding those websites was discouraged by most contributors. They are not designed as means of contact to the businesses, and focus on individual reviews. They are seen as an instrument of search engine optimizers and spammers. --Polarbear w (talk) 19:50, 9 October 2017 (UTC)
Personally, id put 99% of the Facebook links I've seen in that category also. Even if you can technically contact the business through Facebook, its main purpose is to make the business look overly good and they use of a lot of the same SEO/spam tactics. Would something like Yelp qualify also? --Adamant1 (talk) 17:31, 24 January 2019 (UTC)

contact:website vs website

Is there any difference in meaning between contact:website and website tag? Mateusz Konieczny (talk) 18:52, 9 October 2017 (UTC)

Not in my opinion. It was just the attempt by some mappers to group "phone, fax, email, website" under a common key prefix. --Polarbear w (talk) 19:37, 9 October 2017 (UTC)
It might be splitting hairs, but I think there is a difference. To me, visiting a website doesn't qualify as "contact." Anymore then it would be if I stand outside of a business and look at the hours on their door (Maybe that's more to do with it being a bad tag though and not them having different meanings per say).--Adamant1 (talk) 17:26, 24 January 2019 (UTC)
Totally agree with Adamant1. --The knife (talk) 22:23, 30 July 2019 (UTC)
I also agree that contact:website makes tagging more complex, because it eludes to the differentiation of websites which include contact possibilities and those that don't. IMHO we should discourage the use of contact:website for this reason. --Dieterdreist (talk) 15:16, 19 September 2019 (UTC)

Deletion of older tags

I've seen a few people around that have deleted the older more widely accepted tags like phone=* and replaced them with these. It wasn't on a mass scale or anything, one person in particular did it a lot though, but there should still be something on this page about how its inappropriate replace the old tags with these ones. As they can coexist. Hopeful it will help the situation at least a little. I don't think banner at the top is sufficient enough. --Adamant1 (talk) 07:46, 28 December 2018 (UTC)

While it's unfortunate that we have two synonymous keys and I wish we could just finally decide which set of keys to use (it's been 10 years!), deleting them like that isn't really acceptable and a recipe for edit wars. Feel free to add something to the page. --Tordanik 20:14, 14 January 2019 (UTC)

contact:youtube?

Is it just me, or is it quite absurd to describe it as a contact method? Mateusz Konieczny (talk) 13:22, 19 May 2020 (UTC)

Just as absurd as contact:website, maybe more. --The knife (talk) 13:37, 19 May 2020 (UTC)
Just ignore it Mateusz, the "contact"-prefix is not about sense. Sooner or later it will disappear, if we simply do not use it. --Dieterdreist (talk) 14:42, 19 May 2020 (UTC)
contact:website in theory can work and link to a contact form - though it is basically never used in that way Mateusz Konieczny (talk) 16:05, 19 May 2020 (UTC)
It still makes sense in this respect. The extent and nature of contact:*=* isn't well-defined. You can comment on videos, reply to Community posts, (these 2 alone already make contact:youtube=* more directly contact=*-fiting than most contact:website=* tags you observe) and there will be a list of email address and links in the About section. Keys like contact:webcam=* (cf Talk:Key:contact#Webcam.3F could be worse than contact:website=* - there's usually not even any contact channel listed. We simply need to clarify how to use contact:*=*, *:website=* and *:url=*, etc. -- Kovposch (talk) 10:34, 20 May 2020 (UTC)

Addresses?

These tags IMHO are not about Addresses, let’s remove the group or find a better one.—-Dieterdreist (talk) 17:42, 1 October 2020 (UTC)

emergency phone number

Is there any way to include emergency numbers? Eg. the opening_hours of a vet are Mo-Fr 08:00-16:00, but in case of emergency you can call under phone number X. (Mabye contact:emergencyphone ?) --TBKMrt (talk) 07:45, 2 December 2020 (UTC)

I am not aware of any. There is emergency_telephone_code=* which has 90% values of "112" and might eventually apply, although the term "code" seems strange? Also it is not documented in the wiki. Some usage also for emergency:phone=* (4191 uses, undocumented but eventually suitable) and much less for emergency_phone=* (337 instances, undocumented but from the values it looks as if it could be suitable for your scope). From this short lookup it seems emergency:phone=* is the best available option. The contact prefix should be avoided unless you want to make everyone's life harder by using multiple keys with the same meaning. For completely there is also "emergency:contact:phone=*" with 115 uses and contact:phone:emergency with 106 uses, i.e. both combined are at 5% of emergency:phone=*. --Dieterdreist (talk) 09:03, 2 December 2020 (UTC)
@Dieterdreist: I really did not expect an answer that quickly so thanks for the quick reply!
@ emergency_telephone_code: I also thought about that code does not really sound as if it would fit the rest of contact:*
@ emergency:phone: I saw that one, but I honestly don't really like it since it's awfully close to emergency=phone and this is something completelly else. I thought about using the emergency key in general, but the key as such seems to be more in use for public emergencies (eg. fire_hydrant, life_ring, phone, siren).
Because of the existing mixes of contact, phone and emergency I would more tend to use emergency_phone as key even it does not have a huge ammount of uses. The reason simply is that it's name is short and descriptive and it would fit the rest of the contact key. So phone = contact:phone and emergency_phone = contact:emergency_phone. But after all I don't really mind the way how it is included.
Usecase would be this vet that has a public phone number for cases of emergency.
--TBKMrt (talk) 16:20, 4 December 2020 (UTC)
I don't know if this would help in any way. I checked/searched taginfo. If you want use a mix of contact & phone & emergency i found two schemes which people starts to use:
=> 115x emergency:contact:phone: https://taginfo.openstreetmap.org/keys/emergency:contact:phone#overview
=> 106x contact:phone:emergency: https://taginfo.openstreetmap.org/keys/contact:phone:emergency#overview
Additionally you could look to the values which are used for these both versions and look to the taginfo chronology tab to see if there is organic growth --MalgiK (talk) 17:00, 4 December 2020 (UTC)
@MalgiK: If possible I do not want to mix contact, emergency and phone with a colon as seperator. I agree with Dieterdreist that this is not really a good mix and should be avoided. --TBKMrt (talk) 23:39, 4 December 2020 (UTC)

LINE

In some countries LINE has already surpassed websites and phones as the main communication method. Please add an entry for it on this page. Jidanni (talk) 00:55, 3 April 2021 (UTC)

Which tag is used for it? Mateusz Konieczny (talk) 09:19, 3 April 2021 (UTC)
First of all you need to decide on contact:line=*'s format. https://taginfo.openstreetmap.org/keys/contact:line#values is very diverse. Nearly half the instance are contact:line=yes wrongly tagged from contact_line=yes on electrified=contact_line.
---- Kovposch (talk) 14:08, 3 April 2021 (UTC)

Internal phone extension number

Seemingly in https://wiki.openstreetmap.org/w/index.php?title=Key%3Acontact&type=revision&diff=1018526&oldid=1018525, a confusion between ITU-T E.123 and DIN 5008 was unintededly introduced for the internal phone extension number used by a company or facility using a PABX. There has also been discrepancy between the English article here and German one DE:Key:contact (also looks like misinterpretations, without reading Greman).

Formats:

At least for any value containing a ext term, Taginfo should be showing 455 phone=* (https://taginfo.openstreetmap.org/keys/phone#values) and 536 contact:phone=* (https://taginfo.openstreetmap.org/keys/contact:phone#values) instances.

I have edited the key:contact article itself here (https://wiki.openstreetmap.org/w/index.php?title=Key:contact&type=revision&diff=2145351&oldid=2067606) and Template:Map_Features:contact (https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:contact&type=revision&diff=2145357&oldid=2142699) to narrow down the scope, leaving key:phone which has no mention of this untouched for now. There's a slight possibility that tiny proportion of usage on phone=* and contact:phone=* may differ over this, notwithstanding the already highly varied formats (due to a lack of standard).

This was asked on https://help.openstreetmap.org/questions/61185/how-to-specify-extension-number-in-phone-and-contactphone and in Talk:Key:phone#Extension_numbers

-- Kovposch (talk) 20:58, 23 April 2021 (UTC)

NANP is just a numbering plan. There's no official standard for phone number formatting in the U.S. or Canada, and industry style guides differ, but the typical notations in order of prevalence are:

  • "555-1234" or "(555) 555-1234"
  • "555-555-1234", especially in areas with ten-digit dialing but increasingly everywhere because of mobile number portability
  • Stylized variants like "555.555.1234", "555/555-1234", and "555 555 1234" occasionally appear on signs, but they're commonly understood to be nonstandard

All these formats can be stylized in creative ways for memorability, for example the phoneword "55-KLICK" (555-5425). Extensions are typically written "555-1234, ext. 10", "555-1234 ext. 10", or "555-1234 x10". Otherwise, the three-digit area code, three-digit exchange code, and four-digit line number are always separated by something, and a space is rarely used as a separator. Approximately three Americans know that "-" is ever used as an extension delimiter anywhere in the world.

If OSM continues to prefer a global standard, then it should not be DIN 5008, which is designed for German-language publications and does not apply to foreign languages, let alone database input. We don't adhere to the rest of DIN 5008 by tagging height=10,8 or start_date=12.06.2021, but of course an editor or data consumer is free to format these values according to DIN 5008 for display to German users. From a practical standpoint, it's already difficult enough to get contributors to tag phone=* according to E.123 instead of the national conventions, so DIN 5008 would only exacerbate the problem. E.123 at least addresses internationalization, even if it unfortunately does so in a machine-unreadable way by allowing the "ext." to be localized. On the other hand, if OSM would like to devise its own standard that happens to match DIN 5008 but not E.123, then editors and data consumers would need to perform more frontend internationalization before that can be a reality.

 – Minh Nguyễn 💬 22:56, 12 June 2021 (UTC)

Addendum: The Canadian telecom industry prefers "1 555 555-1234" in areas with ten-digit dialing, but U.S. and Canadian authorities prefer "1-555-555-1234". [2] The full text of E.123 distinguishes between national and international numbers, allowing for national numbers to contain hyphens but calling for spaces in international numbers (with a diplomatically worded footnote observing that it may take some time for hyphens to go away in actual usage). By the way, Key:phone#Parsing phone numbers recommends that data consumers parse phone=* in a way that precludes DIN 5008 extension formatting (by ignoring hyphens). – Minh Nguyễn 💬 21:12, 13 June 2021 (UTC)
I've copied the syntax ascribed by RFC3966 to phone=* for reference (e.g., phone=+44 20 8452 7891\;ext=42) Bkil (talk) 19:04, 16 November 2023 (UTC)
@Bkil: RFC 3966 is a URI format. Should we really be lopping off the protocol and introducing an alternative to the longstanding escape sequence for multiple values? – Minh Nguyễn 💬 22:58, 7 March 2024 (UTC)
Okay, let's discuss this at Talk:Semi-colon_value_separator#Backslash_escape_sequence Bkil (talk) 10:17, 8 March 2024 (UTC)
All of the formats look confusing. Whitespace is not allowed in the IETF RfC. (But brackets, and full-stops are, aside from hyphens)
—— Kovposch (talk) 21:03, 9 April 2024 (UTC)
Yes, the RFC explicitly allows -, ., ( and ) as visual-separator. I tried to document the status quo of using space for separation, but my personal belief is actually to ditch the whole thing and use a fully standard and machine-processable format and display it in whatever way it is preferred in the locale of the user. Interestingly, I have actually lost one potential OSM contributor because he failed to subscribe to the notion that the phone number is posted in a specific format on the wall while he was supposed to know by heart another format that he needs to manually transcribe it in every time which also makes visual comparison between the two error prone. It seems this isn't always palatable even for a nerd. Bkil (talk) 21:34, 9 April 2024 (UTC)
@Bkil: I agree that a more structured, predictable format like RFC 3966 would be ideal if we were starting from scratch. But I don't think partially adopting a small part of RFC 3966 while ignoring the rest of the standard is the best solution. Maybe we could allow setting phone=* to a full tel: URI, and we could recommend that option whenever the phone number has an extension or other complication. Then it would be simpler for data consumers to look for a value that begins with tel: to parse and format the value differently. Meanwhile, the older format wouldn't need an answer for escaping semicolons and the like. Other contact:*=* subkeys already allow for dual formats. For example, contact:facebook=* can be either a user name or a full URL. Presumably only the full URL would be URL-escaped. – Minh Nguyễn 💬 22:15, 16 May 2024 (UTC)

OpenStreetMap has always been about targeting a best effort middle ground aiming to allow humans to be able to read tags. Regardless of how elegant your suggestion seems, we still need a shorthand notation that humans are expected to produce by heart. Percentile hex coding is just not going to cut it. I myself copy & paste the full URL of whatever website into the appropriate tag instead of bothering to visually search for the ID in the URL to extract it by hand (I also expect autolinking to just work on most data consumers vs. logic for rewriting IDs to URLs of all possible fields will incur a maintenance overhead). -Bkil (talk) 22:34, 16 May 2024 (UTC)

@Bkil: Yes, I was thinking of my suggestion as a compromise. In practice, virtually every number would continue to be written in (more or less) E.123 format for human readability, but a vanishingly small number of phone numbers requiring extensions or other complications could be stored as a tel: URI per RFC 3966. For various reasons, those exceptional phone numbers are currently unreadable to any data consumer today using off-the-shelf phone number formatting utilities, even with the \; syntax that you documented. But there are popular libraries for formatting tel: URIs, especially on the mobile platforms that are most relevant to this key. [3][4][5] – Minh Nguyễn 💬 03:16, 20 May 2024 (UTC)

What is the point of...

I've looked for a reason 'contact:' prefix exists. I may have skimmed over a valid suggestion as the only explanation came from someone who appears to be against this form of tagging: 'to group "phone, fax, email, website" under a common key prefix'.

I'm struggling to see a purpose in this. If someone wishes to do a scrape of the OSM database for 'contacts' they still have to filter further for 'telephone, website' etc to make any use of it.

Can anyone sell this key to me, or should it be recommended to be discouraged or even deprecated?--DaveF63 (talk) 20:44, 17 January 2023 (UTC)

Many peers and I wholeheartedly support the contact prefix. I know a lot of people who don't care. I don't personally know any who actually oppose it. Someone should find the canned answer I copy & pasted in the last few years on random wiki pages, but the gist is that two drawbacks if we left out the "contact:" prefix are that the term itself might clash with other overloaded uses for the same (such as sold items, specialty, repairs, etc.). The second one is that in case of some other contact keys, it may not be trivially obvious to everyone what a given key means without consulting a wiki, especially if it is not a full URL, but an ID instead. Tag genesis is free form and the main concepts are that don't use ones that might clash with others and that good ones should "stand on their own", i.e., a well versed OSM editor should be able to decide what each tag means by solely looking at the XML, not at the wiki. -Bkil (talk) 22:42, 16 May 2024 (UTC)
The only purpose of the contact=*-prefix is to eat up some additional CPU power and fill up some additional (now cheap) flash/disk space. There is a JOSM-templete, which pushed the usage of this prefix. contact:webcam=* is still my favorite key. Nobody known, if it is the contact of the operator, the owner or anybody else. Fabi2 (talk) 22:50, 16 May 2024 (UTC)
https://wiki.openstreetmap.org/w/index.php?title=Key:contact:*&oldid=213722 might be originally started for that, but now, prefixing SNS and IM services is a good idea. Don't want random names popping up for every new app. Proposal:Social media contact prefix
A specific example for your concern is contact:mobile=* , which is more numerous and clearer than mobile=* . Unless suffixing phone:mobile=* is sought, which is somehow mentioned in Key:phone#How_to_map while having only ~5k.
—— Kovposch (talk) 08:01, 17 May 2024 (UTC)
There a many keys, where you must look up in the wiki, to understand the meaning of them, such as service=*. Yes, keys should be self explaining in an ideal world. For IM and social media apps with "random" names this prefix may be useful, but for many listed keys, its adds no useful information, such as common keys like website=*, fax=*, phone=* or even webcam=*. --Fabi2 (talk) 12:31, 18 May 2024 (UTC)
It improves consistency if all of them have the same prefix, not just a random subset of them. Bkil (talk) 12:43, 18 May 2024 (UTC)
We should rename all keys to have the same prefix, as some users feel some type of "fragmentation" if keys like name=* does'nt look like ref=* or opening_hours=*. Key-name-consistency works best if the keys look like key:0001=*, key:0002=*, key:0003=*, ... ;-) --Fabi2 (talk) 15:35, 19 May 2024 (UTC)

If you can touch type, it doesn't really take any effort to type in the prefix. Novice or normal people are expected to fill in information on preset forms so they would have to neither type in, nor know about which scheme their underlying editor supports. Better database systems know how to tokenize repetition of keys so it can take exactly the same amount of space. -Bkil (talk) 23:32, 16 May 2024 (UTC)

I will now stop replying to trolling questions and ignore their respective author. Your last two reverts are also considered made in bad faith. -Bkil (talk) 19:28, 19 May 2024 (UTC)