SC adds redundant tags to intersection mapped in high detail

[apophenic-treehugger]

On intersections that are mapped in high detail (especially those with traffic lights), SC creates quests that lead to redundant tagging for pedestrian crossings and traffic lights.

Context in which the issue appears
See for example this path and the intersection that it is part of: https://www.openstreetmap.org/changeset/107474301

• The path is already tagged as "crossing".
• It has traffic lights mapped on either end.
• The crossing carriage way for motor traffic also has its traffic light mapped separately.
• The fact that the intersection is mapped in high detail means that no traffic light is mapped at the crossover node between the pedestrian crossing and the motor traffic carriage way. This is not a mistake.

Current behaviour:
In situations like this, SC falsely creates quests for the crossover node to ask the user for features like traffic lights, tactile paving and kerbs. (which is great, in principle!)
However, SC wrongly adds the new tags to the node where the road and the pedestrian crossing intersect (which would be correct on intersections that are mapped in low detail).

Expected behaviour
In cases where traffic-light regulated intersections are mapped in this detail, no tag at all should go to the node where the road and the pedestrian crossing intersect.

• The tags crossing=traffic_signals and tactile_paving=* should go on the path.
• The tags kerb=* (together with barrier=kerb), traffic_signal:button_operated*, traffic_signals:sound=* and traffic_signals:vibration=* should go on the two nodes at the end of the *=crossing path.

Negative implications of current behaviour

• frustration for desktop mappers since they put a lot of effort into mapping an intersection correctly and then SC comes along and adds wrong tags (mostly tags in wrong places, that is; often redundant to already existing tags in the correct place)
• frustration for SC users if the above desktop mapper has cleaned the intersection from SC's mapping and the SC user finds themselves again confronted with quests they have already solved in the past.

Proposed solution
In principle, the SC quests are highly valuable, because they ask for things that can often not or only with great effort be determined by a desktop mapper: Are the traffic lights button operated? Do they make a sound? Is there tactile paving? What's the height of the kerbs?
However, the tags should be added to the correct nodes/paths. Since the false mapping is done by SC, the behavioural fix should be done on SC's side. In cases where SC has high uncertainty whether it's doing the right thing, it should be conservative and not do anything at all.
I can think of some refinement of SC's algorithm that would help in many situations that I have encountered:

• If the foot path that crosses the street has a footway=crossing, a cycleway=crossing or a path=crossing tag, then
  • create a crossing=* quest for the path, not the node.
  • create kerb=* quests not for the crossing node, but for the nodes at the two ends of the path. Don't forget to add the barrier=kerb tag in that case.
  • if there are traffic signal tags on any of the two end nodes of the path, add tags like traffic_signals:vibration=* traffic_signals:sound=* and traffic_signals:button_operated to these nodes, not to the crossing node.

This is just a coarse outline of an improved algorithm. If the SC developers agree to adopt it, I'd be glad to help with refining it.

[matkoniecz]

In cases where traffic-light regulated intersections are mapped in this detail, no tag at all should go to the node where the road and the pedestrian crossing intersect.
The tags crossing=traffic_signals and tactile_paving=* should go on the path.

Is it personal preference or some widespread standard?

frustration for desktop mappers since they put a lot of effort into mapping an intersection correctly and then SC comes along and adds wrong tags (mostly tags in wrong places, that is; often redundant to already existing tags in the correct place)

In which cases tags would be wrong?

[apophenic-treehugger]

Is it personal preference or some widespread standard?

It's the way it is documented and also the way that seems logical to me. I haven't made a survey of how widespread it is and I don't think my personal preference should matter a lot here.

[matkoniecz]

See https://wiki.openstreetmap.org/wiki/Tag:crossing%3Dtraffic_signals

Nearby can also be a traffic light (highway=traffic_signals) on another node.

Note https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Traffic_signals_for_cyclists

It is good practice to also tag the crossing but only with highway=crossing and crossing=traffic_signals.

apparently this was edited by people with contradictory ideas, and SC is following one of popular versions.

---

In addition, you claimed that in some cases tags would be wrong, not just repeat of info. Can you give an example? Or is it a mistake. No problem, mistakes happen - but I am especially interested in fixing outright bad data added by StreetComplete rather than cases of competing tagging schemas and StreetComplete following one of them.

[matkoniecz]

I opened https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dtraffic_signals#Separately_mapped_traffic_light_and_highway.3Dcrossing_.2B_crossing.3Dtraffic_signals to try resolve this issue.

Maybe discussing it on tagging mailing list or on other similar place would be also a good idea.

As it stands OSM Wiki is conflicted and no matter what will be done SC will follow one of pages, ignore another. Note that there is clearly no consensus so before editing either for preferred version more general community should be consulted.

(note that this specific page is a poor place to discuss preferred tagging schema - please do this on OSM Wiki, tagging mailing list etc)

[apophenic-treehugger]

Thanks. Much appreciated!