cts_buildings

CTS electricity and heat demand time series for scenarios in 2035 and 2050 assigned to OSM-buildings are generated.

Disaggregation of CTS heat & electricity demand time series from MV substation to census cells via annual demand and then to OSM buildings via amenity tags or randomly if no sufficient OSM-data is available in the respective census cell. If no OSM-buildings or synthetic residential buildings are available new synthetic 5x5m buildings are generated.

class BuildingHeatPeakLoads(**kwargs)[source]

Bases: sqlalchemy.ext.declarative.api.Base

Class definition of table demand.egon_building_heat_peak_loads.

building_id
peak_load_in_w
scenario
sector
class CtsBuildings(**kwargs)[source]

Bases: sqlalchemy.ext.declarative.api.Base

Class definition of table openstreetmap.egon_cts_buildings.

Table of all selected CTS buildings with id, census cell id, geometry and amenity count in building. This table is created within cts_buildings().

geom_building
id
n_amenities_inside
serial
source
zensus_population_id
class CtsDemandBuildings(dependencies)[source]

Bases: egon.data.datasets.Dataset

Generates CTS electricity and heat demand time series for scenarios in 2035 and 2050 assigned to OSM-buildings.

Disaggregation of CTS heat & electricity demand time series from MV Substation to census cells via annual demand and then to OSM buildings via amenity tags or randomly if no sufficient OSM-data is available in the respective census cell. If no OSM-buildings or synthetic residential buildings are available new synthetic 5x5m buildings are generated.

Dependencies
Resulting tables

The following datasets from the database are mainly used for creation:

  • openstreetmap.osm_buildings_filtered:
    Table of OSM-buildings filtered by tags to selecting residential and cts buildings only.
  • openstreetmap.osm_amenities_shops_filtered:
    Table of OSM-amenities filtered by tags to select cts only.
  • openstreetmap.osm_amenities_not_in_buildings_filtered:
    Table of amenities which do not intersect with any building from openstreetmap.osm_buildings_filtered
  • openstreetmap.osm_buildings_synthetic:
    Table of synthetic residential buildings
  • boundaries.egon_map_zensus_buildings_filtered_all:
    Mapping table of census cells and buildings filtered even if population in census cell = 0.
  • demand.egon_demandregio_zensus_electricity:
    Table of annual electricity load demand for residential and cts at census cell level. Residential load demand is derived from aggregated residential building profiles. DemandRegio CTS load demand at NUTS3 is distributed to census cells linearly to heat demand from peta5.
  • demand.egon_peta_heat:
    Table of annual heat load demand for residential and cts at census cell level from peta5.
  • demand.egon_etrago_electricity_cts:
    Scaled cts electricity time series for every MV substation. Derived from DemandRegio SLP for selected economic sectors at nuts3. Scaled with annual demand from demand.egon_demandregio_zensus_electricity
  • demand.egon_etrago_heat_cts:
    Scaled cts heat time series for every MV substation. Derived from DemandRegio SLP Gas for selected economic sectors at nuts3. Scaled with annual demand from demand.egon_peta_heat.

What is the goal?

To disaggregate cts heat and electricity time series from MV substation level to geo-referenced buildings, the annual demand from DemandRegio and Peta5 is used to identify census cells with load demand. We use Openstreetmap data and filter tags to identify buildings and count the amenities within. The number of amenities and the annual demand serve to assign a demand share of the MV substation profile to the building.

What is the challenge?

The OSM, DemandRegio and Peta5 dataset differ from each other. The OSM dataset is a community based dataset which is extended throughout and does not claim to be complete. Therefore, not all census cells which have a demand assigned by DemandRegio or Peta5 methodology also have buildings with respective tags or sometimes even any building at all. Furthermore, the substation load areas are determined dynamically in a previous dataset. Merging these datasets different scopes (census cell shapes, building shapes) and their inconsistencies need to be addressed. For example: not yet tagged buildings or amenities in OSM, or building shapes exceeding census cells.

How are these datasets combined?

The methodology for heat and electricity is the same and only differs in the annual demand and MV/HV Substation profile. In a previous dataset (openstreetmap), we filter all OSM buildings and amenities for tags, we relate to the cts sector. Amenities are mapped to intersecting buildings and then intersected with the annual demand which exists at census cell level. We obtain census cells with demand and amenities and without amenities. If there is no data on amenities, n synthetic ones are assigned to existing buildings. We use the median value of amenities/census cell for n and all filtered buildings + synthetic residential buildings. If no building data is available a synthetic buildings is randomly generated. This also happens for amenities which couldn’t be assigned to any osm building. All census cells with an annual demand are covered this way, and we obtain four different categories of buildings with amenities:

  • Buildings with amenities
  • Synthetic buildings with amenities
  • Buildings with synthetic amenities
  • Synthetics buildings with synthetic amenities

