-
Notifications
You must be signed in to change notification settings - Fork 71
Roadmap
This is an overview of features that are either in development or on the roadmap:
This contains some ideas on some non-breaking extensions on top of v1.0.
- Meta-data on vertices: More details here.
- Add a weight matrix calculation algorithm that calculates edge->edge weights excluding the source-target edge weights.
- Check to see if the current edge-based matrix algorithm can be replaced by this more general case.
-
PLANNED: Constrained routing: Routing with constraints like weight limits or vehicle size (width and height).
-
[PLANNED] Destination-only access: Handle access constraints where there is destination only access, also when using contracted graphs.
-
Support for dynamic weights per edge, for example to handle floating car data.
-
Elevation profiles: Output height profiles of calculated routes.
-
Elevation-aware routing: Routing that takes into account elevation. Think avoiding steep hills for bicycles.
-
No-go areas or maximum speeds based on areas: https://github.com/itinero/routing/issues/19
-
Alternative routes.
-
Map matching.
-
Reevaluate lua for instruction generation of fix performance issues.
-
Remove nullable booleans to describe directional information.
A collection of general ideas that may or may not end up on the final roadmap.
Just return geojson with all details included:
- Edge with start and end vertex.
- The location on the network.
- The original location.
Do something like Result<Route> TryCalculate(source, target, sourceForward, targetForward). The resulting route must leave and arrive in the same direction as the given flags.
There already is a method to do this with edges: Result<EdgePath<T>> TryCalculateRaw<T>(IProfileInstance profileInstance, WeightHandler<T> weightHandler, long sourceDirectedEdge, long targetDirectedEdge, ...). This still should have it's use but it's definition needs to be refined for the case where it's input for source and target is the same edge. The actual route in that case depends on the original routerpoints but we need to make a choice here. The best option would be to return a route that leaves the edge and arrives again at the other end. The above method could then be built on top of this one.
[29-04-2017] Thinking about this some more this is now considered to be a bug: https://github.com/itinero/routing/issues/96 The original idea of adding the new extension method is still unplanned.