Plan to release the GraphHopper routing engine 1.0

We plan to release 1.0 in the next 2 or 3 weeks. You can try the pre-release 1.0-pre40 already. Please let us know if you have problems or if documentation is incomplete.

Every release had always several contributors. Now we moved from version 0.13 to version 1.0 and for no other version so many contributors were involved - thanks a lot! Without your work GraphHopper would not be possible:

easbar, michaz, msbarry, boldtrn, karussell, oflebbe, otbutz, Janekdererste, sguill, samruston, aoles, don-philipe, ratrun, taulinger, naser13, HarelM, twitwi, Anvoker and devemux86.

The biggest new features are:

  • A new approach to query GraphHopper using a JSON query. Without knowledge of Java you can now tweak the vehicle profiles to avoid bridges, motorways, ferries, steps or certain areas. Or avoid roads with truck limits or change the speed or max_speed variables. You can also prefer official bike routes or tweak your bike profile towards a cargo bike. And many more features. See the documentation, issue #1841 and this blog posts. From @karussell and @easbar.
  • A major code refactoring that includes turn costs calculation in the Weighting from @easbar. See our changelog.
  • A major refactoring towards profiles that replaces weighting and vehicle from @easbar. This requires a configuration changes. For the most cases you can use our converter tool. See the documentation.
  • Alternative routes now also for node and edge-based Contraction Hierarchies #1722 from @michaz
  • Isochrone refactorings and improvements like turn restriction support from @michaz. See e.g. #1824.
  • Add new 'curbside' parameter #1697 to approach roads from a specific side from @easbar
  • Bilinear interpolation for elevation #1942 from @msbarry
  • Many changes and improvements for spatial rules from @otbutz
  • Updates to our iOS port graphhopper-ios#47 from @oflebbe
  • Several bug fixes for Landmark algorithm from @michaz and @aoles
  • a new POST /route endpoint, additionally to GET /route, avoiding URL-length limitations, request compression and more from @karussell
  • More encoded values like EU tunnels, hazmat etc from @otbutz
  • A new vehicle profile wheelchair #1726 from @don-philipe
  • Many bug fixes to the block_area and the country feature from @karussell
  • A big improvement to reduce the memory requirement for the import. Mainly from @msbarry
  • A new user interface for public transit from @Janekdererste and @michaz
  • Improved turn instructions like #1882 (or this) from @boldtrn
  • A good speed improvement for path details from @easbar
  • Turn instructions give now hints about ferries, tolls and private roads
  • Upgrade to Dropwizard 2.0
  • Several changes to reduce FlagEncoder usage.
  • Start to use JUnit5 in tests from @Anvoker and @easbar
  • A StringIndex allowing to store strings per edge that will allow several improvements for turn instructions in the future

Fantastic work everyone and thank you so much for your time and expertise to implement these additional features and improvements!


One question so far:
Encoding manager is created in GraphHopper, from a builder. Inside tagParsers, turnCostParsers and relationTagParsers are created.
I have my custom consistency validity check, which persist some most important features of EncodingManager with his FlagEncodersā€¦
And I noticed that those mentioned above are released when graph parsing is finished - only in OSMReader.finishedReading(). I would assume this is a bug, because finishedReading is called only in writeOsmToGraphā€¦ so as a result those parsers are cleaned only after first graph reading and writing - those are still present when you recreate existing graph.