Unconventional tagging scheme from an application

General talk Tagging general discussion
1

I’m referring to the mappingbitcoin application [1], which allows for custom labeling (as well as a review system) of points of interest in OSM.

An application user, with OAuth authorization from their OSM account, can tag points of interest. The tagging follows the Google Maps places Types scheme [2], translated into the category and amenity OSM keys. For example [3]: category=culture, amenity=historical_place.

The map within the application displays an icon and the chosen type as a label below the name, on the card that opens when selecting the POI.

If an OSM user corrects the tags, the POI in the application is shown as if it were not labeled, so any other user of the application can relabel it, which could lead to an unintentional edit war.

In the Argentinian community, we’re in contact with the developer (or one of the developers) of the application through our Telegram group [4]. They told us that development is currently halted.

I’m starting this thread to raise this issue publicly and encourage opinions and suggestions for possible solutions.

[1] https://mappingbitcoin.com
[2] Place Types (New)  |  Places API  |  Google for Developers
[3] Node: ‪La Crypta‬ (‪13507338690‬) | OpenStreetMap
[4] ES:Argentina - OpenStreetMap Wiki

2 Likes
2

in such case existing users should be told that they use broken editor and should migrate to proper one - or (far less preferable!) stop editing

if they continue breaking data, the should be (even less preferable!) be blocked, to do this contact DWG

3

In general it would be great DWG not blocking the users but the editor. Not sure whether they have such methods, but might be useful.
Recently there was another editor uploading multiple times the same data.

1 Like
4

Drop an email to data@openstreetmap.org with as much detail as you can add, and we’ll see what we can do.

API level blocks are unlikely, but let’s understand the scale and nature of the problem first.

1 Like
5

Hi Gabriel, thanks for raising this here, it’s better in the open than in a Telegram thread.

One correction: we never said development was halted. We’re not actively pushing updates at the moment, but the app is maintained and we’re paying attention.

On the tagging itself, the category / amenity pairs come from a translation of the Google Places types that drives our own labels and icons. We’re happy to change it, and we’d rather be told exactly what to switch to than guess and break things a second time.

Specifically:
1: what should replace our category=* key, or should it simply be dropped on upload
2: for the types that have no clean OSM equivalent, is the preference amenity=* values from the wiki only, or something in our own namespace kept out of the main keys

On the relabeling loop, that one we can address without waiting on anyone: if an OSM user corrects a POI, we shouldn’t be presenting it as unlabeled and inviting someone to overwrite it. We’ll change the app so corrected tags are treated as authoritative rather than missing.

Happy to keep this conversation here or by email if that’s easier for the DWG.

2 Likes
6

I don’t think you should be introducing a custom category=* key, when that’s not an established OSM tagging scheme. Instead you should do your best to work out the equivalent OSM tags (you may need more than one or two) for each type of object that you’re interested in.

Maybe you could post a list of the object types with your internal tagging and what you think the equivalent OSM tags would be. Perhaps highlight any that you’re not sure about or need further guidance on, and them I’m sure the community would be able to help you out. There are generally ways to tag most things in OSM, and key values can be extended in suitable ways (see Any tags you like) if not. But it would generally be better to use standard OSM tagging practices and keys (with extensions to new values where appropriate) then using a proprietary key of your own.

6 Likes
7

Looking at changesets, there haven’t been many since 1st April 2026, and it looks like the problematic tags from those have been tidied up.

(echoing what @robert_whittaker has already said) drop it on upload.

There are usually examples around in OSM somewhere. Perhaps ask in the forum about specific examples - but do bear in mind that some of the things that “take bitcoin” aren’t suitable to be added to OSM (businesses with no bricks-and-mortar presence).

2 Likes
8

Read the documentation:

4 Likes
9

Thanks all. This is now live, so here is where things stand.

category=* is gone. We no longer write it on upload, and we no longer write google:place_id either. That second one was not raised here, but a Google identifier sitting next to a Google-derived vocabulary invites exactly the conclusion nobody wants about where our data came from, so it went with it.

Corrections are now authoritative. Two things were happening. Our writer used a 331-entry table and our reader a much smaller one, so our own uploads came back unrecognised and rendered as an unlabelled “Bitcoin Location”, which is what invited the next person to relabel. And on edit we merged our tags over the node’s, so we won every disagreement. Both are fixed: the reader is now derived from the writer so the two cannot drift, and if OSM classifies a place at all, we leave the entire classification alone and only touch the details our contributor actually filled in (hours, address, contact, payment).

