(Informal) Proposal: Recommend using `board:title=*` over `name=*` to tag the title of an `information=board`?

General talk
82

I would say my philosophy on this is that the wiki serves both purposes. For data consumers, description is the only thing that matters, and it’s important that the wiki document what OSM actually contains so they can make an informed choice on how to present that information.

For mappers though I would argue the wiki is primarily prescriptive; I read it to tell me how to format my edits. In the absence of any explicitly prescriptive information, even the descriptive parts of the wiki are actually prescriptive for me as a mapper, because mappers conforming to common convention is critical to the success of OSM as a useful project.

As we just discussed and agreed on, OSM tagging is not a human language, it is a computer-readable data format. While humans are good at dealing with ambiguity, computers are not. If we had “15 competing standards” for everything, OSM would be nearly unusable for data consumers. Because of this, some degree of prescriptivism is necessary for the health of the project.

For the same reason, mappers who completely ignore the wiki and established convention, unless they are guided by an opinionated editing tool, are at best less helpful than they otherwise would be, and at worst actively harmful.

That said, I actually am a big fan of “any tags you like” in principle, at least in cases where there is no established convention, or when choosing between existing established conventions. It allows mappers to solve problems with the existing tagging scheme on the fly without having to go through some complicated proposal process, or any process at all for that matter. It prioritizes doers over talkers, which I think is good for the health of the project.

As a concrete example, I was rather disappointed by the lack of any conclusion in the Solving the dreaded access=dismount problem thread, until I realized some people had just quietly invented and started using bicycle:pushing=*, bypassing the proposal process and solving the problem for everyone as far as I’m concerned.

Sadly, the problem we’re discussing in this thread is not so easily solved by unilateral action.

What do you think about this as an iterative approach?

  1. Propose inscription:title as a replacement for board:title, but not for name yet (we leave that untouched for now).
    1.1. Organized effort to re-tag existing board:title to inscription:title
  2. Proposal to prefer inscription:title over name, but but leave name in place as acceptable (but deprecated) usage for now
    2.1. Modify the wiki and existing tooling to prefer inscription:title over name
    2.2. Manually re-tagging name as inscription:title would be allowed where appropriate, but not required.
  3. Automated edit to fix past StreetComplete edits which used the name tag to use inscription:title instead (since the question the UI was asking users is “What is the title of this information board?”, there’s no risk of anything being lost in translation here)
  4. Some time passes, name becomes (hopefully) less prevalent and inscription:title more prevalent.
  5. Another proposal to fully eliminate the usage of name in this context, this time with an organized effort to re-tag existing usage and inform mappers of the new tagging scheme

#2 is essentially what I’m proposing in this thread (except with board:title). #1 is a possible follow-up, but I agree with you it would be slightly less disruptive if it was done before or at the same time as #2. #5 is the only part of this that I think is actually particularly hard, but if it fails #1-#4 would still leave us in a better position than we are now so I think there’s little risk there.

2 Likes
83

Often, but not nearly always. Note that 3rd category I mentioned: “OSM wiki ignoramus” - e.g. default map (Carto) shown on www.openstreetmap.org is one of the prominent data consumers, who refuse to consult the wiki at all in making their decisions, and instead prefer to look only in a database and what is there. [1]

There I agree with you, and that is “descriptivist” stance.

Absolutely, that is the purpose of the wiki – it is expected that in most situation people will choose to do what everybody else is doing (unless they feel their case is special). It does not make it prescriptivist in a sense I meant.

But I think you missed the main point – the problem is not (the quite common, but maybe not majority) case when both “What people actually map” and “What we feel people should be mapping” are the one at the same. In that case, as you noticed, practical difference between “descriptivist” and “prescriptivist” does not actually exist, and everyone is happy as the situation is ideal!

The problem is however in many cases that “What someone feel should be how things are mapped” differs from “How are people actually mapping”, and those cases unfortunately also abound.

It that case, wiki cannot simultaneously recommend two opposing things “this situation should be mapped with X=A” and “this situation should be mapped with X=B”. It is our own equivalent of Pauli Exclusion principle.

In my opinion (as a descriptivist), the best we can do is such cases is document both actual state and community opinions, with something like:

“stats as of 2026/07 show that 90% of tagging is using X=A for that case, but 10% of community seems to insist that it must be tagged as X=B as they argue it makes more sense because XYZ”

E.g. see post_office=post_partner diff as a real-world example of such difference of “wishes how something was voted and how people feel should be tagged” vs. “how it is actually being tagged” ).

