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] > <mailto:[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] >> <mailto:[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] <mailto:[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
