[GraphHopper] Multiple Extended Storages

[Erik Formella]

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 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/20141028/0459bccc/attachment.html>