Angel Island paths/roads not navigable

[graue]

The router thinks the paths and roads on Angel Island are all unnavigable, which is causing absurd results where the Angel Island ferry terminal is snapping to a road in Tiburon, making it recommend getting to Tiburon by using the Angel Island ferry then teleporting over the water.

Routes within Angel Island either 500 or give absurd results.

Most paths in Angel Island seem to have highway=footway while the roads have motor_vehicle=private, foot=yes, bicycle=yes. This should be navigable for us.

[graue]

Figured out why some attempted routes within Angel Island give 500s: this line calls legs.get(-1), because there are zero legs for the trip, presumably because the start and end point both snap to the same location (on Tiburon rather than Angel Island).

It is weird that we don't have a check for that rather than crashing, but points to the fundamental issue being that we won't snap to points on Angel Island.

[graue]

I've yet to find an explanation why the router isn't snapping to points on Angel Island, but here's what I know:

This way, "Perimeter Road," is tagged:

highway=unclassified ("minor public roads, usable by motor cars")
motor_vehicle=private
bicycle=yes
foot=yes

The SnapPreventionEdgeFilter does not filter out highway=unclassified, and the implementation in BikeCommonFlagEncoder#getAccess should allow this, because the encoder calls setHighwaySpeed for "unclassified", this way explicitly allows bikes, and also because even if it didn't, restricted values for motor_vehicle shouldn't be checked.

This way running alongside North Ridge Trail is tagged:

highway=track
motor_vehicle=no
motorcar=no
motorcycle=no
bicycle=designated

Again, highway=track shouldn't pose a problem for snapping or access, and those access tags should be fine for BikeCommonFlagEncoder#getAccess.

As for this footway, I thought we were not snapping to it because of #148. We should probably rethink #148, which will prevent snapping to this footway, which has no parallel road alternative, and explicitly has bicycle=yes. We should probably only prevent snapping to footways if they have footway=sidewalk (cc @rsarathy). However, even that isn't sufficient to explain this behavior. I commented out snap_preventions: footway in the bike2 profile in my config, rebuilt my graph cache, and it still won't snap to this footway.

I also don't see any enclosing feature on OSM that has restricted access (for example, if the whole of Angel Island State Park were tagged access=private or some weird access value... that's not the case).

[abhumbla]

does the router drop edges that aren't connected to the rest of the graph? it shouldn't, that's what nom-GTFS ferry edges are used for

[graue]

Oh, excellent question. A bug where the router is failing to follow the ferry edges, and therefore dropping these edges for not being connected to the rest of the graph, seems like a plausible hypothesis. Worth looking into.

There is a ferry edge, and the Angel Island ferry terminal is connected to the other roads/paths on Angel Island by a highway=footway (with bicycle=dismount).

[graue]

Okay, I've found the cause. Because of #85, which made the bike router ignore ferries, Angel Island's roads and paths are considered to form a small, disconnected "subnetwork" for the purposes of the bike router¹, which is then ignored for bike routing.

It's not immediately clear what a correct fix would be, but maybe revert #85 (or configure use_ferries to true, which requires the bug fix #168 to be merged), and address that issue in a different way. In principle, we should still use ferries for 'bike2' routing, just not for 'pt' routing with 'bike2' as the connecting profile.

1. But they are still in the graph and can be used for foot routing.

[abhumbla]

agreed, I think we should fix this in the PT routing section of the code, we shouldn't exclude Angel Island from the bike graph