I’m currently developing a little project that uses overpass to query for certain features in an area - as a result during development I’m spotting a number of repeated tags (with different spellings)/multilingual entries/odd entries/variations on multiple entry delimiters etc etc - I’m a little reluctant (at present/and until im comfy with OSM in general) to use JOSM (or whatever tool is appropriate for fixing them up) myself - but I was wondering if there was anyone who’s really on top of/obsessed with fixing tags that I can email the errant tags to as I find them (well in batches so as not to be annoying). Alternatively if taghetti is classified as a bug you can just point me to the most appropriate bug-reporting tool and I’ll log them in there for approval/rejection.
As you might know, OSM has a free tagging system, everybody can come up with her own tags. This makes it sometimes hard to tell whether something is just a typo or it was the actual intention.
There is no good way to change large batches of “wrong” tags. We have the mechanical edit process, but that has its limitations.
The best methods are to do a survey, make sure that you understand the intention and fix the tag. Or you could contact the previous mapper. Both are lengthy processes.
Some people advise that you “prepare” the data before you actually use it. In that case you have to write your program so that it takes care of the different spelling mistakes or that you make a local copy of the database on which you run a number of scripts to fix the data in the way you want.
Or you could just ignore the mistakes, make sure your webapp / app becomes popular, so it becomes an incentive for mappers around the world to correct the wrong tags.
People like Marc Zoutendijk have been reporting strange tags. There is also a tool new keys that picks up those “strange” keys.
So we prefer local people to change the tags above mechanical edits. If you want to contact someone, try writing a comment on the changeset that introduced the problem. There is not “someone to email”, sorry.
Great thanks I’ll have a ponder on the best way forward - I think it might be fixing them up my end - I’ve noticed (for instance) that beachvolleyball (as one word) is a sport where I’d expect it to be either broken into two words(beach_volleyball) or sport=“volleyball”, surface=“sand” since there’s no real requirement for the court to actually be on a beach! so I think some thought needs to go into it my end!! The end game is of course to make the app successful and pipe back any corrections!
In general it’s better to post-process tag variants than to ‘correct’ them directly. Too many ‘corrections’ remove information, often because the editor is remote from the local community & is unaware of local conventions or idiosyncrasies. Also an automated correction does not involve the original mapper in the loop and thus the same tag usage may continue for new entries.
The worst example of autocorrection I can recall was an edit which converted all (or nearly all) aeroway=* values to aerodome. Prior to that we had airport, aerodrome & airstrip. With a single value we still have a problem of identifying significant airports easily. Under the old tagging this would have been simpler.
If using a database its fairly simple to have a table to look-up values and map them to a consistent term.
Also note that in most cases there is a long tail of values but something like 95-99% will be the widely used ones. When this is not the case it usually means that local conventions have been adopted and a synthesis of different tags has not been carried out: we had this in the UK with betting shops: shop=betting,bookie;bookmaker;bookmakers;gambling etc.
Other examples from retail, the store chain John Lewis mainly run department stores, but to correct all their stores to shop=department_store would be wrong. They have a small shop mainly selling gift items on one or more London stations and at least two stores which mainly sell furniture & household wares.
