Proposal talk:Replace *:signed with is signed:*

Make it simpler

signed=key. For example:

• amenity=pub
• name=Lone Buffalo
• opening_hours=...
• signed=opening_hours;name

Something B (talk) 16:02, 1 February 2023 (UTC)

That variant would need less data and could be handled by software properly, but for mappers using software that does not have a supporting interface for that key, the handling would be worsened. That is a tradeoff, in which I do not have a clue which variant would be better.

--Sdicke (talk) 16:46, 1 February 2023 (UTC)

This would be very inconsistent with other meta keys.

Also, it takes away the theoretical possibility to append a check date to a specific signed key. E.g. denote that whether the shop has a an opening hours sign has been checked last at this and that date: check_date:signed:opening_hours=2022-10-10

--Westnordost (talk) 22:31, 1 February 2023 (UTC)

Resolved: Stated reason why the original suggestion is better than the alternative suggestion according to the proposal author

Not good examples vs Problems with the syntax

As a user only, I don't find *:signed=* or your cases a significant problem.

• recycling:note=*: This should not be used in the first place. There is no recycling=* alone. It should be a note=* on the amenity=recycling, or can be a recycling:*:note=* for the recycling:*=*. For the general cases, an "all" suffix can still be invented, or it can reuse by recycling:others:note=* (obviously "others" is not a physical item to be recycled either) or recycling:waste:note=*. It will be understood what it means. Tag:amenity=recycling#Accepts further claims recycling:operator=* is a mistake, but the facility operator=* of a recycling_type=container can definitely be different from the end recycler. That's not including intermediate collector, which makes owner=* not strictly correct as well. A recycling_type=centre may also be fronted by a different organization than the end processor. For the relevance, recently our country reports the news of a collector not transferring the recyclable items deposited at an NGO station to the end processor. To compare, this format would instead align with heritage:operator=*, toll:operator=*, internet_access:operator=*, and atm:operator=*, for the numerous ones.
• addr:source=*: Depends on what is meant by "part" of the address. The source can be important. addr:interpolation=* doesn't form an address itself, only a data format. Same "philosophical" question can be pondered on whether name:pronunciation=* or name:etymology=* are part of the name. And surely the year range suffix format name:****-****=* aren't related to the existing name. For other examples, source:url=* or source:ref=* aren't the source=* of url=* or ref=*. Are such meta items not few and standard enough to escape?

So I'm fine with examples of name:wikipedia=* and others. Eg *:description=*, *:url=*, *:location=* in the cases of defibrillator:location=*. Are they much different from the meta annotations?

What can be improved is separating the presence of signage and signposted content. Eg https://taginfo.openstreetmap.org/keys/ele:signed#values has seemingly been used for the signposted heightm and some of its ele=* indeed doesn't equal to ele=*. Indeed this is meaningful. It's not enough to assume ele=* and signposted height are equal, or worth adding the inscription=* or ele=* on some tourism=*, man_made=*, or traffic_sign=* sign objects. It might even be ele:local=* only, and let's not get into how ele=*, ele:regional=*, and ele:wgs84=* are defined....

Therefore for a change, you could use is_signed:*=* for annotative boolean presence or a pre-defined status. signed:*=* can then be reserved for the functioning format corresponding to *=* when there is mismatch, misunderstanding, disagreements, etc.
--- Kovposch (talk) 17:45, 1 February 2023 (UTC)

True, the examples are not very good because they are quite theoretical, plus, it is true that other suffix keys exist. I added a better example and changed the description a bit to reflect that.

I also like the is_signed:*=* suggestion because it makes clear that it is a boolean rather than to tag the difference between signage and physical (width, height, name, ...).

--Westnordost (talk) 22:35, 1 February 2023 (UTC)

On the other hand, I see no other "is_XXX" (except is_in) tag on taginfo, so this very name may already be inconsistent. --Westnordost (talk) 12:21, 3 February 2023 (UTC)

Although I oppose it, there has been is_sidepath=* for generalizing sidewalks. Would be a start for more self-explanatory syntax by using grammar as a hint. Unless using both signed:*=* for existence and *:signed=* for content is acceptable. Similar to what I said, I'm fine with that, but it looks confusing to me as well. Not that there is no precedence for different namespacing / prefix vs suffix having different meaning, with lanes:*=* & *:lanes=* leading. --- Kovposch (talk) 15:25, 3 February 2023 (UTC)

Or it could be changed to noun signage:*=* for emphasis. Also to follow most other annotations. --- Kovposch (talk) 20:35, 3 February 2023 (UTC)

fire_hydrant:signage=* (1231 instances) is interesting... Kovposch (talk) 20:38, 3 February 2023 (UTC)

Hm well, wouldn't signage have the same problem as signed, as in that it could be misunderstood as not being the boolean it should be though? --Westnordost (talk) 20:49, 3 February 2023 (UTC)

By the same logic, the other option can still be interpreted as the attribute "is signed" as something, similar to how you pointed out is_in:*=*. There's a limit to the optimization in trying to incorporate the semantics. --- Kovposch (talk) 10:39, 4 February 2023 (UTC)

The raised has_signage:*=* is better yet? --- Kovposch (talk) 08:39, 5 February 2023 (UTC)

I don't know, is_signed:*=* was mentioned more often and noone mentioned that it sounds odd, so I chose that tag now --Westnordost (talk) 11:54, 6 February 2023 (UTC)

Resolved: Added a better example, changed proposed tag to is_signed