I would like to propose to change the current
where attribs contains the material that is in the Attributable part of Activity.
One use case would be that carrier agents, which are run as normal person agents through the qsim, would be able to report the ID of the customer they are serving with their delivery activity.
The question is obviously more general: Should we, in the longer run, aim for adding the contents of Attributable to events of the corresponding object type (Activity, Leg, ...)? This is evidently mostly important for such objects that do not have an ID of their own.
The ActivityStartEvent constructor is called at 4 locations: events xml reader, events txt reader, activity start in qsim, activity start in mobsim. So the changes seem to be fairly limited.
Evidently, non-known external mobsims would have problems. We could leave the old constructors as deprecated in place.
One question would be what we pass through; in principle, we would need AttributeConverter to convert non-String objects to strings.
Why convert the attributes from Object to String when passing them to the event? This would mean that code would have to always check if the expected value is a String or of some other type it expects in other places.
How would you serialize the attributes to the XML events format?
So the changes seem to be fairly limited.
Due to the whole (de)serialization issue and the fact that code must start differentiating between “Attributes from Events containing String” and “Attributes from Activities containing Object”, I’m not yet convinced that the changes are only small.
Thanks for the suggestion with the separate freight agents. That makes a lot of sense, since that also opens the way to a different behavioral modelling than person agents.
➝ closing the issue