[OSRM-talk] OSRM 5.0.0 Released

Stephen Woodbridge woodbri at swoodbridge.com
Sun Apr 24 02:21:52 UTC 2016


On 4/23/2016 6:46 PM, Daniel Patterson wrote:
> Hi Steve,
>
>   You're probably remembering this
> ticket: https://github.com/Project-OSRM/osrm-backend/issues/483

Yes, that is the one, thanks! OK, I saw a bunch of comments about 
restrictions and turn penalties so I thought I would check on it as I 
would like to see it implemented.

>   We still haven't added support for this kind of restriction.
>
>   Support for the `via node` restrictions exists because it maps fairly
> directly to OSRM's internal data model.  All we have to do is remove the
> corresponding edge-based-edge identified by the edge-node-edge values.
>
>   For edge-edge-edge restrictions, we'll need a more complex graph to
> represent a restricted intersection.  Instead of just removing the
> restricted edge-based-edge, we'll need to replace the existing simple
> edges with a set of synthetic edges that represent the permitted
> routes.  This is quite a bit more involved than the current approach,
> and is the reason that nobody has tackled it yet.

I confess some ignorance in how these gets implemented, but in the 
simple model in my mind when doing Dijkstra, I would think that that 
when you are at a node in the graph and you are deciding which of the 
next nodes to evaluate, that if you had a restriction(s) for arriving at 
following node, then the restriction could be defined based on the path 
of arrival to that node.

So for example we can represent edge based restriction of say: AB,BC,CD 
as a path sequentially through nodes A, B, C, arriving at D.

So if we are at node C and the next node in the graph to be evaluated is 
D and D's parent is C, and C's parent is B, and B's parent is A, then 
you can not go to D and you evaluate the other following nodes if any 
that follow on from C.

But if you were at C and your parentage was say C, B, Z, then you could 
proceed to D, unless you also had a restriction for Z->B->C->D.

But I suspect that it is not this simple because of the contracted graph 
and you probably have to transform the intersection into some analogous 
representation that removes restricted paths through the intersection or 
something like that.

Regardless, thank you for your response, the issue number and 
explanation. It would be a nice feature to support if anyone is up for 
the challenge.

Thanks,
   -Steve

