Very often, some POIs have more than one phone number listed (such as land line and mobile, but two land lines happen as well). How should I map such condition? asked 01 Jun '14, 11:26 RicoElectrico edited 01 Jun '14, 11:27 |
3 Answers:
My instinctive answer, which seems to be used a bit according to taginfo, is to use "phone:XXX" where XXX qualifies the usecase ("mobile", "emergency", etc). You might want to tag the default phone twice, once with and once without the ":XXX" suffix. Taginfo shows a lot of other schemes are in use, such as "phone2" and "alt_phone", but I feel that they do not follow best practices for new tag creation. There is also "contact:phone" as a IMHO-superfluous synonym of "phone". answered 01 Jun '14, 22:07 Vincent de P... ♦ edited 01 Jun '14, 22:07 |
I also believe that the qualification of telephone numbers with "phone:XXX" would be the best. In such a case, the tag "phone" could be the telephone exchange and the identifiers "phone:customer-service" or "phone:order-board" pose a direct line in these departments. (Similar is possible for the departments of city goverment or a hospital) with best regards Thomas G.M. Mainka answered 09 Mar '15, 10:48 tgmm edited 09 Mar '15, 10:48 |
We have a local fire department with a separate after hours phone number for anything that isn't a 911 emergency. Should this be tagged phone:after_hours or perhaps something else? It would be nice if there was a single location where all these corner cases could be documented for standardization, at least for anyone taking the time to search for the solution of a case which already has a solution. Best Rgds, -H- answered 28 Apr '19, 03:54 HMWamboldt For a phone number that is only used during certain hours, perhaps a condiitional/opening hours style value could be used. See: https://wiki.openstreetmap.org/wiki/Conditional_restrictions Maybe something along the form of: phone:non_emergency=+n nnn nnn nnnn @ Mo-Su 00:00-08:00 (28 Apr '19, 15:54) n76 |
Looking at the number of these tags being used, I doubt this is accessible to the software parsing OSM data. Still, better than nothing - if we invent something better then it's no problem to catch and replace these automatically. (Well, some people don't even let you finish a sentence that contains "automated edit" :P)
Given this situation, if someone really wanted to catch any "other" phone numbers, they could probably just look for tags that have "phone" anywhere in the key