Additional API signature
hawesie opened this issue · 3 comments
From @PDuckworth's work on trajectory activities for the G4S deployment, he is doing lots of calls with trajectories such as: (t, o1), (t, o2), (t, o3) etc. This is introducing a fair bit of overhead doing all these hundreds of calls (tens of thousands once the database fills up when learning I guess). It would be better if we could have a service that did (t, [o1, o2, o3, ...]) to reduce the overhead. Is this possible? It shouldn't be too difficult as it's simply moving the loop from one end to the other. This would be in addition to the existing calls.
QSRlib already supports passing multiple "objects" [t, o1, o2, o3, ...] at the same time and creating QSRs for/between them as appropriate by the requested QSR (e.g. RCC3).
However, there are two causes for the overhead:
- Current implementation of QTC only allows two-objects for two-time steps queries. Have already discussed it with @cdondrup and he will fix it when he finds time.
- @PDuckworth requires QSRs to be generated only between certain objects, in particular between trajectory and objects. QSRs in the QSRlib having no knowledge of that have a default behaviour which usually is to generate QSRs among all possible combinations. A solution that I see to this is that on top of the [o1, o2, o3, ...] the request could include an optional field between which objects QSRs should be computed, e.g. [(o1, o2), (o1, o3)] which overwrites the default behaviour. This causes though some "issues": a) the client will be responsible for generating them (not a major one in my opinion as he is the one knowing what to request), b) a QSR developer should fill the custom_checks method that exists to check against inappropriate use, c) for more complex QSRs it will require further parsing.
Doable though. I will have a look into it when I get a chance.
Ah yes and forgot to mention that since QSRlib already supports passing multiple objects then a temporal solution for now to maybe reduce overhead would be to pass everything, get QSRs for everything (hence the maybe reduce overhead) and filter them out on the client side.
Nevermind, won't work as QTC does not handle more than two objects.