<div dir="ltr">Hi François,<div><br></div><div> > <span style="font-size:12.8px">I don't understand why flagging part of the graph as "small element" prevent a route to be found.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> I guess you could describe this as a bug. What OSRM is trying to do is always return a route. The current approach makes sure to snap the input coordinates to edges on the same "strongly connected component", which (usually) guarantees a route will be found.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> There's an older blog post by Denis here: <a href="https://blog.mapbox.com/robust-navigation-with-smart-nearest-neighbor-search-dbc1f6218be8">https://blog.mapbox.com/robust-navigation-with-smart-nearest-neighbor-search-dbc1f6218be8</a></span></div><div><span style="font-size:12.8px"> that explains the behaviour/problem that this snapping is intended to solve.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> This behaviour makes sense for fully disconnected components - islands, parks, etc.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> However, in your case, the components are weakly connected - there is a one-way path in, and an A->B route could be found, but a B->A route would not.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> This situation isn't really handled by the current approach. The Tarjan SCC algorithm flags *strongly connected* graph regions (full connectivity in both directions). We would need to do something quite different I think in order to do correct snapping for weakly connected components as you have in your graph.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> Generally in OSM, there aren't too many of these, and where they are, they're usually a mapping error (one-way roads with no exits, etc). Given that, I'm not sure it's worth spending time improving this behaviour for use with OSM data.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">daniel</span></div><div><br class="gmail-Apple-interchange-newline"></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 27, 2018 at 1:58 AM, François Lacombe <span dir="ltr"><<a href="mailto:fl.infosreseaux@gmail.com" target="_blank">fl.infosreseaux@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Daniel,<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2018-03-26 19:48 GMT+02:00 Daniel Patterson <span dir="ltr"><<a href="mailto:daniel@mapbox.com" target="_blank">daniel@mapbox.com</a>></span>:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi François,<div><br></div><span class=""><div> Yes, oneways onto your custom road network sound like exactly the kind of thing that the small component algorithm (<a href="https://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm" target="_blank">https://en.wikipedia.org/wiki<wbr>/Tarjan%27s_strongly_connected<wbr>_components_algorithm</a>) would flag. If your custom network is <1000 nodes, it would've been flagged previously.</div><div><br></div><div> If you are only routing from the normal network *onto* your custom network, then changing the component size like you've done is the correct fix here. Just be aware, if you start on your custom network, and try to return to the main network, you will get "NoRoute" errors, but it sounds like that won't be a problem for you.</div></span></div></blockquote><div><br></div><div>This is indeed what I look for, no problem to get "No route" errors, but only when network topology doesn't allow me to find one.<br></div><div>I don't understand why flagging part of the graph as "small element" prevent a route to be found.<br></div><div><br></div><div>I would agree to a potential downgrade of small elements versus normal ones, but a route have to be returned when it exists, haven't you?<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div> I'm not sure what's up with the turn icons in the debug viewer - make sure you've zoomed in far enough, turn icons only show up from Z12 and higher.</div></div></blockquote><div><br></div></span><div>Yes, I look between zoom 12 and 14<br></div><div>Still no turn icons<br><br></div><div>I'm wondering if it's only a display issue or a more serious problem in my data processing.<br></div><div>Anyway, osrm gives me routes with turns and intersections so this sounds to be only a display issue.<br><br><br></div><div>All the best<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>François<br></div></font></span></div></div></div>
<br>______________________________<wbr>_________________<br>
OSRM-talk mailing list<br>
<a href="mailto:OSRM-talk@openstreetmap.org">OSRM-talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/osrm-talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/osrm-talk</a><br>
<br></blockquote></div><br></div>