Proposal:Replace *:signed with is signed:*

Replace *:signed with is_signed:*
Proposal status:	Rejected (inactive)
Proposed by:	Westnordost
Draft started:	2023-02-01
RFC start:	2023-02-01
Vote start:	2023-02-15
Vote end:	2023-03-01

*: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 been used by StreetComplete for various keys and thus seen a massive increase in usage during the last years (e.g. 30k+ for opening_hours:signed=*). So far, it has been used for example to denote:

• opening_hours:signed=* - whether the opening hours are signed
• maxweight:signed=* - whether e.g. a bridge has a maxweight sign
• maxheight:signed=* -whether e.g. a tunnel or an underpass has a maxheight sign
• name:signed=* - whether the name=* of this feature is actually signed on-site (e.g. for bus stops)
• and more...

In terms of software support and according to taginfo, all these keys have actually been exclusively used by StreetComplete except for name:signed=* which is also used by SomeoneElse's "England and Wales rural pedestrian" cartoCSS style (unsigned names are shown in brackets).

Proposal

The proposal is to discourage the use of *:signed as suffix key, encourage the use of the is_signed:* as prefix key instead and document it accordingly.

No mechanical edit is planned nor recommended to enforce this change, so if this proposal is approved, it is expected that *:signed will still be around for a long time. This means that software will need to understand both variants for a long time.

However, StreetComplete, as the main user of this key, will be made to only tag is_signed:* and remove *:signed when a user re-confirms the information (e.g. when re-surveying opening hours) but will understand both, because the suffix key will be around for a long time as usage will only decrease slowly.

Rationale

1. signed has been misunderstood by a very low number of mappers (about 0.01% to 0.1% of usages, depending on the tag) to mean "the ... as signed" and additionally a number of people have commented on that signed sounds a bit odd and could indeed be misunderstood. Hence, the change to is_signed.
2. The structure of the key is inconsistent with other such "meta" prefix keys, such as note:*, check_date:*, source:*, fixme:*, i.e. it is not a prefix key but a suffix key. However, this is a weak reason as there are other such meta keys that are indeed suffixes, such as *:description.
3. A better reason against suffix keys is that these can invade on the namespacing of a key in a conflicting manner. Examples where a suffix key conflicts with the namespace of another key:
   • name:signed - Software generally assumes that the suffix of the name key is a ISO 639 language code such as "en", "de" etc.. Because name:signed=* does not fall into this pattern, Nominatim had to add this tag to a blacklist to not index this tag. The same would need to be done for every key that can (theoretically) appear as a suffix to any other key. Software that shows a list of names grouped by language also have to explicitly exclude from display any such suffix. This has been an issue in StreetComplete. If is_signed:* was a prefix, it would not have been an issue.
   • recycling:note - Is this a note for the recycling key or can "notes" be recycled here? The namespace below recycling:* is reserved for what things can be recycled here, and the latter is somewhat of a free-form key. While humans may be able to ascertain what is meant, software would need to specifically exclude such "meta" suffixes from any parsing. Hence, putting such meta information on keys into the suffix is generally problematic.

Features/Pages affected

At least opening_hours:signed=*, collection_times:signed=* maxweight:signed=*, maxheight:signed=*, name:signed=*, ref:signed=*, fire_hydrant:diameter:signed=*

If the is_signed:* is documented, there is really no reason to have a wiki page for each single use of *:signed, so the pages above can be deleted or made to redirect to the to be created is_signed:* wiki page..

External discussions

• https://community.openstreetmap.org/t/rfc-feature-proposal-replace-signed-suffix-key-with-signed-prefix-key/8459
• https://lists.openstreetmap.org/pipermail/tagging/2023-February/066928.html

Comments

Please comment on the discussion page.

Voting

Voting closed

Voting on this proposal has been closed.

It was rejected with 6 votes for, 10 votes against and 0 abstentions.

• I approve this proposal. -- Something B (talk) 11:43, 15 February 2023 (UTC)
• I oppose this proposal. I see no great benefit in using a new tagging scheme for this --chris66 (talk) 12:21, 15 February 2023 (UTC)
• I oppose this proposal. This proposal will cause confusion and waste everyone's time for almost no benefit. --SomeoneElse (talk) 12:55, 15 February 2023 (UTC)
• I oppose this proposal. as noted in forum discussion, I find current situation quite OK, and in fact find current suffix as more logical than proposed prefix. If it was a new tag being proposed, there would be a slight benefit in using *:is_signed=yes to address that <0.1% confusions -- but still as a suffix. At this point it time, possible tiny benefits are much less than confusion which renaming would bring. --mnalis (talk) 01:42, 17 February 2023 (UTC)
• I oppose this proposal. both *:signed=no and is_signed:* are a bad designn : if a key has only one useful value (here =no), it means that the key should be a value of another key (unsigned=name unsigned=opening_hours ...) Marc marc (talk) 02:09, 17 February 2023 (UTC)

