Daniel Huppmann
Daniel Huppmann
I guess that there are synergies in implementation with #416
Thanks for the reminder. I think that all codes or hierarchy-levels or other filter-arguments will be str or value, not lists. So it's fine to assume that "filter by `hierarchy=["R5",...
This looks ok to me, but can you please rebase this branch so that the seeming merge conflicts are resolved?
Closing in favor of #325
No, this would be basically the same pattern as the existing aggregate-option. My point here was to have the same pattern as the rename-option of the RegionProcessor.
> And can a config have both `aggregate` and `rename` (with given sanity checks)? Yes, I don't see why it shouldn't be allowed to have both (though in practice, it...
For the record, it may be preferable to keep the variable as is and add a method-explainer in square brackets, e.g. > Yield|Cropland|{Crop Types} [Dry Matter per Harvested Land Area]...
@IAMconsortium/common-definitions-industry @IAMconsortium/common-definitions-macro-economy, please advise
This is a good idea, but it would automatically add the UNEP regions to every project. I suggest to wait until **nomenclature** supports a filtered-import of other definition repositories.
For reference, this is issue in **nomenclature** that will enable filtering (and not always importing the UNEP-R5 regions in projects relying on **common-definitions**): https://github.com/IAMconsortium/nomenclature/issues/326