The amenities are summed per census cell (of amenity) and building to derive the building amenity share per census cell. Multiplied with the annual demand, we receive the profile demand share for each cell. Some buildings exceed the census cell shape and have amenities in different cells although mapped to one building only. To have unique buildings the demand share is summed once more per building id. This factor can now be used to obtain the profile for each building.

A schematic flow chart exist in the correspondent issue #671: https://github.com/openego/eGon-data/issues/671#issuecomment-1260740258

What are central assumptions during the data processing?

  • We assume OSM data to be the most reliable and complete open source dataset.
  • We assume building and amenity tags to be truthful and accurate.
  • Mapping census to OSM data is not trivial. Discrepancies are substituted.
  • Missing OSM buildings are generated for each amenity.
  • Missing amenities are generated by median value of amenities/census cell.

Drawbacks and limitations of the data

  • Shape of profiles for each building is similar within a MVGD and only scaled with a different factor.
  • MVGDs are generated dynamically. In case of buildings with amenities exceeding MVGD borders, amenities which are assigned to a different MVGD than the assigned building centroid, the amenities are dropped for sake of simplicity. One building should not have a connection to two MVGDs.
  • The completeness of the OSM data depends on community contribution and is crucial to the quality of our results.
  • Randomly selected buildings and generated amenities may inadequately reflect reality, but are chosen for sake of simplicity as a measure to fill data gaps.
  • Since this dataset is a cascade after generation of synthetic residential buildings also check drawbacks and limitations in hh_buildings.py.
  • Synthetic buildings may be placed within osm buildings which exceed multiple census cells. This is currently accepted but may be solved in #953.
  • Scattered high peak loads occur and might lead to single MV grid connections in ding0. In some cases this might not be viable. Postprocessing is needed and may be solved in #954.
name = 'CtsDemandBuildings'
version = '0.0.3'
class EgonCtsElectricityDemandBuildingShare(**kwargs)[source]

Bases: sqlalchemy.ext.declarative.api.Base

Class definition of table demand.egon_cts_electricity_demand_building_share.

Table including the MV substation electricity profile share of all selected CTS buildings for scenario eGon2035 and eGon100RE. This table is created within cts_electricity().

building_id
bus_id
profile_share
scenario
class EgonCtsHeatDemandBuildingShare(**kwargs)[source]

Bases: sqlalchemy.ext.declarative.api.Base

Class definition of table demand.egon_cts_heat_demand_building_share.

Table including the MV substation heat profile share of all selected CTS buildings for scenario eGon2035 and eGon100RE. This table is created within cts_heat().

building_id
bus_id
profile_share
scenario
amenities_without_buildings()[source]

Amenities which have no buildings assigned and are in a cell with cts demand are determined.

Returns:pd.DataFrame – Table of amenities without buildings
assign_voltage_level_to_buildings()[source]

Add voltage level to all buildings by summed peak demand.

All entries with same building id get the voltage level corresponding to their summed residential and cts peak demand.

buildings_with_amenities()[source]

Amenities which are assigned to buildings are determined and grouped per building and zensus cell. Buildings covering multiple cells therefore exists multiple times but in different zensus cells. This is necessary to cover as many cells with a cts demand as possible. If buildings exist in multiple mvgds (bus_id) , only the amenities within the same as the building centroid are kept. If as a result, a census cell is uncovered by any buildings, a synthetic amenity is placed. The buildings are aggregated afterwards during the calculation of the profile_share.

Returns:
  • df_buildings_with_amenities (gpd.GeoDataFrame) – Contains all buildings with amenities per zensus cell.
  • df_lost_cells (gpd.GeoDataFrame) – Contains synthetic amenities in lost cells. Might be empty
buildings_without_amenities()[source]

Buildings (filtered and synthetic) in cells with cts demand but no amenities are determined.

Returns:df_buildings_without_amenities (gpd.GeoDataFrame) – Table of buildings without amenities in zensus cells with cts demand.
calc_building_demand_profile_share(df_cts_buildings, scenario='eGon2035', sector='electricity')[source]

Share of cts electricity demand profile per bus for every selected building is calculated. Building-amenity share is multiplied with census cell share to get the substation bus profile share for each building. The share is grouped and aggregated per building as some buildings exceed the shape of census cells and have amenities assigned from multiple cells. Building therefore get the amenity share of all census cells.

