[GraphHopper] Reconnecting edges after the contraction

[Peter K]

The bug in GraphStorage
filter != null && filter.accept
vs.
filter == null || filter.accept

resulted in the speedup. But without moving to "insert at front" I would
not have discovered it.


> Is this speedup related to A*?

If you use CH with bidirectional A* then probably yes. But using
algorithms without CH then speed is the same.

Regards,
Peter.

>> This is fixed in the master. And while this fix I detected also a bug 
>> in the edge iterator logic. Those two changes made nearly no difference 
>> for normal algos but now CH queries are 35% faster and the 
>
> This is strange actually to have faster queries. (unless this is
> related to the bug correction in the ede iterator logic)
>
> Maybe it is because when inserting at the head during the contraction,
> latest shortcuts discovered during the contraction are explored
> first during the exploration, and these tend to cover longer distances.
>
> Is this speedup related to A*?
>
>> CH-preparation is over 20% faster! So, thanks Renaud :) !
>
> cool.
>
>> Regards,
>> Peter.
>>
>>
>>>> Is there a reason for not inserting it at the beginning?
>>> No. This could be improved. BTW: It is already mentioned in this ticket
>>> under 'further possible improvements':
>>> https://github.com/graphhopper/graphhopper/issues/111
>>
>> _______________________________________________
>> GraphHopper mailing list
>> GraphHopper at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/graphhopper
>>
>
>
> -- 
> *Renaud De Landtsheer, Ir, Phd*
> Sr R&D Engineer
> CETIC
> Rue des Frères Wright, 29/3
> B-6041 Charleroi
> Phone: +32 71 490 754
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20131107/286a12a6/attachment.html>