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.
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.
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)?
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.
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:signedshould 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:signedshould 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.
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.
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 I’m totally in favour of signposted / is_signposted over just signed.
“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.
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=*
I’m totally in favour of