Input: GeoJSON lines representing trips from A to B. They might have arbitrary properties, usually representing something like number of people doing that trip, broken by mode. This comes from some kind of travel demand model / jittering process.
Final output: Segments in the route network with aggregated properties. A segment should never be "longer" than an original OSM way, but it'll often by "smaller" (between two nodes in the way).
The routing implementation should be pluggable, letting us quickly swap out Valhalla, OSRM, OTP, etc running locally or remotely. The goal will be speed for big areas and inputs, of course.
Walking using the "most likely route somebody would pick assuming streets today" is the highest priority. Adjusting routing preferences and modifying the street network (making something nicer, drawing new bridges) would also be important.
Input: GeoJSON lines representing trips from A to B. They might have arbitrary properties, usually representing something like number of people doing that trip, broken by mode. This comes from some kind of travel demand model / jittering process.
Final output: Segments in the route network with aggregated properties. A segment should never be "longer" than an original OSM way, but it'll often by "smaller" (between two nodes in the way).
The routing implementation should be pluggable, letting us quickly swap out Valhalla, OSRM, OTP, etc running locally or remotely. The goal will be speed for big areas and inputs, of course.
Walking using the "most likely route somebody would pick assuming streets today" is the highest priority. Adjusting routing preferences and modifying the street network (making something nicer, drawing new bridges) would also be important.