Skip to content

Roadmap

Jump to bottom
Ben Abelshausen edited this page Jun 26, 2017 · 38 revisions

This is an overview of features that are either in development or on the roadmap:

Version 1.1

This contains some ideas on some non-breaking extensions on top of v1.0.

  • Add a weight matrix calculation algorithm that calculates edge->edge weights excluding the source-target edge weights. DONE
    • Check to see if the current edge-based matrix algorithm can be replaced by this more general case. DONE
  • And several other issues and ideas: Milestone for 1.1 DONE

Version 1.2

  • Meta-data on vertices: More details here.

Version 2.0 and beyond

  • Move to netstandard2.0 only.

  • Move to .NET core for the functional test project: development should be possible on any platform.

  • 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.

General ideas

A collection of general ideas that may or may not end up on the final roadmap.

Add a more efficient data structure to represent restrictions

Add extension method to turn a routerpoint into GeoJSON

Just return geojson with all details included:

  • Edge with start and end vertex.
  • The location on the network.
  • The original location.

Add extension method to calculate an edge-based route with forced directions:

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.

Clone this wiki locally