> daniel
>
> On Sat, Apr 23, 2016 at 2:09 PM, Stephen Woodbridge
> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.com>> wrote:
>
>     Patrick, et al,
>
>     Congrats! Nice job on a major effort to pull this release together.
>
>     I have one question, regarding turn restrictions. Last I knew, OSRM
>     only supported edge-node-edge restrictions and not a more complex
>     edge-edge-edge-... style restriction.
>
>     There used to be issue for this, but I can't find it now. Has this
>     been implemented and I just missed it? I believe there are cases for
>     this in the OSM data and I can provide some simple use cases if needed.
>
>     Thanks,
>       -Steve
>
>
>     On 4/23/2016 7:12 AM, Patrick Niklaus wrote:
>
>         Hey,
>
>         I'm proud to announce the 5.0.0 OSRM release. This is by far one
>         of our biggest
>         releases in terms of lines of code changed, since... a while. It
>         was a
>         real team effort featuring contributions from:
>
>         @akaiser, Aleksei Potov, Bas Couwenberg, Wilhelm Berg, Dane
>         Springmeyer, Daniel J. Hofmann, Daniel Patterson, David Low,
>         Johan Uhle, Jeff Miccolis, Karen Shea, Kerrick Staley, Lauren
>         Budorick, Lev Dragunov, Mathias Gug,
>         Michael Krasnyk, Moritz Kobitzsch, Mortada Mehyar and yours truly.
>
>         This release features a completely revamped API (both HTTP API
>         and C++
>         library), a completely new guidance generation engine,
>         replacing the Ruby based cucumber tests suit with its Javascript
>         sibling cucumber-js and various other improvements and fixes.
>         See the detailed changelog at the end of this post.
>
>         Checkout the new documentation:
>
>         https://github.com/Project-OSRM/osrm-backend/wiki/New-Server-api
>         https://github.com/Project-OSRM/osrm-backend/wiki/Library-API
>         https://github.com/Project-OSRM/osrm-backend/wiki/node-osrm-api
>
>         On the development side, we removed the two branch system of
>         having a
>         `develop` and master `branch`.
>         `master` now is _unstable_ and `develop` was removed.  This model is
>         now implemented in both `osrm-backend` and `node-osrm`.
>         If you have a look at the structure of the source tree, you will
>         notice we also re-arranged it a lot to more match the module
>         structure.
>         Combined with consistent namespacing, this makes the code a lot
>         easier
>         to navigate now.
>
>         Changes with regard 5.0.0 RC2:
>         - API:
>           - if `geometry=geojson` is passed the resulting geometry can be a
>         LineString or Point
>             depending on how many coordinates are present.
>           - the removal of the summary field was revered. for `steps=flase`
>         the field will always be an empty string.
>
>         Changes with regard to 4.9.1:
>         - API:
>           - BREAKING: Complete rewrite of the HTTP and library API. See
>         detailed documentation in the wiki.
>           - BREAKING: The default coordinate order is now `longitude,
>         latidue`. Exception: Polyline geometry
>               which follow the original Google specification of
>         `latitdue, longitude`.
>           - BREAKING: Polyline geometries now use precision 5, instead
>         of previously 6
>           - BREAKING: Removed GPX support
>           - New service `tile` which serves debug vector tiles of the
>         road network
>           - Completely new engine for guidance generation:
>              - Support for highway ramps
>              - Support for different intersection types (end of street,
>         forks, merges)
>              - Instruction post-processing to merge unimportant instructions
>              - Improved handling of roundabouts
>
>         - Tools:
>           - BREAKING: Renamed osrm-prepare to osrm-contract
>           - BREAKING: Removes profiles from osrm-contract, only needed
>         in osrm-extract.
>           - Abort processing in osrm-extract if there are no snappable
>         edges remaining.
>           - Added .properties file to osrm-extract ouput.
>           - Enables the use of multiple segment-speed-files on the
>         osrm-contract command line
>
>         - Profile changes:
>           - Remove movable bridge mode
>           - Add `maxspeed=none` tag to car profile.
>           - A `side_road` tag support for the OSRM car profile.
>
>         - Fixes:
>           - Issue #2150: Prevents routing over delivery ways and nodes
>           - Issue #1972: Provide uninstall target
>           - Issue #2072: Disable alternatives by default and if core
>         factor < 1.0
>           - Issue #1999: Fix unpacking for self-loop nodes not in core.
>
>         - Infrastructure:
>           - Cucumber test suit is now based on cucumber-js, removes Ruby
>         as dependency
>           - Updated to mapbox/variant v1.1
>           - Updated to libosmium v2.6.1
>           - Remove GeoJSON based debugging output, replaced by debug tiles
>
>         Obtain the new release of node-osrm via:
>
>         npm install osrm
>
>         Or obtain our C++ core engine here:
>
>         https://github.com/Project-OSRM/osrm-backend/archive/v5.0.0.tar.gz
>
>         Cheers,
>         Patrick
>
>         _______________________________________________
>         OSRM-talk mailing list
>         OSRM-talk at openstreetmap.org <mailto:OSRM-talk at openstreetmap.org>
>         https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
>
>     ---
>     This email has been checked for viruses by Avast antivirus software.
>     https://www.avast.com/antivirus
>
>
>
>     _______________________________________________
>     OSRM-talk mailing list
>     OSRM-talk at openstreetmap.org <mailto:OSRM-talk at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
>
>
> _______________________________________________
> OSRM-talk mailing list
> OSRM-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus




More information about the OSRM-talk mailing list