Integrate EmissionsEvent Mapping in (standard) EventsReader?

[kt86]

I am wondering if we should we extend the functionality of the EventsReaderXMLv1.java, so that it can also handle WarmEmissionEvents and ColdEmissionEvents directly?

Currently it is necessary to use a CustomEventMapper. ... or ... use the EmissionEventsReader.java), which has this mapping included.

Since we are going more and more into the direction, that emissions calculation (and analysis) is done in our (VSP) scenarios, I think this may be useful... (today it took me a lot oft time to find that problem)

But I do not have any idea, if that integration would result in any performance decreases....

[JWJoubert]

Hhmm, yes, I see that the matsim already has many events that it explicitly caters for, @kt86. Still, it would make sense to me to look for the emissions event-related code in the emissions contrib. I'm just thinking out loud now... event handling is something that you often do after a simulation run, so it does not make sense to "set it up" as part of the emissions module.

It will most likely become the standard practice for us (Pretoria) too to consider emissions, so while I am in favour of extending the core, I am aware that the price to pay is that the core replies on a contribution, which is not okay.

[kainagel]

Essentially, the events reader has "typed" and "untyped" events. The emissions events are "untyped", since the core does not know about the emissions contrib. However, untyped events are still processed. Alternatively, one can register the custom events mapper (which should be fairly easy). So I think that there are two paths: (1) Somehow deal with the untyped emissions events. (2) Somehow make sure that the emissions events mapper is registered when you need it (which means to refactor the events mapper out of the EmissionEventsReader so that it can be added as a one-liner). I think that (1) would not be too stupid since the typed events are not that helpful anyways. However, closer to the matsim design is (2).

We might also, at some point, consider to move central infrastructure from contribs into the core to simplify handling. The DrtRoute would also be a candidate.

[Janekdererste]

Maybe provide a ready to use CustomEventsMapper inside the emission contrib would be sufficient for now? This way one could use the normal events reader/manager to generate and read emission events.

I would agree with @JWJoubert that having those events in the core EventsManager would confuse the direction of dependency in this case.

It would also be important to change our examples to this method so that poeple can pick up the new way of handling emisson events.