[GraphHopper] Multiple Extended Storages

[Erik Formella]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20141028/d10677ba/attachment.html>