Update rendering of `crossing=uncontrolled` way to match `crossing=marked`

[kallejre]

Description

In late 2022, https://github.com/openstreetmap/id-tagging-schema/issues/408 and https://github.com/openstreetmap/id-tagging-schema/pull/590 changed the marked crossing tagging preset from crossing=marked to crossing=uncontrolled.

However, iD’s rendering has not caught up with this change. Currently uncontrolled crossing is rendered at lower contrast, which inadvertently suggests the tag is discouraged (see the reasoning discussed in https://github.com/openstreetmap/iD/issues/2327 though that discussion focused on path vs. cycleway). I suggest updating the rendering of uncontrolled crossing ways to use stronger contrast, ideally matching the style of marked crossings.

PS. On second though, I also propose reopening https://github.com/openstreetmap/iD/issues/8290 as iD now supports traffic signals. Additionally maybe unspecified crossing (highway=footway;footway=crossing) could use same style as uncontrolled and traffic_signals currently use.

LLM disclaimer: I used one to search and summarise older issues and PRs, but issue is written mostly manually with AI refinement.

Screenshots

Current rendering of different kinds of pedestrian crossing in iD 2.35.3

[tordans]

Also Ping https://github.com/openstreetmap/iD/pull/10256 which shows how hard it is to come up with a good system of styles that looks good and makes sense/is easy to understand.

[k-yle]

to me, it seems like a good idea to unify the style for all crossing values. because crossing=* is slowly becoming less relevant, and the emerging tagging schema (crossing:markings) has an non-finite number of values which we can't style individually.

Currently only marked and unmarked have dedicated styling. Perhaps all crossings could use the marked style? (which might change again in #10256)

[tyrasd]

My first though was that there is some merit in distinguishing unmarked crossings from definitely marked crossings (regardless of the type of markings), and maybe those two cases from the case where it is unclear if a crossing is marked or not.

But on the other hand, this is already a relatively specific detail that we would need to accommodate alongside other attributes of the "paths" infrastructure. For other ways we are much less detailed (e.g. roads just get a width/color by their primary tag and then different sub-styling depending on bridge/tunnel tags). Simplifying the main map style for "paths" would make the map style simpler and easier to maintain. #11189 would offer a solution for mappers who focus on mapping this kind of data often and benefit from the styles to make their work efficient.

So 👍 from my side to unify the styling

[kallejre]

Ultimate goal to resolve by opening this issue was to reduce number of clicks needed when (re)mapping or verifying junctions with different types of crossings. Take a look at the image below, what kind of crossings does this junction contain? Here's a junction with traffic signals, where i believe rendering differentiation could be beneficial. Despite having crossing=traffic_signals on all crossing nodes (except one),

This image shows 5x crossing=traffic_signals (all nodes), 2x uncontrolled (1 way and 1 node), 1x marked (way) and 2x zebra (ways). Only way to find it out is to interact with every crossing way (hover or click). In reality, all of them are controlled with traffic signals. This was example created for illustration, real junction is mapped bit differently.

I must admit i have been less involved with tagging standards for past 2-3 years and these recent crossing:*=* developments are bit unfamiliar to me. They may provide more flexible way to describe crosswalks, but on downside figuring out informative rendering rules will be more difficult.

PS. I came up with query to find crossings where way and node have different crossing=* value. This is kind of like workaround of this issue for me.

[out:json][timeout:180];
{{geocodeArea:Tallinn}}->.a;

/* Ways that explicitly have crossing=* */
way(area.a)["crossing"]->.ways;

/* Loop each way as .parent */
foreach.ways->.parent
{
  /* crossing=* nodes of parent, but
     with different crossing value */
  node(w.parent)["crossing"]
    (if: t["crossing"] != parent.u(t["crossing"]))
    ->.badnodes;

  /* Output if there is at least one mismatching node */
  (.badnodes;)->._;
  if (count(nodes) > 0)
  {
    .badnodes out tags geom meta; /* the mismatching node(s) */
    .parent   out tags geom meta; /* the parent way */
  }
}

[maro-21]

I'm copying what I independetly wrote about this issue in a separate thread:

Previously the standard preset for marked crossings was highway=footway + footway=crossing + crossing=marked. This is still in use, but currently used is highway=footway + footway=crossing + crossing=uncontrolled. There are two things I want to mention:

• The rendering of a line with crossing=uncontrolled is the same as for any value - no dedicated rendering. But we had a dedicated rendering for crossing=marked.
• When I have a preset highway=footway + footway=crossing and I choose crossing=uncontrolled from the list, iD doesn't suggest to add crossing:markings=yes, but it does when I choose crossing=marked.

Correct me if I'm wrong, but I think the things we had for crossing=marked, i.e. rendering and tagging suggestions should be moved to crossing=uncontrolled:

• swap rendering of a line with crossing=marked to crossing=uncontrolled;
• add suggestion to add crossing:markings=yes also for crossing=uncontrolled.

[1ec5]

add suggestion to add crossing:markings=yes also for crossing=uncontrolled.

If so, maybe it should be a blue suggestion instead of a yellow warning. For better or worse, mappers in English-speaking regions historically didn’t consider crossing=uncontrolled to imply that the crossing is marked, at least until crossing=unmarked was approved a few years later. Also, crossing=uncontrolled still doesn’t necessarily imply anything about markings on a railway=crossing or a *=crossing way that intersects a railway. Either way, the user needs to exercise more care when setting crossing:markings=*.