Exclude ways with access=private or have access=no and do no explicitly allow bicycles

[mitchellhenke]

Pull-Request

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to
  change)
• Code cleanup / Refactoring
• Documentation
• Infrastructure and automation

Description

This change proposes adding additional exclusions for ways that have access=no or access=private to close #840. The exclusion exists for footways currently, but not other ways. I think it's probably correct and minimally impactful to add the exclusion to every case.

In running analysis for Madison, WI after applying this patch, the private path (1309414435) that was part of the report in #840 is shown crudely highlighted is now not part of the network as expected:

Checklist

• I have updated the documentation accordingly
• I have updated the Changelog (if applicable)

Fixes: #840

[rgreinho]

I am a bit wary of using access=no as I discovered this while working with OSNMX:

Filter for the OSM “access” tag. Default is [“access”!~”private”]. Note that also filtering out access=no ways prevents including transit-only bridges (e.g., Tilikum Crossing) from appearing in drivable road network (e.g., [“access”!~”private|no”]). However, some drivable tollroads have access=no plus a access:conditional tag to clarify when it is accessible, so we can’t filter out all access=no ways by default. Best to be permissive here then remove complicated combinations of tags programmatically after the full graph is downloaded and constructed.

source: https://osmnx.readthedocs.io/en/stable/user-reference.html#osmnx.graph.graph_from_place, for the default_access: str argument

Shall we just filter with access=private then? This sounds reasonable to me. But maybe finding a slightly more complex logic, as OSMNX recommends, may provides better results? 🤔

[vgXhc]

Seems like the Tillikum crossing example isn't really relevant. The bike paths are mapped as separate ways, and the transit portion of the bridge shouldn't show up in the "drivable road network" nor in the BNA. I'm not sure about the toll roads.

There's probably more merit to account for cases when people tag access=no (or private) and then add bicycle=yes (or permissive/dedicated/whatever) to tag a bike-only or bike/ped-only way. This is not uncommon So filtering only by access=no is probably too coarse. It'd be something like access=no AND !bicycle=(yes|permissive|designated)?

[mitchellhenke]

Based on the above, I've added a commit so that the following ways are included:

• access is not defined
• access is not private or no
• access is no and bicycle=(yes|permissive|designated)

As an overpass query, it would be something like:

way[!"access"];
way["access"!="private"];
way["access"="no"]["bicycle"~"permitted|designated|yes"];

The (fixed) inverse query of ways that would be excluded:

way["access"="private"];
way["access"="no"]["bicycle"!~"permitted|designated|yes"];

[vgXhc]

I think the overpass link for the inverse query got messed up. Here's what I think is the correct one. https://overpass-turbo.eu/s/23po

I took a quick look at what would be excluded in my area and it correctly removes the way that prompted the initial bug report. Other removals all seem to be correct -- I didn't see many false positives, and those were based on incorrect/dubious tagging. Most of the true negatives probably would have previously made it into the analysis as low stress -- stuff like highway=service service=driveway with an explicit access=no and the like. So I think this is good!

[lalver1]

We went over these changes and they make a lot of sense, thanks! We'll approve this PR soon to get it merged, we just want to make sure that the documentation on our end is updated (if needed) and that this change does not conflict with anything else in the methodology.

[mitchellhenke]

Thank you! If there's anything else I can update for this, just let me know.

[lalver1]

👍