Note that this example is a lucky case, as we can get stats which can tell us how it is actually being used. For some other tags, like smoothness=*, if is impossible to say whether wiki nowadays matches the actual tagging, or just someone wishes how it should be tagged. The best we can do is run some polls and document how people might disagree with definition on certain values – but that will reach only tiny percentage of community, and will thus be quite biased (but still probably better then nothing, as long as bias is acknowledged).

The prescriptivist approach however would be to only state “this situation should be mapped with X=B” as that is what they feel is better, and that actual use should ideally not be mentioned at all (or if it does get mentioned, it should preferably happen only on Talk page that nobody will look at, and even then clearly marked as “deprecated” / “unwanted” / “incorrect” tagging.)

It this were wikipedia, there would be huge “[citation needed]” put right up there :wink:
Humans are in my experience terrible at dealing with ambiguity, creating a random untraceable and inseparable mix of both meanings - see e.g. landuse=farm or more generally Counterintuitive_keys_and_values.

Basically the only practical solution is deprecating the whole ambiguous tag (preferably after inventing two [or more] separate tags for those two [or more] different meanings that were creating ambiguity), and it is not easy nor painless to do…

Computer programs, however, when confronted with ambiguity, will very often behave deterministically - i.e. same program will always assume the same thing, even if it is not the one that was wanted. That makes it possible to find systematic errors they introduced and fix them automatically, contrary to errors introduced by humans due to ambiguity.

While multiple standards (somewhat obviously) are not ideal from data consumer stance, it is actually relatively easily handled by data consumers (much easier than most non-programmers would imagine)

Sure, if (tags["amenity"]="pharmacy") then xxx is somewhat simpler then if (tags["amenity"]="pharmacy" or tags["healthcare"]="pharmacy") then xxx, the difference is (when you look at the whole slew of problems they have to handle) pretty minor (even if there were 15 aliases for that, rather just 2 as in example above) for that same thing. It is most basic junior-level coder stuff.

Yeah, I’d definitely agree that if they are behaving randomly, that is in almost all cases worse then if they consulted the wiki.

However, if they are behaving in well-though way (e.g. by doing research of actual use of tags in database, or using preset made by editor who did such research), their results might be better then those by humans following the wiki (which might be in the middle of edit warring, or made by prescriptionist instead of descriptionist etc)

I am big fan of ATYL too, but only where there are not already existing tags for the same purpose. If such tags exist, but people don’t want to use them due to NIH sindrome or laziness to search, then ATYL is actually producing bad results. :frowning: But for mapping things which have never been done before, it is absolutely indispensable.

Glad you liked it, I (quite obviously) thought that it was a good way to progress from that state.

Yes, agreed. Inventing new tags is easy and risk-free; changing existing ones is million times harder.

  1. I may often think they lose some insight there, and they seem to think it is better as it doesn’t contaminate their thinking with irrelevant and possibly made-up claims, so it lets them focus on what is important. Can’t say it doesn’t make sense sometimes, when I see mess of some wikis - e.g. ones edited by extreme prescriptivist User:Rtfm ↩︎

84

Yes, I’d definitely say ordering is very important there. So I would agree it is probably best trying going for for #1 and #2 combined in same proposal, as they are related (and if were to be done separately, it would need extra explanations why the other tag was not being considered there).

I think you might find that parts in your list with text “Propos(e|al)” might also be quite harder then planned (as they are required for others to proceed, and depend on OSM mappers to be mostly of the same opinion, which is in my experience has not historically always been exactly trivial task)

Other than that, yeah, I think it might work, given that each step is well though out. So, great start!

