bugs in osm_build_network.py

[pz-max]

The osm_build_network.py creates from line data, buses at the start and endpoint.

Though, looking at the image below which can be reproduced with pypsa-africa/notebooks/osm_build_network_plot.ipynb, we find out that some buses appear to be relatively far from the maingrid:

• [x] as single points (how was that point created?)
• [x] as short lines, that appear on the map as points (Why are there short lines? Should we avoid them? Short lines are sometimes also available in the maingrid which makes them hard to remove - maybe we can count the number of connections of a line i.e. remove a network that contains only 2 buses and the line length is short)

Further, the osm_build_network.py also defines the low voltage buses. Currently, most buses are set to "True", and only at locations with multiple buses (LV,MV,HV) only the lowest bus is "True" while the others are set "False". We recognised for instance, by looking at hydropower plants, that there we assume that these are also LV buses. We need to:

• [x] check if the assumption of LV buses at generation sites is valid. (I guess PyPSA-Eur is removing generator buses as LV bus)

Our goal is to keep the network structure of the "real system" in the representation. Since the Voronoi cell will spread from these LV buses later, maybe it is a good option to keep the generators as LV_bus. In Aswan, Egypt, is a roughly 1.4 GW solar PV plant installed in the desert far from the city. If Egypt is modelled in high resolution, it might be useful to have the grid bottlenecks represented I.e. by spreading the Voroin cell from the generator substation.

[pz-max]

@davide-f, I think we solved that issue with the single points not being at the line end? Can you remind us what the issue was?

[davide-f]

In #96 , later improved by #100 , the function line_endings_to_bus_conversion has been improved to identify the beginning and end of any line. In the previous implementation, the bounding points of the corresponding square were identified, which probably resulted in points located afar the actual extremes of a line. That approach works fine for all lines except a line in Tanzania, as noted in #103 , whose extremes are empty, but for all >10k lines for africa that fix works fine. Were there other "weird points" that issue was referred to? According to the notebook checking the mappings (build_bus_regions_verifybuseslines) it didn't seem like.