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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.openstreetmap.org/listinfo/graphhopper >> >> > > > _______________________________________________ > GraphHopper mailing > [email protected]https://lists.openstreetmap.org/listinfo/graphhopper > > > > _______________________________________________ > GraphHopper mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/graphhopper > >
_______________________________________________ GraphHopper mailing list [email protected] https://lists.openstreetmap.org/listinfo/graphhopper
