[RFC] Feature Proposal - Replace `*:signed` suffix key with `is_signed:*` prefix key

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.

I don’t understand the situation much yet. It could use eg name:de-RO= first? Or the UN region name:de-642 to emphasize it’s not about the country. Unfortunately there’s no corresponding region, including in other standards. As a last resort, invent some private use name:de-x-*= here.

1 Like

Do I understand you correctly that you say that signed:opening_hours sounds like the purpose of the tag is to write what is on the sign (i.e. the opening hours)?

Obligatory taginfo:

signed:opening_hours 0 (of either potential meaning)
opening_hours:signed 31,263

and interestingly the values for that shows some small usage (10s, not 1000s) of the 2nd suggested meaning.

I do not think it makes much sense to change the status quo:

  • I do not see clear advantages that the new syntax would have over old one (i.e. what things were very hard/impossible with old syntax, but become very easy/possible with the new one)? IMHO, if some existing tagging is to be deprecated, there should be HUGE benefits for that, which I don’t see
  • current format actually makes more sense to me, because standalone_key:additional_attribute=* format actually makes all standalone_key related attributes be grouped together. Note that all other keys mentioned in the proposal using prefix format (note, check_date, source, fixme) make sense (and have massively been used) as standalone_key=*. On the other hand having just signed=yes/no key would be bad candidate for such standalone_key – it would make little sense on its own, as it would be horribly ambiguous and carry little (if any) information without more detailed specification. Thus, :signed seems to better be used as a suffix.
  • making the change at this point in time will not make people lives easier (and will instead make them harder for anybody using or planing to use those tags - even while acknowledging it is admirable you’d fix the major player yourself). I.e. if current status is preserved no work needs to be done (everybody that needs already handles the special cases). If the format was changed, it does not mean that the current hacks would go away, it only means that the new method handling would have to be added in addition to current hacks - ObXKCD. Hence, it would (needlessly) require more work.
4 Likes

Thank you, @Matija_Nalis, I think you summarized well the points that speak against the proposal.

I’ve worked in some of the feedback / contra-points / “howevers” into the proposal text and when it is moved to voting, we’ll see if there is a clear majority for replacing it or not.
I still think the proposal would make sense for I think the tag would be not problematic as a prefix key but (as described) potentially problematic as a suffix key.
I see it also as an offer to clean up this inconsistency, recognizing that StreetComplete has been the editor to popularize the key. Given, of course, that you agree in the first place that it is inconsistent and problematic. It looks like some either do not find it problematic at all or do not think it would be worth it, which is ultimately a matter of consideration.

So, suppose the proposal will be approved, do you think a prefix key like is_signed:* would be clearer than signed? I am not sure if I understood @IanH correctly there, but it was also proposed in the talk page.

name:signed is really just a house-keeping tag, a more interesting case occurs when the signed name differs from the actual name (could be a typo or even a completely different name), so on the ground it could be relevant to know which is the signed name, because this is what you will see, but name:signed does not help with this

Can you reword this (or write in German)? I am not quite sure I get what you mean. Are you saying that name:signed should mean “the name that is signed, which is different from the actual name”?
I am confused because this interpretation of this tag is not seen, documented or used at all, see taginfo, but maybe I just misunderstood you.

Can you reword this (or write in German)? I am not quite sure I get what you mean. Are you saying that name:signed should mean “the name that is signed, which is different from the actual name”?

you’re right, I expected name:signed to be a tag for the signed name, (there is actually signed_name with very low usage) but name:signed is only used with “no”, thank you for pointing it out
I think it is better to not make signed a prefix then, because signed:name and signed_name would be too different.

2 Likes

I would expect signed_name to have very low usage – name would generally be a better key for that.

*:signed and signed:* sound slightly funny to me but for a different reason: “signed” more commonly means that something has a signature, versus being signposted. Then again, payment:cheque:signed=no would have even lower usage under the former interpretation. :wink:

2 Likes

So you’re saying name:signposted=no / signposted:name=no makes more sense?
In any case, I think is_signed / is_signposted is less prone to be confused with the actually signposted name. I also confused named:signed for the actually signposted name in the past, same for the opening hours. I knew that the weekly market was opening up at 13:00, but the signposted opening hours were starting at 14:00 :person_shrugging: I’m totally in favour of signposted / is_signposted over just signed.

1 Like

“Signpost” might suggest a “post”. Aside from the 1156 signpost | Keys | OpenStreetMap Taginfo instances preceding marker= and boundary=forest*, there are similar numbers of https://taginfo.openstreetmap.org/compare/ele:signposted/name:signposted to the ele:signed= used for displayed content.
I further suggested “signage”. There are 1236 fire_hydrant:signage | Keys | OpenStreetMap Taginfo instances with compatible semantics and status, however including sign structure (=plate) if exists.

1 Like

Yes, supposing that the change is to be made (which I still don’t think is good idea), I guess is_signed (or maybe is_signposted or has_signage ) would have clearer meaning than just signed / signage- which could be misunderstood to mean “signed name” (as in “What is signed there?” or “What does that signage say?”), e.g.:

@dieterdreist I would think that the name=* is “signed” name (i.e. what the on-the-ground user would see when looking at a sign on a door/wall/… at that location). If the object has some other “actual” (official?) name, that would probably to official_name=*

1 Like

I was just musing about how “signed” came to be the preferred word around here. I personally don’t see a compelling need to change anything about the current tagging scheme, at least not under the stated rationale, which could be applied to a whole host of conflicts between actual established tagging schemes.

3 Likes

The word “signed” is also sounding funny to me right now. I often experience this from word repetition in extended tagging conversations :smile:

1 Like

Yeah me too, so I started digging through the git history. It was added for opening_hours in #1076.

@dieterdreist I would think that the name=* is “signed” name (i.e. what the on-the-ground user would see when looking at a sign on a door/wall/… at that location). If the object has some other “actual” (official?) name, that would probably to official_name=*

there are sometimes typos on streetsigns or there are different ways to write the same name, for example Via Venti Settembre is signed Via XX Settembre because it is ok to keep old street signs in this case although the name is now written differently.

Oh yeah, I can confirm that. In Thailand, street names are sometimes given in Thai script and below that, transcribed into latin script. There is an official transcription system for that (RTGS) but some signs do either not follow this system or at least not the latest version of it. Not sure how the Thai community handles that. Though maybe a little off topic now (I guess this thread could be moved if it becomes too long), I’d be interested to know. Do you know, @stephankn @Mishari ?

I also see street names like „Berliner Straße“ and „Berlinerstraße“ being mixed from time to time, depending on the sign. Or „Alanya Doner“ instead of „Döner“. And we all know what it’s supposed to be. Not sure if official_name would be correct here, but I guess so.