Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stop asking crossing detail for unmarked crossings #3394

Conversation

matkoniecz
Copy link
Member

this type of object is considered as crossing in OSM tagging, but not by many regular people
as result it can be a very confusing quest, see #3341

alternative solutions:

  • consider confusion as acceptable and require people to be aware about OSM classification (contrary to SC purpose and design)
  • explain somehow that it may be not exactly crossing as regularly understood
  • reword questions somehow to reduce confusion

Main negative effect here is that unmarked crossings may have a pedestrian island and tactile_paving data is useful also on unmarked crossings

this type of object is considered as crossing in OSM tagging, but not by many regular people
as result it can be a very confusing quest, see streetcomplete#3341

alternative solutions:
- consider confusion as acceptable and require people to be aware about OSM classification (contrary to SC purpose and design)
- explain somehow that it may be not exactly crossing as regularly understood
- reword questions somehow to reduce confusion

Main negative effect here is that unmarked crossings may have a pedestrian island and tactile_paving data is useful also on unmarked crossings
@andrewharvey
Copy link
Contributor

Main negative effect here is that unmarked crossings may have a pedestrian island and tactile_paving data is useful also on unmarked crossings

Exactly, according to https://taginfo.openstreetmap.org/tags/crossing=unmarked#combinations, 2% of crossing=unmarked have crossing:island=yes compared to 6% which have crossing:island=no.

Have we noticed if the confusion is coming more from some regions than others? Perhaps it could be disabled for problematic regions only?

@matkoniecz
Copy link
Member Author

Have we noticed if the confusion is coming more from some regions than others? Perhaps it could be disabled for problematic regions only?

It is 100% definitely confusing in Poland (heavily confirmed). I have seen notes indicating similar confusion in UK and USA where I am also monitoring StreetComplete notes. In other English-speaking countries note value is much lower, as result I am less sure.

Given repeated discussions/confusion among OSM mappers what is counted as crossing and what not - I am expecting this confusion to be widespread across regions. But I am not sure about this.

@westnordost
Copy link
Member

I am with @andrewharvey here. I actually planned to create a PR to exclude highway=crossings that are on highway=service (except service=alley or more?) so it should exclude the worst offenders, i.e. those "crossings" where usually a driveway just crosses the sidewalk.

@westnordost
Copy link
Member

The other common type of maybe-non-crossings are just intersections in a residential area where the sidewalk has been drawn as a separate way, so the sidewalk highway=footway crosses the street and often a highway=crossing is tagged on this node. IMO this is still a crossing through but opinions differ. At least what is useful to record is whether the kerb here is lowered or not. If it is lowered, it is worth asking if there is tactile paving and if there is an island.

So maybe maybe maybe, we could

  1. only ask for tactile paving and island on crossing=unmarked if it also has kerb=lowered (or similar) tagged
  2. start asking for the kerb height (kerb=*) at all highway=crossing, i.e. not only these (vertex of a road, sidewalks are tagged on the road) but also those (vertex of an intersection of a road and a crossing footway). Currently, StreetComplete does not set the kerb height property on the crossing node, but at the location of the kerb (barrier=kerb)

@matkoniecz
Copy link
Member Author

IMO this is still a crossing through but opinions differ.

I agree that it is crossing - the problem is that people consistently got confused when asked about crossing detail there.

Maybe for crossing=unmarked show extra info about this?

@arrival-spring
Copy link
Contributor

  1. start asking for the kerb height (kerb=*) at all highway=crossing, i.e. not only these (vertex of a road, sidewalks are tagged on the road) but also those (vertex of an intersection of a road and a crossing footway). Currently, StreetComplete does not set the kerb height property on the crossing node, but at the location of the kerb (barrier=kerb)

The problem with this is it can sort of make it look like there's a kerb on a road. i.e. from the perspective of the road there is a node tagged with kerb=*. Where there is also highway=crossing data consumers could/would assume that the kerb property belongs to the crossing, but I'm not sure if they do.

In fact, this is what the add crossing quest does already (add kerb=* on a node in the middle of a road), and I'm not so sure about that, but it may well have been discussed somewhere and I missed it. I don't think it matches accepted usage of the kerb tag. See the wiki.

@westnordost
Copy link
Member

westnordost commented Oct 17, 2021

The problem with this is it can sort of make it look like there's a kerb on a road

kerb=* is not a primary map feature but a property - of either a highway=crossing or a barrier=kerb. Data consumers that are looking for barriers (should) look for barrier=*. As far as this tag is defined, there is no issue, it is quite clear.

I don't think it matches accepted usage of the kerb tag. See the wiki.

Yes it does. Citation from the wiki page you linked: "[...] If the kerb is identical on both sides of a crossing, it is possible to add the kerb=* tag to the highway=crossing node, which sacrifices accuracy for simplicity [...]"

The (only) issue there is with this is that it is essentially duplicate information where it is tagged like this:
image
On the other hand, if this is done, then we can avoid tagging tactile_paving, crossing:island (and crossing=unmarked depending on what exactly we filter) on every single of those "non-crossings" because we can bail on asking any more questions if kerb=raised/none or similar.

@matkoniecz
Copy link
Member Author

then we can avoid tagging tactile_paving, crossing:island (and crossing=unmarked depending on what exactly we filter) on every single of those "non-crossings" because we can bail on asking any more questions if kerb=raised/none or similar.

It is worse. Most of "it is not a crossing at all" that confused people had lowered curb.

@westnordost
Copy link
Member

It is worse. Most of "it is not a crossing at all" that confused people had lowered curb.

Hm, okay

@westnordost
Copy link
Member

Then I propose:

  • do not show tactile paving + island + ... quests for highway=crossing if it is crossing = unmarked ( and (!kerb or kerb~no|flush) and (!tactile_paving or tactile_paving=no)) and a vertex of a highway=service
  • refer to a crossing = unmarked using different wording

@matkoniecz
Copy link
Member Author

do not show tactile paving + island + ... quests for highway=crossing if it is crossing = unmarked ( and (!kerb or kerb~no|flush) and (!tactile_paving or tactile_paving=no)) and a vertex of a highway=service

So crossings in highway=service with kerb=no/flush or crossing and crossing!=unmarked would be shown?

And crossing=unmarked on highway=residential questions would be shown, but with some different wording?

@westnordost
Copy link
Member

So crossings in highway=service with kerb=no/flush or crossing and crossing!=unmarked would be shown?

No. crossings on highway=service that have either e.g. kerb=raised or crossing!=unmarked would be shown.

And crossing=unmarked on highway=residential questions would be shown, but with some different wording?

Yes. That is my suggestion.

@matkoniecz matkoniecz closed this Oct 22, 2021
@matkoniecz matkoniecz deleted the crossing_unmarked_not_recognized_as_crossing branch August 22, 2022 11:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants