More input to edge costs and LTS

[dabreegster]

• Fully separated cycletracks next to a motorway aren't great. Maybe just project perpendicularly (or buffer and look for overlaps) and check the speed / classification of the parallel road. https://www.openstreetmap.org/way/153773332
• Separated paths through greenspace can sometimes be nice, but may be uncomfortable at night. https://www.openstreetmap.org/way/933851270
• Similarly, industrial land use as the surrounding thing may feel uncomfortable. https://www.openstreetmap.org/way/166148979

For all of these, I think we could first just detect this situation about the edge (and surface that info in the UI clearly). Then we can write edge cost and LTS functions that take these things into account, using TBD weightings.

And a further idea: local knowledge (or routing preference) is always going to be helpful. If we have a way in the UI to just annotate a road and edit the LTS / edge cost manually, then that could be super helpful.

[dabreegster]

Elaborating a bit... we heard feedback about some of the LTS ratings. https://www.openstreetmap.org/way/153773332#map=18/53.46591/-2.83879 is a great example -- this is a separated path next to a highway. Although the separation from fast-moving traffic may be adequate, the noise / general experience from being next to traffic is unpleasant. Somebody using od2net might want to adjust the LTS or cost function accordingly to still penalize this. So some steps would be:

• Add a new field to Edge to represent this situation. Maybe we can start simple, next_to_motorway: bool
• In create_from_osm, fill this out for every edge. A simple approach here would be geometric -- buffer a linestring around the edge, then see what other edges match and are roughly parallel. If those other edges have highway=primary or a certain maxspeed, then set to true. We'll probably need to make these rules configurable eventually, but we don't need to at first. Or maybe we could calculate lts first, then look at the LTS of the parallel nearby roads.
  • To find the nearby roads, instead of buffering the edge, we could instead just project a line perpendicular to the edge and look for intersecting edges. Maybe we just use one perpendicular line in the middle of the edge to start.
  • Buffering linestrings in rust isn't really possible yet, without patching in some PRs in dependencies. https://github.com/dabreegster/spatial_join_tests/blob/f05062331886fc4a358e7af5629477d36cdecc17/rust/src/geo_utils.rs#L54 has some notes. The perpendicular check is probably simpler
• Plumb through this new field to the cost function
• Maybe start thinking through a way in the UI to debug this new boolean, so we can make sure it's marking the edges we expect. Kind of similar to steepness, maybe the "edge cost app" page should have more of a concept of layers?

The greenspace and industrial area ones are similar. There's already some code to try and extract greenspace_polygons, but it's only half-started -- I don't remember getting very far for verifying the output of it

@KDKasonde

[KDKasonde]

Sweet thanks for that, I will start having a read through this now!

[KDKasonde]

Hey @dabreegster, just looking at how to visualise the data but noticed the steepness is not included in the EdgeCostApp should I add it in or have I missed something? Also I am now not 100% sure I know what you by layers 😅

[dabreegster]

Apologies, got very behind on emails... Since there's a "Color edges by" selector, slope would be a fine choice to include for networks that have it. Not sure why I didn't wire that in originally.

EdgeCostApp looks broken right now in main with the default "Color by cost relative to length" selector, by the way -- I probably broke this at some point. I'll try and look into it at some point.

You can ignore what I said about layers in the edge cost app. There's already that "color by" dropdown -- we can use that to debug the new per-road info gathered.

[KDKasonde]

No worries at all it happens! And that makes sense I will get started on running my changes in that case.