<html><head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">Hi Peter<div><br></div><div>Not a limitation of graphhopper just of the fact that I haven't had the time to diagnose the simple fix fully. The way itn works instructions can be encoded part way down a roadlink so at that time the pillar would need promoting back to a tower. I hope to find time to look at it today.</div><div><br></div><div>Sincerely Stuart Adam<br><div id="1332189272991-sig-id">Sent from my BlackBerry® PlayBook™<br>www.blackberry.com</div><br><hr><div><strong>From:</strong> "Peter" <graphhopper@gmx.de><br><strong>To:</strong> "GraphHopper Java routing engine" <graphhopper@openstreetmap.org><br><strong>Sent:</strong> November 28, 2014 10:30 AM<br><strong>Subject:</strong> Re: [GraphHopper] Speed of OS ITN routing<br></div><br>
<div class="moz-cite-prefix">Hi Stuart,<br>
<br>
thanks for the follow up! When I introduced the pillar node /
tower node difference I got ~7 times faster code which makes your
high numbers of ~30secs explainable.<br>
<br>
> This is an easy fix however does seem to break some of ITN's
turning restrictions<br>
<br>
How do you mean that? Is that just hard to implement or do you see
a GraphHopper limitation?<br>
<br>
Regards,<br>
Peter<br>
<br>
On 28.11.2014 11:19, Stuart Adam wrote:<br>
</div>
<blockquote cite="mid:DUB119-W44964FD080E2B64760A6D2BA7E0@phx.gbl" type="cite">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">As I suspected part of the issue with our speed
when not using contraction hierarchies is that currently our
code is introducing all nodes as towers rather than a mix of
towers and pillars. This is an easy fix however does seem to
break some of ITN's turning restrictions so I won't be commiting
that yet. Obviously correct and legal is better than fast :-)<br>
</div>
</blockquote>
<br>
</div></body></html>