[GraphHopper] Storing additional node properties

[Peter]

Hi Andreas,

to store some edge or node information somewhere you can just use an
array with the edgeId or nodeId as index. To make this the "graphhopper
way" you can use one of the DataAccess implementations. The disadvantage
is a bit more complex handling, but the advantages are that these
integer or byte 'arrays' increase segment by segment (important for
large arrays), that you can store this to disc or switch on demand to be
used in-memory or memory mapped (important for mobile usage).

To store multiple values of different length per edge it gets a bit more
complicated when you need to be memory efficient (large areas) and want
to avoid Object[], then you need two DataAccess objects, one emulates
the pointer access and the other stores the different sized information.
E.g. we do this for wayGeometry in GraphHopperStorage.


> I also did not find a way to get the direction of travel

Every EdgeIteratorState is already in the correct direction, where
baseNode is the 'from' and adjNode is the 'to'. Now look into
AbstractFlagEncoder.reverseFlags where we swap flags that are dependent
of the direction like the access bits. In your case probably just use an
array of size=edgeIds*2 and GHUtility.createEdgeKey.


> My only problem now is that I did not find a way to store node
properties without a custom storage extension.

Yes, currently only one storage extension is possible, there was a pull
request but obviously we lost the submitter's energy:
https://github.com/graphhopper/graphhopper/pull/278

Regards,
Peter

On 15.05.2015 11:54, Andreas Wolf wrote:
> Hi,
>
> I need to store information about some nodes (pillar and tower) in the
> graph. More specifically, I’m interested in traffic lights and some
> traffic signs.
> I don’t need to have this used during routing, as I will only use the
> route calculated by Graphhopper as a base for further calculations –
> so as long as it is not totally off limits, it is good enough for my
> purpose, even if the travel times are sometimes much too low. But
> probably we can improve that with my work…
>
> My first approach, based on the work by Jan Soelter, was to store the
> count of traffic lights for each edge, using two flags for traffic
> lights at the start and end of the edge, plus a counter for the
> intermediate traffic lights.
> This works in general, but has several flaws. One is that it is
> impossible to get the exact location of the light, which would be a
> problem on longer roads (imagine a pedestrian crossing on longer roads
> within a city).
> I also did not find a way to get the direction of travel, which makes
> the start/end flags kind of not-so-useful.
>
> My current idea is to store the additional data with the nodes, which
> would remove the above mentioned flaws and would enable me to get a
> detailed list of road segments with the traffic signs and lights along
> them. That is basically what I need in the end.
>
> My only problem now is that I did not find a way to store node
> properties without a custom storage extension.
> Is there a kind of "node flags" like there is for edges and I just
> overlooked it?
> Or is a storage extension (which would make using turn costs
> impossible) the only viable solution? If yes, would it be an option to
> integrate node flags into the graph storage?
>
>
> Regards
> Andreas
>
> _______________________________________________
> GraphHopper mailing list
> GraphHopper at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/graphhopper


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20150521/4f867670/attachment.html>