*:signed is used to indicate whether the tag it refers to is signed or not and is helpful for on-site verifiability of the referenced information.
It has mainly been pushed by StreetComplete for various keys and thus seen a massive increase in usage during the last years.
However, it is conceptionally problematic that it is a suffix key and not a prefix key. Please read the proposal for more information.
What’s your take? Do you have any more/better examples where the suffix key could be problematic? Or do you think it’s not worth it and it’ll be fine without the change?
Please, cross post this announcement on the tagging mailing list on my behalf by sending an email to: tagging@openstreetmap.org
That is a great idea. Supplementary tags like this one should follow a uniform format. Also, it would be very easy to migrate old data to the new format. Such a change should reduce confusion, errors, and simplify the tagging schema. I am all in++.
In what way is it problematic? Your page describes problems with “recycling:note” and “addr:source” but then says “Inconsistency alone is not a good reason to change this”. Is there an example where “:signed” would actually cause an inconsistency?
What I meant with inconsistency is: It is inconsistent that the other (I name them:) meta tags such as note, description, fixme, check_date, source etc etc are all keys that are prefixed, while signed is suffixed.
The paragraph with the examples only explains why beyond being inconsistent, it is / may be problematic.
If this was not clear from the description, maybe you could help to clarify its intent? As you know, I am not a native English speaker.
The premises seems to be that the internal structure of a key has semantics of its own but that is a fallacy, “namespacing” is simply a convenient way to construct unique keys and not much more.
Nearly no users ever see the actual string value of the key to start with so this is just another occasion we are going to be churning tags, burning manpower with zero value added.
Nominatim has always operated under the assumption that name:* tags contain some kind of name and are therefore all indexable for search. name:signed has joined a blacklist together with other problematic tags like name:wikipedia and name:etymology. So, I’d say: good riddance.
Given that this is more of a house-keeping tag used for communication between mappers than something that data users have in active use, the usual issue of spreading the word about such a change is much smaller.
A key’s structure may not really have its own semantics, but there are conventions for when prefixes or suffixes are used. It seems like usually a suffix is used when a tag is recording similar or related but more specific information to the main un-suffixed key. For example lanes specifies the total number of lanes on a road and lanes:forward specifies a subset of those lanes that are going in one direction. Prefixes are generally used when a tag is recording a different kind of information or changing the meaning of the unprefixed key. For example building indicates a building but demolished:building does not add more specific information about a building. Instead it indicates something completely different–that there is no longer a building. However, there are plenty of examples that do not follow these conventions. As much as I appreciate consistency, it would not be worth the time to try and change all such keys. It’s also not always clear if one string is a prefix or the other is a suffix. Unlike lanes:forward, turn:lanes uses lanes as a suffix. Or maybe it’s turn that is used as a prefix. One could argue that turn:lanes is different kind of information than lanes or that is tightly related but more specific. It probably doesn’t really matter either way.
I’m also not sure it really matters too much if *:signed or signed:* is used. That being said, opening_hours:signed=yes seems perfectly clear to me. It suggests that there is another commonly used tag opening_hours (which there is) and :signed is adding supporting information to tag this. signed:opening_hours=yes also seems fine but I’m not sure I’m seeing a big enough problem that it’s worth the effort to change.
I think the reason for this is that note, description, fixme, check_date, source are all used as keys by themselves, but can also be modified with a suffix indicating the specific tag they are referring to. On the other hand, signed is not generally used by itself because that would just mean there is a sign of some kind. Not terribly useful information.
Personally, I even think that signed:opening_hours could be understood as “These are the signed opening hours, they could differ from the real ones”, much like signed:maxheight (I know the bridge is 4m height, but signed are 3.5m). But that might be, because English isn’t my native language.
Anyway, I think it doesn’t matter whether it’s a prefix or a suffix. Just changing it for consistency might not be worth it, especially, because, as @ezekielf already showed, there isn’t really a consistent usage of prefix vs suffix. It seems more or less driven by language preference (lanes:turn vs turn:lanes). Having said that, I’m neutral to this specific proposal, as long as it will include an automated retagging.
Do you have anything particular statistic in mind which is missing in your view? Here is a taginfo search for :signed, I included this link in the proposal.
Though of course if the proposal is approved, I’d only change the documentation on tags that are documented. E.g. phone:signed with hundred-something uses is not documented.
Right, actually, I recall a different issue in StreetComplete where street names are displayed and editable in a table like this:
en
Wisut Kasat Road
th
ถนนวิสุทธิกษัตริย์
… and at one instance, there appeared some odd “language identifier” like old because someone used name:old instead of old_name. I’ll add both examples to the proposal as examples.
True, signed as a tag by itself would only make sense to denote that (the presence of) a map feature is/can be signed. Off the top of my hat, actually, several map features come to mind where this information may arguably be useful, such as:
amenity=drinking_water - there is a sign that says it is (public) drinking water
emergency=fire_hydrant - there is a sign for the fire hydrant
tourism=picnic_site, maybe leisure=firepit or amenity=bbq
But alas, I think this would be outside of the scope of that proposal and I am not really sure if this matters. After all, demolished is also not used by itself, right?
The main effort in the migration will lie by the software that is currently tagging and interpreting the tags. So, mostly at StreetComplete and as the author of both the proposal and the app I will of course make sure it is implemented if the proposal is approved.
However, it is true that it is a fallacy to assume that as a result of the proposal if approved, :signed tags will vanish anytime soon. Software that reads/write these tags will need to support both for an indeterminate time.
A kind of mechanical edit to migrate from one to the other is out of the question in my opinion because :signed is often used in context of on-site surveys and as changing the tag would update the last-update-date of every element tagged with it, software may assume that these elements were then just checked at the time of such a mechanical edit.
On the plus side, StreetComplete asks its users about the presence of e.g. opening hours signs, collection times signs etc. in regular intervals, so the usage numbers will go down bit by bit automatically due to continuous re-survey and not any kind of concerted effort is necessary.
I’ll make sure to mention these things in the proposal.
Sure, I have the ability to dig around through taginfo and research the various key combinations and how frequently they’re used and build up some comparisons and so forth, but I just think it’s unfair to expect community members that are reviewing proposals in their limited spare time to have to take on that level of analysis.
Are you proposing a wholesale change of established tagging? Deprecating a bunch of barely-used edge cases for the same tagging? How will it impact data consumers?
Unlike some of the commenters in this thread, I have no idea what the background is of prefixed versus suffixed keys and how they’ve come to evolve and what the current state of play is, and I personally think it’s the responsibility of proposal writers to lay out a baseline understanding of the current tagging challenge beyond “these are different and I would like to make them the same.”
The only thing you’ve really noted as rationale is that some keys are prefixed and some keys are suffixed and that we should standardize it because for some reason prefixes are better. So what I’m really looking for is a more robust explanation of the change, why it needs to happen, and who if anyone is impacted.
Software generally assumes that the suffix of the name key is a ISO 639 language code such as “en”, “de” etc.
Software should assume that only a valid IETF BCP 47 language tag (such as an ISO 639 language code) can represent a language subkey. signed is not a valid language tag. In case it helps, here’s a regular expression for matching name subkeys in Java, and here are tests to prove that it works.
The root of the issue is that subkeys of name serve two different purposes:
This is another name in another context: name:en, name:genitive, name:left. Sometimes this is expressed as a different base key: alt_name, official_name, sorting_name.
This key refines name with something you should know about the value of that tag: name:pronunciation, name:etymology, name:signed. Sometimes this is expressed as a prefix: source:name. In the specific case of name:pronunciation, technically we should’ve instead chosen e.g. name:en-fonipa for better standards compliance, but I suspect Nominatim would’ve had to special-case that anyways.
Which usage is worse? I think that’s mostly a subjective, aesthetic decision, since OSM keys are too inconsistent for there to be very much automated logic around their structure. The latter usage exists because the data model does not formally support associating a key with an array of values or an array of key-value tables. (If it did, this thread wouldn’t have stretched for over 200 comments and counting.)
While understandable, it was not the most forward-thinking decision to make language tags direct subkeys of name:*. It essentially assumed that no two- or three-letter English word would reasonably be a standard subkey. Naturally, to became a popular key, and Valhalla’s developers riffed off it by promoting destination:to. But this is not the name of the destination in the Tongan language; that would have to be destination:lang:to.
StreetComplete apparently regrets its promotion of *:signed because it affects not only name:* but also various other keys that could come with their own standard subkeys. But if the goal is to make key construction more predictable, there would be a long way to go. This table of standard key slots has an additional row for not only *:signed but also *:wikidata.
Meanwhile, I can never remember if psv:lanes or lanes:psv is the one with the vertical bars in it.
The link between name:xyz and ISO 639 is not inviolable either. The German community has decided to take over the entire Germanic language family to represent the Transylvanian Saxon dialect of German, which has no standard language code. I’m unaware of any software that accounts for this special case.
I’m very confused. I understand opening_hours:signed=yes as the store’s hours are display. The reverse would imply that there is specific sign with opening hours.
Used as prefix, it refers to a particular sign. That sign is probably on it’s own node. Somewhere nearby the larger amenity who’s opening hours it displays. Even if thats whats intended, the tag should not be an adverb as it sounds awkward as it breaks basic English grammar.
The suffix version should be used to convey how the prefixed tag is being applied. In case of opening_hours:signed=, the value indicates whether the specified hours appear on some type of sign or not.
