DE-AT-LU bidding zone split about entsoe-py HOT 4 CLOSED

DE-LU bidding zone was added in b8ccfca, included in 0.2.4

from entsoe-py.

Hi,
Related to this, I was wondering: is there a reason that in the mapping BIDDING_ZONES, the country code of Germany (DE) is mapped to the bidding zone DE-AT-LU?
And that in several functions (e.g. query_load) the bidding zone mapping is used instead of the domain mapping?
I am asking this, because I would like to get all the data of Germany starting in 2017, but now this is throwing the NoMatchingDataError due to DE-AT-LU not containing any data anymore after the change of bidding zones in 2018 (DE-AT-LU --> DE-LU).

from entsoe-py.

To give a specific answer:
If you want German data before October 2018, use DE. (which is mapped to DE-AT-LU behind the scenes.
If you want German data after October 2018, explicitly type DE-LU.

Some general comments on how it got to this point:
These mappings were added once, some time ago, when the only user of the code was me, and I only needed data from Belgium which has only one bidding zone. So it made sense to me to map the parameter BE, so I wouldn't have to type this complex domain code every time.

Since then I've learned that these mappings change, bidding zones merge or split, some API-calls take domains, others take bidding zones... frankly it's a mess.

So, feel free to update the code to something more useful and I will be happy to approve the update.

from entsoe-py.

Great, thank you for the explanation. It seems indeed like a mess and I am surprised it is working most of the time. I tried to come up with an easy solution, but so far didn't succeed and for my purposes it is good enough to just make two different calls for Germany.
I will update the code if I come up with a smart way to order it :)

from entsoe-py.