Parameters:
  • df_cts_buildings (gpd.GeoDataFrame) – Table of all buildings with cts demand assigned
  • scenario (str) – Scenario for which the share is calculated.
  • sector (str) – Sector for which the share is calculated.
Returns:

df_building_share (pd.DataFrame) – Table of bus profile share per building
calc_census_cell_share(scenario, sector)[source]

The profile share for each census cell is calculated by it’s share of annual demand per substation bus. The annual demand per cell is defined by DemandRegio/Peta5. The share is for both scenarios identical as the annual demand is linearly scaled.

Parameters:
  • scenario (str) – Scenario for which the share is calculated: “eGon2035” or “eGon100RE”
  • sector (str) – Scenario for which the share is calculated: “electricity” or “heat”
Returns:

df_census_share (pd.DataFrame)
calc_cts_building_profiles(bus_ids, scenario, sector)[source]

Calculate the cts demand profile for each building. The profile is calculated by the demand share of the building per substation bus.

Parameters:
  • bus_ids (list of int) – Ids of the substation for which selected building profiles are calculated.
  • scenario (str) – Scenario for which the share is calculated: “eGon2035” or “eGon100RE”
  • sector (str) – Sector for which the share is calculated: “electricity” or “heat”
Returns:

df_building_profiles (pd.DataFrame) – Table of demand profile per building. Column names are building IDs and index is hour of the year as int (0-8759).
cells_with_cts_demand_only(df_buildings_without_amenities)[source]

Cells with cts demand but no amenities or buildilngs are determined.

Returns:df_cells_only_cts_demand (gpd.GeoDataFrame) – Table of cells with cts demand but no amenities or buildings
create_synthetic_buildings(df, points=None, crs='EPSG:3035')[source]

Synthetic buildings are generated around points.

Parameters:
  • df (pd.DataFrame) – Table of census cells
  • points (gpd.GeoSeries or str) – List of points to place buildings around or column name of df
  • crs (str) – CRS of result table
Returns:

df (gpd.GeoDataFrame) – Synthetic buildings
cts_buildings()[source]

Assigns CTS demand to buildings and calculates the respective demand profiles. The demand profile per substation are disaggregated per annual demand share of each census cell and by the number of amenities per building within the cell. If no building data is available, synthetic buildings are generated around the amenities. If no amenities but cts demand is available, buildings are randomly selected. If no building nor amenity is available, random synthetic buildings are generated. The demand share is stored in the database.

Cells with CTS demand, amenities and buildings do not change within the scenarios, only the demand itself. Therefore scenario eGon2035 can be used universally to determine the cts buildings but not for the demand share.

cts_electricity()[source]
Calculate cts electricity demand share of hvmv substation profile
for buildings.
cts_heat()[source]
Calculate cts electricity demand share of hvmv substation profile
for buildings.
delete_synthetic_cts_buildings()[source]

All synthetic cts buildings are deleted from the DB. This is necessary if the task is run multiple times as the existing synthetic buildings influence the results.

get_cts_electricity_peak_load()[source]

Get electricity peak load of all CTS buildings for both scenarios and store in DB.

get_cts_heat_peak_load()[source]

Get heat peak load of all CTS buildings for both scenarios and store in DB.

get_peta_demand(mvgd, scenario)[source]

Retrieve annual peta heat demand for CTS for either eGon2035 or eGon100RE scenario.

Parameters:
  • mvgd (int) – ID of substation for which to get CTS demand.
  • scenario (str) – Possible options are eGon2035 or eGon100RE
Returns:

df_peta_demand (pd.DataFrame) – Annual residential heat demand per building and scenario. Columns of the dataframe are zensus_population_id and demand.
place_buildings_with_amenities(df, amenities=None, max_amenities=None)[source]

Building centroids are placed randomly within census cells. The Number of buildings is derived from n_amenity_inside, the selected method and number of amenities per building.

Returns:df (gpd.GeoDataFrame) – Table of buildings centroids
remove_double_bus_id(df_cts_buildings)[source]

This is an backup adhoc fix if there should still be a building which is assigned to 2 substations. In this case one of the buildings is just dropped. As this currently accounts for only one building with one amenity the deviation is neglectable.

select_cts_buildings(df_buildings_wo_amenities, max_n)[source]

N Buildings (filtered and synthetic) in each cell with cts demand are selected. Only the first n buildings are taken for each cell. The buildings are sorted by surface area.

Returns:df_buildings_with_cts_demand (gpd.GeoDataFrame) – Table of buildings