Re: [sumo-user] libsumo & subscriptions

[czechows <czechovs@xxxxxxxxx>]

Hi Michael,

thanks for your reply!

On 3/22/19 4:12 PM, Michael Behrisch wrote:
> Hi Aleksander,
> my thoughts on that one below:
>
> Am 22.03.19 um 14:50 schrieb czechows:
> > libsumo.vehicle.getSubscriptionResults() returns a SwigPy object
> this won't be fixed soon, probably, since I first want to check how this
> make reusable instead of copying the same code over and over again.
Makes sense.
> > libsumo.vehicle.getSubscriptionResults(vehID) returns a Python dictionary,
> > but if one of the subscriptions is the vehicle position then it is again
> > a SwigPy object and so on.
> This one I would consider a bug and not an incomplete interface. I will
> try to fix this till the next release in April.
Ah then this would probably already solve our problem,
since we would only need to loop over the subscription objects.
> > 1. My colleagues and I use a wrapper around SUMO, that was till now
> > organized around obtaining all needed data from subscription and caching
> > it, for faster execution time.
> > We want to make it configurable to support both traci and libsumo.
> > Is it on the development roadmap to complete the translation for libsumo
> > subscriptions?
> > If not, then we would rewrite our wrapper, but this would be unnecessary
> > effort if the SUMO developers plan to fix it soon anyways.
> But honestly, if you have bigger implementation efforts anyway and a
> whole team working on this wouldn't it be an option to try and fix this
> yourselves and contribute it back? I would be very grateful if you could
> at least consider the idea and be willing to give support if I can.
Indeed it would indeed be nice if we could contribute something back.
I'll suggest that on the team meeting but it is not up to me to decide
(and using libsumo wasn't a task of high-priority for us in the first 
place, but a nice-to-have).
At least I can promise that we will eventually open source our wrapper,
regardless of whether we use libsumo in the end.

> > 2. Assuming support for libsumo subscriptions is not planned:would
> > asking for each variable through libsumo be still faster than obtaining
> > all of them (e.g. all vehicle positions in a simulation) through a traci
> > subscription?
> The subscription results are stored in a map of maps once the step is
> finished so there should be no notable performance difference between
> asking for each vehicle result separately or obtaining the whole map and
> iterate over it (provided that python maps and C++ maps are more or less
> equally performant). This is true for TraCI and libsumo. Asking for
> every vehicle parameter individually (without subscriptions) will make a
> major difference in TraCI (since it will do network communication for
> every call) but probably not so much in libsumo.
Clear, thanks!

> > That probably would also depend on the number of vehicles?
> The version without subscriptions definitely, the other not so much.
>
> Best regards,
> Michael
Cheers,
Aleksander
>