[GraphHopper] ExtendedStorage for OSM ids

Philipp Hamm Philipp.Hamm at Optitool.DE
Fri Mar 28 08:44:46 UTC 2014


Hi,
integer is still big enough for way ids (which are currently < 270.000.000) and so int should suffice for a very long time.
however if you need node ids too, one field is too small.

regards,
Philipp

Von: Karl Hübner [mailto:evilhack at gmx.de]
Gesendet: Donnerstag, 27. März 2014 22:50
An: Bruno Carle; GraphHopper Java routing engine
Betreff: Re: [GraphHopper] ExtendedStorage for OSM ids

Hey Bruno,
the extended storage is a quite new feature, so I think you have to implement it by yourself. Since osmIds are of type long but the additional fields for edges and nodes are of type int, you have to use additional storages and let the additional fields point at its entries. I think Peter can tell you where you can find helper methods in order to split a long value into two integer values. But you're right, looking at my code in TurnCostStorage should help you. Fell free to ask if you have further questions.
Best regards, Karl.

Bruno Carle <brunocarle at yahoo.com<mailto:brunocarle at yahoo.com>> schrieb:
Hi everybody,
I would like to retrieve the osmIds from edges and/or nodes in order to be able to blacklist some paths.
The blacklist will change often, so I can not put it inside a FlagEncoder as I would have to reimport every time.
I think another way is using an ExtendedStorage that would store the OSM ids. Please does anyone have one running?
If not I will try to implement it, probably copying the ideas from the TurnCostStorage in khuebner/graphhopper.
Thanks
Bruno
-------------- n�chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140328/3b415abb/attachment.html>


More information about the GraphHopper mailing list