[GraphHopper] Multiple Extended Storages

[Erik Formella]

Agreed. I am going to invest time in multiple extended storages then since
it seems like a better fit for my use case.

On Wed, Oct 29, 2014 at 3:27 AM, Peter <graphhopper at gmx.de> wrote:

>  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> 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> 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
>> https://lists.openstreetmap.org/listinfo/graphhopper
>>
>>
>
>
> _______________________________________________
> GraphHopper mailing listGraphHopper at openstreetmap.orghttps://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/aabddab3/attachment.html>