OSM Phone Number Validation has added a test for the use of phone and contact:phone [1] on an object at the same time.
In this post @dieterdreist wondered if that is actually an error which caused me to wonder as wel.
So, what do you folks think about that.
My initial thought: It might be not a real error but is is undesirable, there is a risk that the keys go out of sync.
All results I have seen are for the same number ↩︎
Think Osmose flags this combo if the numbers are not the same. I could imagine a business has a regular number and a number for customers to call… the contact:phone, so I’d expect them to be different.
Who calls that “regular” number?
If both numbers are identical it’s an error and one of the tags can be removed
Using both phone and contact:phone on the same object. Is that an error?
no, it is a double-tagging (see also people adding healthcare=pharmacy to amenity=pharmacy
note: there were repeated attempts to deprecate either phone or contact:phone - attempts in either direction were rejected
If both numbers are identical it’s an error
no, it is not
OSM Phone Number Validation has added a test for the use of phone and contact:phone on an object at the same time.
(I am the author of the tool)
The test is rather for duplicate numbers in general, whether in the same tag or different tags (across phone, contact:phone, mobile and contact:mobile). My “suggested fix” is to remove the number in the less common tag.
no, it is a double-tagging
Perhaps there is a subtle difference between double tagging and duplicate tagging.
It is the same thing, as far as I know.
Difference is what is implied about situation.
Do you mean the difference between “Contact the feature at this number that belongs to it” (phone=*) versus “Contact this number about the feature” (contact:phone=*)? For some mappers that seems to be essentially the difference between addr:housenumber/street=* and contact:housenumber/pobox/street=*, but not for social media keys as far as I can tell.
I meant difference between “duplicate tagging” (suggesting that one of tags should be removed) and “double tagging” which does not make such implication or makes it less strongly.
OK, I see what you mean here and I agree with that.
It might be me not being a native English speaker but this does not make sense to me. As Jarek has said “Who calls that ‘regular’ number”. And as both forms of the key are used individually probably a lot more the difference between “regular” and contact kind of disappears.
That looks to me like “forcing” towards a specific key while neither of them are deprecated (phone: de facto, contact:phone: in use). As I understand the situation at the moment, which key is used is more or less decided by the mapper’s preference. (JOSM has presets for both versions).
As neither phone nor contact:phone mention they are to be used for fixed/POTS phones, they simply say “a phone number”. It looks to me like having a mobile phone number in the phone version of the key is not wrong.
As for having the same number in (contact:)phone and (contact:)mobile it is a bit redundant but probably not wrong. I would not do it when creating a new item but I would also not see both being used as a reason to edit the item.
So for me reporting identical numbers in the contact and plain versions of the keys is not a metric I am interested in.
P.S. The phone and contact:* wiki articles mention different “formats” ( ITU-T E.164 and DIN 5008 respectively)
regular > switchboard main number, contact > call centre/customer service. Come to think of it, they can be equal too, simply a website (most all here) have a contact link which then lists out email, facebook, cs, Could easily give the same number.
Yes, that’s a mess I’ve been trying to clean up for the last few years. Whoever documented that DIN 5008 is the format for phone numbers in OSM must’ve assumed that it’s an international standard, but in fact it’s only a standard for German-language publications in Germany (and possibly some other German-speaking countries). As such, it’s incompatible with real phone numbers in a good chunk of the world, let alone other standards in English. The documentation sometimes causes unaware mappers to mangle valid numbers into invalid ones.
E.123 is an actual international standard, but it’s still intended for print matter, particularly business cards and letterheads. That creates problems for machine readability, particularly when extensions are involved.
That’s why I mentioned addr:housenumber/street=* versus contact:housenumber/pobox/street=* earlier. Two different addresses can apply simultaneously: one is intrinsically assigned to the POI/door/building/parcel and useful for wayfinding, and the other is useful for contacting the POI. But phone numbers are different. No one navigates to a POI based on its phone number… right? 
I think there are two possible scenarios:
The numbers are identical in both keys. Some people will think that one of the two can be deleted, while others will think that this is pointless since both are correct. In both cases, this does not pose a problem in practice as long as it remains this way, since both are correct.
The two numbers are different, and this is ambiguous: are both numbers valid? It would be clearer with key=number1; number 2. Or did a contributor add the second number because the first one is incorrect? It is impossible to know, which is the problem with having duplicate tags when one of the two changes. I think we should review these cases to avoid this ambiguity and put both numbers in one tag if both numbers are valid, or delete the old number that was not deleted when the new number was added.
And so, to reduce the risk of this happening, it is useful to go back to the previous case and also delete duplicate numbers, even if it is not an error, but simply because it may cause an error when the number changes.
If this view is shared, editors, especially web editors, would gain in ergonomics by merging the two fields, regardless of the original tag. Given that the difference in meaning between somes contributors is impossible to guess from the data, these two tags are synonymous for data users anyway, and these nuances between contributors are unusable.