Municipalities without mv grid

[ClaraBuettner]

There are two municipalities in Bavaria (namely Egloffstein and Hausen b. Würzburg) that don't belong to any mv grid.
Both municipalities are also missing in boundaries.vg250_gem_clean which is an input to the mv grids.
I tried to look into the SQL script and stumbled over these lines:

eGon-data/src/egon/data/processing/vg250/cleaning_and_preparation.sql

Lines 564 to 566 in 5dbaf24

	DELETE FROM boundaries.vg250_gem_clean
	WHERE is_hole IS TRUE OR
	id = '9251' OR id = '8362'; -- Two special cases deleted manualy

and I'm wondering if these might be the two municipalities which are deleted manually.
@gplssm Why are these municipalities deleted manually from boundaries.vg250_gem_clean?

[gplssm]

I didn't came across these two municipalities. Honestly, I took this code from open_ego without changing it. It would like to try to remove this delete case or replace it with a smarter function in order not to lose these two municipalities.
Sadly, I wasn't able to set up a second workflow for eGon-data to run it with dataset=Everything for testing, because it somehow conflicted with the existing container :-/.
I can't verify at the moment that these two municipalities have the ids '9251' and '8362'. But it seems plausible. Are you anyways about to run the workflow again for Germany? Then, it would be great if you could delete these two lines and see if

1. The two above mentioned municipalities get associated to MV grid
2. If the downstream tasks don't fail on the changed VG250 data

[ClaraBuettner]

Sadly, I wasn't able to set up a second workflow for eGon-data to run it with dataset=Everything for testing, because it somehow conflicted with the existing container :-/.

I also had those problems, it can be prevented by using the same container for different databases or rename the service (I don't really know why this helped but it was working..)

I can't verify at the moment that these two municipalities have the ids '9251' and '8362'. But it seems plausible. Are you anyways about to run the workflow again for Germany? Then, it would be great if you could delete these two lines and see if

1. The two above mentioned municipalities get associated to MV grid

2. If the downstream tasks don't fail on the changed VG250 data

I tested it on the server, the two municipalities have the ids '9251' and '8362'.
If I remove OR id = '9251' OR id = '8362';, all municipalities are inside a MV grid and all downstream tasks run successfully.

[gplssm]

Sadly, I wasn't able to set up a second workflow for eGon-data to run it with dataset=Everything for testing, because it somehow conflicted with the existing container :-/.

I also had those problems, it can be prevented by using the same container for different databases or rename the service (I don't really know why this helped but it was working..)

I gonna add this point to the todays eGon-data webco agenda.

I can't verify at the moment that these two municipalities have the ids '9251' and '8362'. But it seems plausible. Are you anyways about to run the workflow again for Germany? Then, it would be great if you could delete these two lines and see if

1. The two above mentioned municipalities get associated to MV grid

2. If the downstream tasks don't fail on the changed VG250 data

I tested it on the server, the two municipalities have the ids '9251' and '8362'.
If I remove OR id = '9251' OR id = '8362';, all municipalities are inside a MV grid and all downstream tasks run successfully.

Cool! Glad that it works and I'm thankful that you helped out here!