(The issue is about the keys that denote the emittants (like CO2, NO2, NOx). These used to be enums (and everything that was not in the enum was ignored); this was changed some time ago to an approach that took all the emittants from the hbefa files and just passed them through.)
I am wondering if it is a totally stupid idea to go back to enums?
I can see the advantage of "just passing through what is in the input file". Yet, as we note, this causes problems downstream, as
one needs to downstream write code that hedges against spelling variants (e.g. "CO2(total)" vs "CO2_TOTAL"), and
we note that not everything can actually be processed in downstream code (e.g. https://github.com/matsim-org/matsim-code-examples/issues/186).
Also, I don't think that we have this anywhere else in MATSim: We have free-from activity types and modes, but they are registered in the config file first.
Having free form keys to me also feels like a python way of coding, not Java.
Sometimes, a nice idea does not fly. Is it maybe time to admit that this idea did not fly, and go back?
I am perfectly fine with going back to enums. For what it is worth, I also recall picking up some discrepancies between naming conventions between HBEFA 3.3 and 3.4. And now, I think, we are on version 4.1 - so we may just want to keep backward compatibility in mind.
I’m not deeply into the needs of emissions modelling. But it worked very well a few years ago when I integrated it into Via, but didn’t so recently when I had to prepare it again for a tutorial. Thus, I’m also in favor of going back to the more stable enums.
I haven’t worked with the code for ages now, but my decision back then to use enums was because I found it to be a lot more stable going through data prep, calculations, post-processing. And I only had one version of HBEFA
So in general: +1 for going back to enums (without having the full picture here).
Wondering if one could use protobuf schema to auto-generate classes, maybe even further downstream?