How to document tagging mistakes on wiki (undocumented duplicated tags)?

Help and support Tagging help & support
,
1

For example I’ve stumbled upon undocumented camp=* tag, which seems to be created mostly in in one huge import; while there exists more organically-grown and documented camping=*, which is probably the tag users might want to use.

Thus, I’ve added {{PossibleSynonym2|camp}} on camping=* wiki, and that part works OK.

I’m not however sure how to document (previously undocumented) Key:camp so people could be pointed to correct place if they happen upon it (e.g. via taginfo wiki section or elsehow). I’ve added {{Deprecated}} template to it, but I’m wondering is that is the best way to handle it?

I’ve also found Tagging Mistakes - OpenStreetMap Wiki but I’m not quite sure how I should use it (or if I even should?)

Any other wiki editors with a suggestion? Pointers to docs? Thanks!

1 Like
2

Is it the same thing? https://overpass-turbo.eu/s/1t9c suggests e.g. refugee camps in Haiti. I wouldn’t do anything to suggest it’s a synonym of anything until you’ve got to the bottom of what it means.

2 Likes
3

I would at least contact importer and ask in changeset comment have they intentionally used a different tag.

I would also consider asking others - depending on usage scale and tag count ether on some local community chat or here in a separate thread or in tagging mailing list.

In some cases proposing retagging bot edit may be helpful, in some cases it could be reverting an undiscussed import or edit that added it.

If you have trouble with tracking down people who use this tag - feel free to ask for help.

+1 (from my experience it is better to investigate too much than not enough, though I also documented many tags as deprecated without say full scale proposal and voting and several months of discussions)

2 Likes
4

I think there are a lot of rare tags that mean five different things. For example, I stumbled upon building=gate the other day. I went into a rabbit hole of checking a few dozen on Overpass and found some that could be tagged as gatehouses or guardhouses, others monuments, yet others were airport gates. I’ve wondered how to document my findings, because creating a Wiki page that lists all of these usages without a warning could lead others to use the tag, thereby reinforcing the current situation. I think I’m just going to leave a note at the affected airports (definitely the odd one out) and let experienced airport mappers sort it out.

1 Like
5

Initial imports (at least most of it?) seems to be tracked down by Haiti location and source=CCCM to:

Humanitarian OSM Team/Haiti Strategy And Proposal/Missions commonalities/Preparation activities - OpenStreetMap Wiki and Humanitarian OSM Tags/Humanitarian Data Model - OpenStreetMap Wiki

However, that data model does not describe camp=*, and indeed initial node creations did not have that tag, but it seems to be added later on (mass?) edits on those source=CCCM (and other HOT-related Haiti earthquake response sources) nodes initially imported. It all happened almost instantly according to that taginfo graph, even if multiple(?) edits are the reason.

I don’t seem to find it at https://wiki.openstreetmap.org/wiki/Import/Catalogue either when searching by Haiti or by source. But then again, that page did not exist until 2012, so that is probably to be expected.

Yes, I’d like help with that; my overpass-fu is not up to the task and manually checking them one by one does not seem to work too well. I’ve sent few discussions manually, but there are surely more.

I’ve documented possible uses I’ve found so far on that page (and plan to update as I find new information).

I’m not sure what would be the right page template to use (i.e. is there some better solution then my current mishmash of {{Deprecated}} and {{Ambox}}) to mark such undocumented ambiguous tags with multiple possible meanings, and warn users not to use that tag for new taggings, instead pointing them to other tags that might be better choice for thing they are trying to accomplish?

Such template or example page might also help @osmuser63783 with documenting what they’ve found, lest all that work is lost for nothing. It would be IMHO much preferable to document it, even if such documentation is not perfect, as it will save time for others.

3 Likes
6

Added to https://wiki.openstreetmap.org/wiki/Key:camp - feel free to delete that table if not wanted (done with script, not pure overpass)

I can also share list of all changesets, not just such summary (if useful)

It seems something Osmose related, and as Osmose is quite bad at QA[1] I would ignore it

[1] many, many pointless and meaningless complaints, a lot of false positives - including ones reported and ignored, unlike what JOSM developers are doing

7

Yes, this is certainly post-earthquake mapping probably with fixed objectives over a short-time frame and many tags were used for the first time. The ones around Jacamel were imported by Wonderchook, former executive director of HOT and former chair of the OSMF board. Many others were obviously carried out by people involved in the Haiti activation, but who were no longer active on OSM at the time of the licence change. Additionally the original HOT tagging proved cumbersome and in many cases was simplified, it is quite conceivable that some context got lost in the process. Many of the items assigned to jaakkoh (who IIRC lived in Haiti for a time) were just him tidying up.

The earliest reference I can find on the talk-ht mailing list is this cc’ed message from Mikel Maron (current OSM board director @mikelmaron) . Given the context I presume camp=* was used here for IDP Camps. The data model was proposed concurrently mainly by Nicholas Chavent who had already worked with the UNHCR model. In the context of data imports during the Haiti activation they got done as quickly as possible and even if an import catalogue existed I doubt if anyone would have paid any attention. You can see this by scanning the mailing list for February 2010.

There are also more recent instances around Goma, again by context fairly clearly intended for IDP camps, as are the ones in Cote d’Ivoire and the solitary one in Kenya.

