OpenStreetMap
Earlier this week, I accepted a PR to our codebase that made a bad and duplicated phone numbers. What happened was, that we use contact:phone=* per convention, but many entries used phone=*, which was not detected by our dupe scanner.
That’s 100% on me. I should have been more vigilant on that one, should have checked better (the few I checked on did not have phone=, so that’s another lesson for the books), and should have checked more vigilantly afterwards as well.
What I did: wrote a rescue to check all 600 edits we did, removed phone= dupes, and moved all phone= that were still there to contact:phone= in the process.
We also do contact every albergue we list (and thus sync) and ask them about their preferred/working phone numbers. So we went ahead and removed stale numbers that no longer worked, and updated those that did to a fully working set.
Of course the code is now fixed as well, and all edits have been too. Sorry again, this is 100% on me.
Discussion
Comment from DaveF on 20 January 2026 at 22:05
Why were you changing phone=, perfectly valid & popular tag to contact:phone=, which has be shown to be totally pointless, adding no quality to the OSM database & requiring the same amount of post processing as with all the other communication tags such as email, website etc?
What is you “codebase”? you make no mention of it?
DaveF
Comment from BeardMD on 21 January 2026 at 09:26
In the last few OSM meetups I attended, both in Spain and Germany, the majority were speaking in favor of structured tagging (x:y=) over flat tags (x=/y=) for a number of reasons. My main reasons for it are hierarchical taxonomies and processing hierarchies.
I do respectfully disagree on the “no quality” - structure is quality. Personally, I am not a huge fan of ambiguous tag defs, which I argued in 2019 and 2020 if you recall, but here we are. We have three options: leave everything as is (not a fan), adapt the 52% of Spain albergues with contact:phone= to phone= or adapt the 48% to contact:phone=.
Currently I am aware of three efforts to enrich Spanish albergue data: the Xunta in Galicia, the Consellos in Navarra, and Ultreia. Xunta uses MapComplete (which uses contact:phone
~.+), the Consellos use a mix, and we’ve been using contact:phone since pretty much the early days of Camino Now.Comment from DaveF on 21 January 2026 at 19:05
Phone/website/email=* is structured & grouped based on their shared characteristics.
Contact:= is no more classified than Phone/website/email=
Contact:= is not a “parent-child” structure.
Just as much processing is required to extract data using Contact:= as with Phone/website/email=*
I find it concerning that those within OSM who claim to write code fail to understand how to work with data & write code.
Comment from BeardMD on 22 January 2026 at 01:20
Ad hominems aren’t making the world a better place, Dave.
contact:phone differentiates in this case with and from emergency:phone and provides a clear, human and machine readable designator. I don’t even think you need to be a coder to understand that contact:* brings processing advantages.
Binomial nomenclature, if the separator is reserved (as it is here), makes not only sense in code. Consider instagram= vs. contact:instagram= - the latter should not point to the Instagram profile page, but provide contact access. The same is true for threads/contact:threads, etc. It does make sense to differentiate.
And, again, we can fight against things like MapComplete, which does default to contact:phone= or accept (or even, as I do, welcome) the rise of the minority tag. That doesn’t mean I’ll go ahead and auto-scrub (which would go against anything I stand for, see the discussion on banning automated and semi-automated editing), but where phone numbers change, Facebook gets added, WhatsApp gets added, etc. I’ll probably continue to send edits with contact information as contact:= while adding POI information/profile pages as facebook:= and so on.
A good way to look at this is the coming W structure. euroW=url/profile, contact:euroW=user-address-hash, which can not be directly derived from the profile name. Or Fediverse. fediverse=instance_url != contact:fediverse=@user@some_other_instance.
That discussion is as old as the 2018 discussion, which ended in “The proposal “Deprecating ‘contact:phone’ in favor of ‘phone’ tag” has been rejected by community members with 61 oppose votes, 46 approve votes and one comment. 107 people voted in total.”