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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
https://lists.openstreetmap.org/listinfo/osrm-talk
_______________________________________________
OSRM-talk mailing list
[email protected]
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
[email protected]
https://lists.openstreetmap.org/listinfo/osrm-talk
