An unspecified or unknown crossing marking. Can also be used in document any crossing marking which hasn’t been documented.
The actual meaning in practice is closer to this:
An iD/Rapid user blindly accepted the suggestion for a tagging “upgrade” because they were more concerned about making the nasty yellow box go away quickly than actually making any effort to fix the alleged issue.
If they can see that the crossing is marked in the aerial or street side imagery, then they should add a meaningful and useful value.
As a result, the database is spammed by thousands of instances of tags telling us that “this marked crossing is marked”. Any instances where the mapper actually looked at the markings, couldn’t find an appropriate tagging suggestion in the wiki, and used crossing:markings=yes correctly are lost amongst the noise.
If we introduced crossing:markings=unknown for the original case and deprecated crossing:markings=yes, survey and QA tools could treat it in the same way as shop=yes and ask for a more specific value.
For this to be true, StreetComplete would need to ask not only whether the crossing is marked but also which marking pattern is present. StreetComplete is one of the main generators of crossing:markings=yes, and it operates on a model of asking only one simple question at a time, no compound questions.
iD’s Crossing Markings field, the other main generator of crossing:markings=*, accompanies each documented value with a pictogram, so the mapper probably wouldn’t have to consult the wiki. An occurrence of yes probably means no attempt was made to distinguish one pattern from another (same as the StreetComplete case). This is only as much of a tautology as any *=yes value: for example, button_operated=yes means a button-operated crossing is button-operated. In case the crossing is marked with an unusual, undocumented pattern, the approved proposal allows for any value you like, and so does the Crossing Markings field.
If anything deserves a new value, it would be an undocumented pattern, but it would be better to spend time and energy coming up with a descriptive value instead of something like other. If we were to deprecate crossing:markings=yes in favor of crossing:markings=unknown, the inevitable consequence would be iD offering to replace crossing:markings=yes with crossing:markings=unknown, because that’s how id-tagging-schema deals with one-for-one tag deprecations anyways.
There’s a working quest in SCEE for crossing:markings, which will hopefully find its way into StreetComplete.
Or iD could stop suggesting default values and ask people to fix the problem if (and only if) they know how. See also all the suprious layer=* tags added because people were encouraged to hide the problem instead of fixing it.
It isn’t incorrect to add crossing:markings=yes on a marked crossing, even if a more precise value would be available. The value yescan be used for a crossing marking style which hasn’t been documented, but that’s not the only situation in which it may be used.
Surely it would only be a matter of time before a replacement value would be equally “diluted” by the mechanisms you see in action for yes?
This value could easily be misunderstood as “it is unknown whether this crossing has markings”. So in terms of clarity, it would be a downgrade.
An =unknown should mean it’s not known whether it’s =yes or =no
There could be many reasons imaginable. Eg not knowing whether a pattern is =yes , =surface , or =no . I have seen mistakes where the highway= road having different =surface caused a user to make highway=crossing + crossing:markings=surface= , when the crosswalk itself has no different surfacing. If users don’t know for sure, they better add =unknown first with fixme= etc.
The presence of =unknown is more specific than fixme= in referring what to fix. It indicates there was an attempt to evaluate the crossing:markings= . It is at least more informative than having fixme= only.
If someone made it a default value, then yes, it would become as skunked as yes. There’s a simple solution to that: don’t suggest a default value in editors and QA tools.
What does it mean to “Deprecate x in favor of y” but not want any tooling to help mappers replace x with y? We don’t encourage bulk replacements, but that’s a far cry from saying mappers must type in the new tag manually each time.
I agree with you that a mapper should pause for a moment after accepting the tag replacement suggestion to consider any improvements they can make to the feature’s tags, but fiddling with tag deprecations doesn’t seem like it would encourage that positive behavior. Conflating unspecified and miscellaneous marking patterns is a problem, but that’s a consequence of the tagging scheme. What if we strike the second part of the yes definition?
An unspecified or unknown crossing marking. Can also be used in document any crossing marking which hasn’t been documented.
Miscellaneous undocumented marking patterns are being tagged in large numbers with descriptive values such as zebra:staggered, piano, and rainbow. There’s already a line right below that allows for some extensibility:
More values may be documented as they are discovered or invented by governments.
This is a very passive statement. We can give the user more agency with a row in the table that says “user defined”, like you see in many key description pages, such as shop=*. I think this would be a better outcome than encouraging someone who has discerned an unusual marking pattern to fall back to an unassuming yes, incurring immediate dataloss.
You mention that depending on local legislation, the marking style may lead to different implied restrictions. As long as there is no documentation in the wiki on which markings imply which restrictions per legislation, the tag has no useful purpose other than for rendering.
For countries in which there is only one (legal) crossing road marking, the quest should not be shown at all. For others, only those road markings which actually exist should be selectable. As long as this information is not documented comprehensively in the wiki (or something), this cannot be implemented as a quest.
A new issue or this issue can be reopened if such documentation has been done.
So gathering such info can be done by anyone who wants such quest to exist.
In Greater London alone, we’ve got 1400+ crossings tagged with crossing=marked + crossing:markings=yes. The second tag gives no useful information to anyone.
I was under the impression that crossing=marked was recommended to be replaced with crossing=uncontrolled + crossing:markings=*, but recently there’s been corporate mappers in Toronto changing it back to crossing=marked (while keeping the crossing:markings, which usually has a value more specific than =yes) so I don’t know what the idea is anymore
In addition, iD also recommends to add crossing:markings=yes to a crossing=marked and when picking the marked crossing preset (which is crossing=uncontrolled), it’ll also automatically add crossing:markings=yes so SC isn’t solely to blame here.
I disagree with that one because “no” is still a valid answer to “What kind of markings exist at this crossing” but moreover, there are quests with similar questions such as the type of kerb at a highway-barrier=kerb intersection or (an even more sound analogy) the type of ramp of steps (SC never asks you to first say there is a ramp to the user and then the specific type but rather ask for the type directly).
The subtext is a hope among some mappers and developers that crossing:markings=yes will come to replace crossing=marked (and crossing=uncontrolled, to the extent that it means the same thing), but everyone’s handling crossing=* with kid gloves because of the mappers who still insist on using crossing=zebra to mean the same thing as crossing=marked (as opposed to what is meant by crossing_ref=zebra).
The timeline is more or less correct, if not the details:
because of the mappers who still insist on using crossing=zebra to mean the same thing as crossing=marked (as opposed to what is meant by crossing_ref=zebra).
actually I use crossing=zebra for zebracrossings, and I insist it’s not the same as crossing=marked because this would be any marked crossing. In my area, crossing=marked with crossing:markings=zebra could be seen as synonymous, but also unnecessarily convoluted.
It’s crossing=* that makes things convoluted - trying to cram a combination of markings (crossing:markings=*), signals (crossing:signals=*), signage (crossing:signed=*), and local laws into a single tag is the source of the problem.
We have the tags for the individual objective and on-the-ground-surveyable features/properties, so let’s use them!
On-topic: I would argue that *=unknown is (almost?) always wrong and worse (or at least, not better) than just not having the tag at all.
crossing:markings=yes is a fine tag and communicates useful information as it is.
I don’t like that some tags use *=yes as an “end point” in refining the key, others use *=yes as a branching to another key for further refining, and others directly replace the *=yes value with the refinement.
Regardless, crossing:markings=yes is not a problem and crossing:markings=unknown is not a solution.
note on message tone
(My post’s tone here feels harsher than I want it to be - I think it’s great to have more conversations about pedestrian infrastructure mapping and to throw out new ideas, so please don’t take this as a rude “shutting down” of your idea or the discussion )
I wasn’t trying to single you out. If a migration to crossing:markings=*, crossing:signals=*, and crossing:signed=* works out, then it would become feasible for you to use crossing=* to encapsulate whatever aspects you want without creating any issues of consistency or ambiguity, but until then, crossing_ref=* exists for any miscellaneous considerations or regional classification systems. In my personal opinion, crossing:markings=* should be a welcome development for anyone who has taken issue with crossing=marked because it preempts crossing=uncontrolled. It’s a worthwhile tradeoff for long-needed expressiveness and clarity over a modicum of concision.
)