dabreegster
commented
6 months ago 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 havehighway=primaryor 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 calculateltsfirst, 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
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.