[GraphHopper] Multiple Extended Storages

[Peter]

Hi Erik,

the extended storage(s) is useful for different purposes where one needs
dynamic data per edge and not just a fixed number of bytes like one
would get via increasing the row size. So both options have a good
reason. Still we should probably start with only one :)

Regards,
Peter.

On 29.10.2014 00:43, Erik Formella wrote:
> Oh I think increasing the row size could be really awesome. I don't
> know which method should be preferred at the moment. Is it your
> intention to eventually remove extended storage all together?
>
> On Tue, Oct 28, 2014 at 1:23 PM, Peter <graphhopper at gmx.de
> <mailto:graphhopper at gmx.de>> wrote:
>
>     Hi Erik,
>
>     sounds reasonable.
>
>     When I think about extending the graph storage, should we
>     implement this for edges and nodes too?
>
>     Also we could allow to just increase the row size so that one can
>     somehow access attributes directly, without going to some external
>     storage. Or should we concentrate on real external storages for now?
>
>     I've created:
>     https://github.com/graphhopper/graphhopper/issues/276
>
>     Regards,
>     Peter.
>
>     On 28.10.2014 21:11, Erik Formella wrote:
>>     I think it is more extensible to hold a collection of different
>>     storages than to have to make subclasses for every combination of
>>     them. Right now I have a subclass implementation working for my
>>     use case, but it isn't the cleanest.
>>
>>     On Tue, Oct 28, 2014 at 12:06 PM, Peter <graphhopper at gmx.de
>>     <mailto:graphhopper at gmx.de>> wrote:
>>
>>         Hi Erik,
>>
>>         a list of extended storages sounds interesting, still I would
>>         like to understand better the usecase.
>>
>>         When you would use e.g. a subclass with separate DataAccess
>>         objects what would be more complex or impossible compared to
>>         a list of extended storages?
>>
>>         Kind Regards,
>>         Peter.
>>
>>
>>         On 27.10.2014 22:35, Erik Formella wrote:
>>>         It looks like to be able to support turn costs we have to
>>>         sacrifice the ability to use any other extended storage.
>>>
>>>         I am thinking I can refactor GraphStorage to use an
>>>         ExtendedStorageManager. It would allow us to write things like:
>>>
>>>         TurnCostStorage turnCostStorage =
>>>         graph.getExtendedStorageManager().get("turn_costs");
>>>
>>>         instead of doing:
>>>
>>>         if (graph.getExtendedStorage() istanceof TurnCostStorage) {
>>>         ... }
>>>
>>>
>>>         This is just my first guess at what the interfaces should
>>>         look like, but does that seem like a change you would
>>>         appreciate in GraphHopper?
>>>
>
>
>     _______________________________________________
>     GraphHopper mailing list
>     GraphHopper at openstreetmap.org <mailto:GraphHopper at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/graphhopper
>
>
>
>
> _______________________________________________
> 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/20141029/3669f653/attachment.html>