There are instances where =yes would be meaningful, for example with speed limits. For any key where it is common to tag something also in the absence of a sign. Really depends on mapping practice. Or for bicycles allowed on sidewalks: Is there a sign, or did the mapper assume cyclists are allowed for other reasons? Westnordost (talk) 12:27, 17 February 2023 (UTC)

• I oppose this proposal. It's unclear what this proposal is trying to achieve or why it's important. It seems myopically focused on a StreetComplete bug and I'm not sure why the broader community needs to be involved -- just fix the bug. --ZeLonewolf (talk) 18:30, 17 February 2023 (UTC)

Oh sorry, you refer to the example in point 3 of the rationale. I meant to write "was", not "has been". It is an issue for any software that assumes that any subkey of name=* is some sort of language identifier (IETF or OSM community defined, like name:zh_pinyin, name:carnaval etc.) Westnordost (talk) 13:28, 18 February 2023 (UTC)

The entire opening section, before the proposal section even, was about StreetComplete. If the concern you're trying to address is that name:signed=* could be confused with a language code, that definitely didn't come out very strongly in this proposal. --ZeLonewolf (talk) 00:23, 19 February 2023 (UTC)

• I oppose this proposal. I don't find the premise of this proposal very convincing. Apparently neither do the authors of the key syntax documentation, which details three different reasons for a suffix to refine its base, not just to localize the base; the practice of refining a base using a prefix, proposed here, is "relatively uncommon". Order of key parts describes even more reasons for suffixes. If the IETF subsequently makes "signed" a valid locale code, I will eat my hat. Besides, for those who care about key part transposition causing confusion, there are bigger fish to fry. – Minh Nguyễn ^💬 00:53, 18 February 2023 (UTC)
• I approve this proposal. This gets rid of some of the rough edges in OSM tagging, especially name:signed=* not being a name, which affects database users. --Andrew (talk) 14:51, 19 February 2023 (UTC)
• I oppose this proposal. If a name being signed were part of its lifecycle, then this might make sense as a prefix. As that seems unlikely, I feel it makes far more sense keeping it as a suffix. --Rskedgell (talk) 07:23, 23 February 2023 (UTC)
• I approve this proposal. I prefer these clear tags to concatenating. It is good practice in writing software to name variables this way --MatthiasMatthias (talk) 19:14, 24 February 2023 (UTC)
• I approve this proposal. Prefix is better than suffix, makes sense to switch --Arrival-spring (talk) 18:59, 26 February 2023 (UTC)
• I oppose this proposal. I don't like that acceptance of this proposal would mean we would have to live with two parallel systems for a very long time. --Skorbut (talk) 21:07, 26 February 2023 (UTC)
• I approve this proposal. --Totera (talk) 03:37, 27 February 2023 (UTC)
• I oppose this proposal. I might be missing something but I don't really see the point - it will break anything that currently consumes :signed for some curious notion of tidiness, and if tidiness is your bag, OSM tagging is probably not the ideal recreation for you. (For what it's worth I don't think taginfo's Projects page is useful other than as an unrepresentative sample of data consumers - no-one commercial who markets themselves on the quality of their rendering/routing is going to document their "secret sauce" there, for example. It's a nice sample of enthusiast projects but not much more than that.) --Richard (talk) 15:09, 27 February 2023 (UTC)
• I approve this proposal. Happy to see name:signed go. Meta tags in suffixes are problematic for data users who work with open sets of suffixes. --Lonvia (talk) 08:39, 1 March 2023 (UTC)
• I oppose this proposal. IMHO this is at best just kicking the can down the road, there isn't really an established and universal ordering of key components that there is any agreement on (somewhere I pointed out that de:name would be just as valid if not more so than name:de) and this voting illustrates that nicely. I would propose to scrap this proposal and any similar ones and propose that we designate a key component for meta and qa keys and migrate all such keys to using that somewhere in the key. The French community used to use "validate:" but that might be too suggestive for the small number of people that actually read keys. SimonPoole (talk) 09:02, 1 March 2023 (UTC)