Few things I’d suggest (I might have mentioned some of them before, but there it goes):

  • first run a poll to see whether people would prefer inscription:title or something else, to choose what your proposal will run with (for example, I’m not a big fan of that choice, as I’d find more plain title both more versatile, easier to find, and less confusing – e.g. if the map has a title, why it would be inscription:title if there is no text inscribed other than that title?

  • mention that poll (and following proposals) both in relevant threads (like this one), issues (like that SC one), tagging ML, and on Talk pages of related wiki tags (Talk:Key:name, Talk:Key:board:title, Talk:Tag:information=board etc) and elsewhere where it might be relevant, so you get most of opinions at those phases.

  • also somewhere closed to the beginning in that TODO list there there should be opening issues (or preferably, pull requests) to modify popular editors which create those to-be-deprecated tags. The same should be done for popular data consumers which use those to-be-deprecated tags, but probably at different place in a list (I guess it was to be covered by “modify […] existing tooling”, but it should be more explicit re: difference editors/other data consumers)

  • finding both those affected editors and data consumers should be about the first task, as it should be mentioned in the proposals (which are currently #1)

  • also remember to think about related tags, i.e. it was mentioned before situation where SC tags that there is no title (where existing tag does not fit if main title tag changes from name to something else), multiple languages and how they should be tagged in new scheme etc. any other concerns that people might’ve brought up.

  • “organized effort” might be “automated edits” in some cases; in any case it should be considered what is better approach, and how exactly it should be handled.

  • read Deprecating is hard - OpenStreetMap Wiki and think about each bulletpoint there: what is its scope, and how you think it would be adequate to handle it. It should help fine tune your iterative TODO list above, and in proposal process many people will appreciate attention to detail showing that you’ve well-though about it…

    You don’t have to propose the perfect solution for each bullet point there in a first Draft (people will tell you their opinion how it should be better handled), but you should show them that you know about the issue and are prepared to handle it, i.e. that you’ve done due diligence and are serious in your intentions.

2 Likes
85

I think the way you define this term it’s just a particularly extreme form of descriptivism. Like other forms of descriptivism, I agree it’s a perfectly reasonable stance for a data consumer to take. (But would be pretty bad for a data editor.)

It can simultaneously describe the common usages and prescribe a single preferred usage. Mappers should follow the prescribed usage and data consumers should support both. (Even the aforementioned wiki ignoramus would likely support the prescribed usage after it gains enough popularity. Though I personally think they might be better served by not waiting until then.)

I’d probably do something similar, but would word things much more strongly in favor of the tagging the community currently prefers over how the tag has been used in the past. In the case of a clear consensus (like a formal proposal passing) I’d phrase it something like:

This should be tagged with X=B. As of August 2026, 90% of tags still use the old X=A tagging scheme. While this scheme is still widely used, it was deprecated[1] in August 2026 and should be avoided in new mapping wherever possible.

Though to be clear I think a 2:1 plurality in an informal poll is too weak to justify wording this strong. If I were to edit the wiki today based on the results of the poll in this thread I think something closer to your wording would make sense.

I agree with you that such a purely prescriptive approach would not be good, as it would make the wiki far less useful for data consumers. But I also think a purely descriptive approach where you only describe existing usage without making any prescriptive recommendations would also be ill advised.

And just to make this explicit, since it seems like you often have one particular guy in mind[2] when you talk about prescriptivists: I don’t think prescriptive documentation should be based on one person’s opinion, but on community consensus. That’s why I made this thread before trying to edit the wiki.

To be clear, by “good at dealing with ambiguity” I meant good at interpreting ambiguous information, not good at being unambiguous. (Case in point; I guess I wasn’t being as clear as I thought I was when I wrote that sentence. :wink:)

When a human encounters ambiguous information they can seek clarification, infer the correct meaning from context, or just accept the uncertainty and take it into account when choosing their next course of action.

Computers, barring some kind of AI wizardry I doubt anyone wants to incorporate into their tag parsing code, are not so flexible. They work best with a single, clear, unambiguous tagging format, which is something human editors are not great at producing unless guided by equally clear, unambiguous prescriptive documentation, or an opinionated editing tool guided by the same.

If by “multiple standards” you just mean “15 different tags that mean exactly the same thing and are used exactly the same way” then sure that’s not that hard to deal with (though still bit of a PITA). But that’s not what I was envisioning. In the absence of clear standards, the real world often tends to produce situations much more like your example of smoothness, where there is “a random untraceable and inseparable mix” of different meanings.

I think some amount of prescriptive documentation is both desirable and necessary for avoiding such situations.

Here it sounds like we’re in full agreement.

Agreed.

So I’ve noticed. By “particularly hard” I was mostly referring to the execution, not the part where you have to get people to agree.

I think it’s great that we have such a diversity of opinions here, but I do find it a bit frustrating that the process seems to be organized such that when there 3 competing options, A, B, and the status quo, and 1% of people prefer the status quo, 40% think we should do A, and 59% think we should do B, the status quo wins. I feel like we need ranked choice voting or something…

Good advice.

  1. link to proposal page ↩︎

  2. You’ve mentioned User:Rtfm several times now. ↩︎

1 Like
On issues with tag voting
On issues with tag voting