We have released v1.0 of Itinero! Get it now via nuget or check github. We are very proud of this and we tried to limit features to get to v1.0 fast but we could have done better, this release contains a lot of new stuff when comparing with the state of the project back when it was called OsmSharp.
An overview of some of what we chose to include in this release:
We support all the classics like Dykstra, A* but also Contraction Hierarchies. We expanded all these to enable support for edge-based routing and advanced turn restrictions. This means we use a modified Contraction Hierarchy at the core of the routing engine.
Using lua, a scripting language, we can support a wide range of routing profiles. Users of the Itinero can configure almost any vehicle type. We also support using cycle networks or any OpenStreetMap route relation type.
We include some default OSM-based profiles:
Originally the concept of a routing database, or RouterDb, was introduced because preprocessing source data can take a while and we don’t want to repeat this process every time we want to use the routing engine. As a side effect however it has proven to be very useful to separate the data processing from the actual routing code.
There is no dependency on the type of source data used meaning everything is configured in the RouterDb. Even the vehicle profiles are in the RouterDb. No dependency on OSM or a shapefile reader is required, no other dependencies are required to support different vehicles either, and the process of building a routerdb can be done in a separate process.
To read more about the RouterDb concept, check the docs.
Anything Itinero can do is also possible on mobile devices using Xamarin. We use a very simple type of memory mapping. This enables Itinero to load a RouterDb by opening it but not loading it entirely into memory. Routeplanning is obviously slower but still gives you very good offline routing performance on mobile devices.
This project was originally focused on logistical optimization. That’s still partly the case and this is why we also decided to include advanced support for usecases in this domain in the initial release.
One of these features is a very fast matrix calculation algorithm, that supports:
All this enables advanced logistical use cases and optimizations where there is a need for distance and time constrains at the same time or where there is a need for U-turn prevention.
In addition to traditional support for OSM-XML and OSM-PBF files as a source of data, we also support using shapefiles. Most proprietary networks are delivered in this form.
We implemented the concept of shortcuts. This was to support basic and static intermodality support for for example a bike-sharing system. We figured if the bike locations are fixed, so are the shortcuts. We can add these shortcuts to the RouterDb, introduce a bike-share vehicle profile, and include this in a Contraction Hierarchy.
This results in lightning fast routingplanning for a combination of walking and cycling for example. No reason this cannot apply also to a car-sharing scheme or anything else with fixed shortcuts.
The main usecase we target at the moment is using Itinero as a library. To get started check out the core project on GitHub:
Alternatively get started you can try setting up Itinero as a service using the routing-api project:
Even though we included a lot already, there are many more ideas for the future. We put up a roadmap with some future ideas, the most important being:
See something you can use, want your ideas or usecase on this list or are you interested in getting support for Itinero get in touch, it’s what we do!