Hi Peter

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.

Sincerely Stuart Adam
Sent from my BlackBerry® PlayBook™
www.blackberry.com


From: "Peter" <[email protected]>
To: "GraphHopper Java routing engine" <[email protected]>
Sent: November 28, 2014 10:30 AM
Subject: Re: [GraphHopper] Speed of OS ITN routing

Hi Stuart,

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.

> This is an easy fix however does seem to break some of ITN's turning restrictions

How do you mean that? Is that just hard to implement or do you see a GraphHopper limitation?

Regards,
Peter

On 28.11.2014 11:19, Stuart Adam wrote:
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 :-)

_______________________________________________
GraphHopper mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/graphhopper
_______________________________________________
GraphHopper mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/graphhopper
_______________________________________________
GraphHopper mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/graphhopper

Reply via email to