That guard is deliberately node-level rather than per-key, because a per-key one could not tell a tag a mapper had deleted from one that was never there. If you fixed amenity=coffee_shop to amenity=cafe and removed a bogus cuisine=coffee_shop, the cuisine came straight back on our next save. Same for a retag across keys: correcting amenity=bar to shop=alcohol got our amenity=bar written back beside yours, leaving two conflicting primary tags. Neither happens now, and both have regression tests.

While fixing it we also stopped writing a lot of other things we should never have written. To pick the worst: note:submitted_by_role and note:submitted_by_nostr, invented keys that also squatted on the note:<lang> convention; contributor attribution belongs to the changeset and the account, not to object tags. Free-text fields were HTML-escaped before the XML layer, so OSM was storing things like description=Bob&#39;s Bar &amp; Grill and opening hours no parser would accept. Un-ticking a checkbox in our form wrote lgbtq=no. And our optional-extras list let about fifteen invented keys through verbatim (soundproof, instructor, price_range and friends). Changesets now carry created_by=MappingBitcoin <version> with an actual version, and a comment that says what changed rather than naming the tool.

@Robert_Whittaker, the list you asked for:

335 internal types. 312 map to documented tags, 22 are refused at submission, 20 are flagged where I am unsure. It is generated from the source table rather than written by hand, so it cannot quietly drift from what the code does. Every value in it was checked against taginfo, and anything with a handful of uses and no wiki page was removed rather than kept.

To answer my own two questions from earlier, now that I have done the work: dropping category=* entirely was right, and for the second one I ended up going further than “use only wiki-approved values”. Three outcomes rather than two:

  • Where a real business has premises but no specific tag, we write the documented generic and let mappers refine it: shop=yes for an astrologer, office=yes for a summer camp organiser. Not shop=fortune_teller, which has 9 uses.
  • Where the thing is not a point of interest at all, we now refuse the submission instead of uploading it. That is 22 types: boundaries, land areas, residential complexes, and delivery-only businesses. Creating a node for a postcode helps nobody, and I would rather turn a contributor away than put that in the database.
  • Exactly one accepted type writes no primary tag: other. If the contributor cannot say what the place is, I am not going to guess for them.

@SomeoneElse, on businesses with no physical presence: agreed, and that is now enforced rather than just intended. meal_delivery, food_delivery, fishing_charter and transit_depot are refused outright.

Where I would genuinely value input, and I have tried to keep this short rather than ask you to audit 308 rows:

  1. Spas and wellness centres. leisure=spa has ~364 uses and no wiki page. amenity=spa has ~694. shop=beauty + beauty=spa has ~1,935. None of these looks like a settled answer and I do not want to entrench the wrong one.
  2. Cat cafes and dog cafes. There is nothing established: cuisine=cat_cafe and cuisine=dog_cafe are zero, cat=yes at ~118 means cats are permitted, animal=cat is ~42. dog=yes is wrong for the same reason, since that is what our own pet-friendly option sets. They currently write plain amenity=cafe and lose the distinction. Is there a preferred form, or is the answer that OSM simply does not record this?
  3. Groceries. I have grocery_store, asian_grocery_store and food_store all writing shop=convenience. shop=supermarket overstates a small shop and shop=greengrocer means fruit and veg only, but a single Google type genuinely spans corner shop to full supermarket, and I cannot tell them apart from what the contributor gives us. Is shop=convenience the right default, or should this stay unclassified and let mappers refine?
  4. Fortune tellers, astrologers, psychics. shop=fortune_teller has ~9 uses, so these currently write a bare shop=yes. Is there anything documented I have missed, or is the generic the right answer?
  5. Smaller ones I would take a view on if anyone has one: water_sports (sport=water_sports, ~153 uses), truck_stop (currently highway=services, though the merchant is usually the fuel station), and historical_place (currently tourism=attraction + historic=yes, since historic=yes on its own reads as a placeholder).

On the nodes we already uploaded: I have deliberately not touched them. Cleaning up our own past edits in bulk is a mechanical edit and needs a proposal here first, and doing it unilaterally right now would be a strange way to respond to this thread. @SomeoneElse noted things since 2026-04-01 look tidied. If there is a residue worth clearing, I would rather you tell me the scope you would want and I will write it up properly before touching anything.

I will send the note to data@openstreetmap.org as well, as suggested earlier, so the DWG has this from us directly rather than second-hand.

Sorry it took a thread to get here. The tagging was genuinely wrong and the criticism was correct.

2 Likes