Only the element in Brazil does not seem to fall into this class, and this looks like a false friend with campo.

In general this looks like a boolean value to identify things tagged with other primary tags (landuse=residential, amenity=school) as an IDP camp. The description under IDP Camp does say that tagging has not been defined for various aspects, so I suspect suggesting to find another tag or deprecation is not particularly helpful. More seriously, these elements represent transient data from over 13 years ago. Unfortunately revisiting them really requires some on-the-ground knowledge, which for Haiti is challenging.

The action which needs to be taken in engaging with people in HOT who may be able to identify how many of these still exist.

3 Likes
8

Thank you. To be honest with you, that page is not what I’m trying to accomplish.

The first thing I see is a blanket warning “Using this tag is discouraged, use refugee_site instead”. I don’t think this is appropriate for any tag that has more than one meaning: it directly contradicts the idea expressed a few sentences below that some people who used it may have meant camping=* or tourism=camp_site instead. (You wouldn’t want a tourist campsite to be tagged as a refugee camp.)

“Do not use this tag for new tagging” is very strong language. It goes agains the “any tags you like” spirit that many of us cherish about OSM.

“Who added this tag?” in combination with “Do not use this tag” is even worse: these people could be beginners. If I saw my own username on a list like that I would really be put off editing OSM.

Can we not use more neutral, less judgemental language like:
“The most popular way of tagging camp sites is X. The most popular way of tagging refugee camps is Y. Please consider using one of them as it is less ambiguous.”
“Examples of how the tag is currently being used:”

1 Like
9

Thanks for the investigation. This reads accurate to me in all regards. I do anticipate many of these elements are transient, but also some of these IDP camps may have changed into permanent housing. More recent satellite imagery as we have with our standard sources would probably confirm this. HOT might have some insight, but as you say, getting on the ground insight is especially challenging in Haiti right now.

1 Like
10

I agree, currently it is definitely not. What I’m hoping though, once it is finished (where it will look quite different than now), that it will be usable for your case too. My goal is also for it to be somewhat like disambiguation page, by noticing that the current tag is undefined, that it is ambiguous, and then list meanings that it was used for (and alternate tags which would cover same or similar tags as people using it might’ve used instead)

The first thing I see is a blanket warning “Using this tag is discouraged, use refugee_site instead”.
”. I don’t think this is appropriate for any tag that has more than one meaning

Yeah, I absolutely agree. That one is not what I wanted, but is temporarily there. If you look at the start of the thread, I’m looking for a template (or a combination of them) that creates infobox on right side with taginfo etc, and which adds a warning that the tag is not recommended (As its meaning is ambiguous).

Unfortunately closest one I was able to find so far is {{Deprecated}}, which has unwanted requirement to also recommend other tag. Hopefully I’ll find (or someone will recommend!) better template that doesn’t do that.

“Do not use this tag for new tagging” is very strong language. It goes against the “any tags you like” spirit that many of us cherish about OSM.

I don’t think it is too strong, read below for an argument why I think it is appropriate.

I like ATYL as much as the next guy, but note that it refers only to non-existent tags. So you may invent a new tag and give it a meaning. However, if one fails to verify that this tag that they’ve just invented doesn’t exist yet, especially if the wording of the tag is popular word, you run a very high risk of running afoul of ATYL principles and run over someone else’s toes.

For example, ATYL does not allow me start tagging bird houses as building=house, as that tag already has a different meaning. In short, ATYL is “first come first served” - whoever invents the name and use that tag name first in practice lays eternal (but see below) claim to it. (which is incidentally why it is great idea to immediately document tag you’ve invented via ATYL on the wiki, to reduce chance of such clashes).

Failing to follow those steps will results exactly in what have happened here and in your case - same tag being used for completely different things, in the end leading to “burned” tag which can practically no longer be used by anyone, as for whatever purpose you intended to use it, no data consumer will be able to know what it actually means (as there are multiple conflicting definitions).
One way to fix that is to contact all the people who have used this tag, find out what they meant exactly, and replace (at least all-but-one definition) of those tags with other more accepted values. Other way to fix it is to manually go surveying all those locations and re-tag them. Both are cumbersome - but until some of them are completed (if ever), the “burned” tag should really not be used for new taggings, as it will just create more noise and not add data.

That is definitely not meant to be some kind of “hall of shame”! It is a temporary list of people that @Mateusz_Konieczny has created on my request to help me find all the people I need to contact (see above). As soon as I contact them, the list will be gone, be assured!

Can we not use more neutral, less judgemental language like:

Absolutely, and thanks for good suggestions! :heart: I’ll work on that over next few days as I work on gathering data and cleaning it up. I hope when that page is done, it might be useful as a template for your case too. I hope you’ll it will be much different and much better than current temporary experimental work in progress.

11

Use regular infobox and just set status as deprecated?

It is also possible to move it to a different page - or even just delete it and check it in history of page as you make notifications.

Or add some disclaimer or better explanation that makes clear that use of tag was well-intentioned but lack of coordination caused problems.

12

In writing that I was aware that some of this period is becoming OSM prehistory, we perhaps need to document some of these key periods in more detail so that it stays as history. :wink: