Traffic volume matching causes strange reachability results

[dabreegster]

The red dot is a school, marked as unreachable, despite a segregated track on the road right by it. Why? Opening the reachability layer shows: The school snaps to the closest road, https://www.openstreetmap.org/way/400410117, which is a service=parking_aisle.

Question 1: Should such roads be part of the editable network in NPW at all? I think yes, because there might be a service road that a user could repurpose to be part of a route someday.

Why is this parking aisle marked unreachable? Because of the level of service layer: It's a medium LoS, so it's considered a severance for reachability purposes. The traffic volume is 2135 vpd, which comes from snapping the nearest line from the volume gpkg:

That snapping process looks fine here -- the lines are close by and nearly parallel, so this is the most reasonable fit.

But in this case, clearly the vpd on Dunlop Street shouldn't be assigned to this parallel service road.

Question 2: What should we do to assign a vpd to this service road?

• Based on highway=service, have some hardcoded value? Always assume the LoS is high?
• Make the snapping stricter and also check if road names match? I worry about this, because the OSM / OS names might differ a bit; not sure how hard it'll be to get a good fuzzy match. And sometimes legitimately the name might be missing or different between the two datasets.

Any ideas @juanfonsecaLS1 or @Robinlovelace? Thanks!

[dabreegster]

Question 1: Should such roads be part of the editable network in NPW at all? I think yes, because there might be a service road that a user could repurpose to be part of a route someday.

Or maybe not; the user could draw new freehand routes if they really need to, and recreate the exceptional case when a service road needs to be part of the network. More generally, we need to decide which OSM ways to include in NPW. It's different than the cycle_net in osmactive, because edges are editable; something unsuitable today could be part of a plan and made suitable. But for every edge we include, we need to assign vpd and a level of service before any edits. I've been going back and forth whether to include footways and paths in https://github.com/nptscot/npw/blob/b1aaa04b1f23a3f5d244716935ba54cb8c3b7d1a/backend/src/existing.rs#L13 (with unit tests farther down in that file).

Question 3: When the user draws new freehand routes, what vpd and level of service do we assign them? If it's marked as a totally new off-road link, that's easy. But if it's a new line parallel to a big road, it's less clear. If the freehand route is meant to represent an existing service road or other thing that we choose to exclude, it's even less clear.

CC @mvl22 too for opinions

[Robinlovelace]

Question 1: Should such roads be part of the editable network in NPW at all?

Agreed, yes.

[Robinlovelace]

Question 2: What should we do to assign a vpd to this service road?

* Based on `highway=service`, have some hardcoded value? Always assume the LoS is high?

* Make the snapping stricter and also check if road names match? I worry about this, because the OSM / OS names might differ a bit; not sure how hard it'll be to get a good fuzzy match. And sometimes legitimately the name might be missing or different between the two datasets.

Assuming it's high sounds like the simplest and easiest-to-explain approach. Simplicity and ease-of-explanation priorities ATM I think and would would work for this use case, and others I suspect. Great to see this level of detail in the question, thanks for setting it out clearly.

[Robinlovelace]

Question 3: When the user draws new freehand routes, what vpd and level of service do we assign them?

Can it depend on the type of infrastructure they have chosen it to represent?

[Robinlovelace]

Additional point of regarding 'vpd': motor traffic levels are a lot less relevant after infrastructure has gone in. I guess it's the before/after comparison that's important here, and if they are new routes there will be no 'before'. So if I had to pick a number 0 would be my first thought: hopefully the new infrastructure will be good enough as to feel traffic free.

Suggestion on name: refer to it as Annual Average Daily Traffic (motorised) not 'vpd' for consistency.

[dabreegster]

Thanks for the ideas! For now, I'll try an override rule to mark all highway=service as high LoS, keeping an eye out for any exceptions that might come up. Agreed that the LoS of totally new edges can depend on the infrastructure type. It maybe makes little sense to allow options like Mixed Traffic for new edges.

[mvl22]

all highway=service as high LoS

I'll add highway=service to the list of weightings values to generate. Sorry, this should be done soon; just working through a backlog.

I think off-hand we give it a fairly low/middle scoring, because service roads tend to be either:

• Very local private-ish bits of road that are often badly surfaced and generally scrappy; or
• Subject to lorries and vehicle movements in sporadic ways.

[Robinlovelace]

I think off-hand we give it a fairly low/middle scoring, because service roads tend to be either:

* Very local private-ish bits of road that are often badly surfaced and generally scrappy; or

* Subject to lorries and vehicle movements in sporadic ways.

Neither of which will apply for new infra, so high LoS save to assume for edits.

[dabreegster]

I'll close this, since the original problem is fixed. You can now hover on any POI to either see a path from it to the current network (if it's reachable) or the reachable roads around it, the severances hit, and how it's impossible to reach the current network.