diff --git a/joss/paper.bib b/joss/paper.bib index 2d5e71e..7108547 100644 --- a/joss/paper.bib +++ b/joss/paper.bib @@ -71,9 +71,9 @@ @article{pyvista } @software{pandas, - author = {{The pandas development team}}, + author = {{Reback, Jeff and McKinney, Wes and {Jbrockmendel} and Bossche, Joris Van Den and Augspurger, Tom and Cloud, Phillip and {Gfyoung} and Hawkins, Simon and {Sinhrks} and Roeschke, Matthew and Klein, Adam and {Terji Petersen} and Tratner, Jeff and She, Chang and Ayd, William and Naveh, Shahar and Garcia, Marc and {, Patrick} and Schendel, Jeremy and Hayden, Andy and Saxton, Daniel and Jancauskas, Vytautas and Shadrach, Richard and Gorelli, Marco and McMaster, Ali and Battiston, Pietro and {Skipper Seabold} and {Kaiqi Dong} and {chris-b1} and {h-vetinari}}}, title = {pandas-dev/pandas: Pandas}, - month = march, + month = mar, year = 2021, publisher = {Zenodo}, version = {v1.2.3}, @@ -160,7 +160,7 @@ @software{rasterstats } @article{herbst, -title = {A {H}eat {D}emand {M}ap of {N}orth- {W}est {E}urope – its impact +title = {A {H}eat {D}emand {M}ap of {N}orth-{W}est {E}urope – its impact on supply areas and identification of potential production areas for deep geothermal energy}, journal = {GeoKarlsruhe}, volume = {2021}, @@ -219,4 +219,4 @@ @Misc{EnergyDirective title = {DIRECTIVE (EU) 2023/1791 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 13 September 2023 on energy efficiency and amending Regulation (EU) 2023/955 (recast)}, year = {2023}, url = "https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32023L1791" -} \ No newline at end of file +} diff --git a/joss/paper.md b/joss/paper.md index 1f41a2f..51bdeb1 100644 --- a/joss/paper.md +++ b/joss/paper.md @@ -25,7 +25,7 @@ bibliography: paper.bib # Summary **PyHeatDemand** is an open-source Python package for processing and harmonizing multi-scale-multi-type heat demand input data for constructing local to transnational harmonized heat demand maps (rasters). Knowledge about the heat demand in megawatt hours per area and per year of a respective building, district, city, state, country, or even on a continental scale is crucial for an adequate heat demand analysis or planning for providing power plant capacities. Mapping of the heat demand may also identify potential areas for new district heating networks or even geothermal power plants for climate-friendly heat production. -The aim of **PyHeatDemand** is to provide processing tools for heat demand input data of various categories on various scales. This includes heat demand input data provided as rasters or gridded polygons, heat demand input data associated with administrative areas (points or polygons), with building footprints (polygons), with street segments (lines), or with addresses directly provided in kWh or MWh but also as gas usage, district heating usage, or other sources of heat. It is also possible to calculate the heat demand based on a set of cultural data sets (building footprints, height of the buildings, population density, building type, etc.). The study area is first divided into a coarse mask before heat demands are calculated and harmonized for each cell with the size of the target resolution (e.g. 100 m x 100 m for states). We hereby make use of different spatial operations implemented in the GeoPandas and Shapely packages. The final heat demand map will be created utilizing the Rasterio package. Next to processing tools for the heat demand input data, workflows for analyzing the final heat demand map through the Rasterstats package are provided. +The aim of **PyHeatDemand** is to provide processing tools for heat demand input data of various categories on various scales. This includes heat demand input data provided as rasters or gridded polygons, heat demand input data associated with administrative areas (points or polygons), with building footprints (polygons), with street segments (lines), or with addresses directly provided in kWh or MWh but also as gas usage, district heating usage, or other sources of heat. It is also possible to calculate the heat demand based on a set of cultural data sets (building footprints, height of the buildings, population density, building type, etc.). The study area is first divided into a coarse mask before heat demands are calculated and harmonized for each cell with the size of the target resolution (e.g., 100 m $\times$ 100 m for states). We hereby make use of different spatial operations implemented in the GeoPandas and Shapely packages. The final heat demand map will be created utilizing the Rasterio package. Next to processing tools for the heat demand input data, workflows for analyzing the final heat demand map through the Rasterstats package are provided. **PyHeatDemand** was developed as a result of works carried out within the Interreg NWE project DGE Rollout (Rollout of Deep Geothermal Energy). The development and maintenance of **PyHeatDemand** will continue in the future beyond the duration of the project. This will include adding bottom-up workflows based on building specifics to calculate the heat demand. @@ -33,7 +33,7 @@ The aim of **PyHeatDemand** is to provide processing tools for heat demand input # Statement of need Space and water heating for residential and commercial buildings amount to a third of the European Union’s total final energy consumption. Approximately 75% of the primary energy and 50% of the thermal energy are still produced by burning fossil fuels, leading to high greenhouse gas emissions in the heating sector [@Reiter]. The transition from centralized fossil-fueled district heating systems such as coal or gas power plants to district heating systems sourced by renewable energies such as geothermal energy or more decentralized individual solutions for city districts makes it necessary to map the heat demand for a more accurate planning of power plant capacities. In addition, heating and cooling plans become necessary according to directives of the European Union regarding energy efficiency to reach its aim of reducing greenhouse gas emissions by 55% of the 1990-levels by 2030 [@EnergyDirective]. -Evaluating the annual heat demand (HD, usually in MWh = megawatt Hours) on a national or regional scale, including space and water heating for each apartment or each building for every day of a year separately is from a perspective of resolution (spatial and temporal scale) and computing power not feasible. Therefore, heat demand maps summarize the heat demand on a lower spatial resolution (e.g. 100 m x 100 m raster) cumulated for one year (lower temporal resolution) for different sectors such as the residential and tertiary sectors. Maps for the industrial heat demand are not available as the input data is not publicly available or can be deduced from cultural data. Customized solutions are therefore necessary for this branch to reduce greenhouse gas emissions. Heat demand input values for the residential and commercial sectors are easily accessible and assessable. With the new directives regarding energy efficiency, it becomes necessary for every city or commune to evaluate their heat demand. And this is where **PyHeatDemand** comes into place. Combining the functionality of well-known geospatial Python libraries, the open-source package **PyHeatDemand** provides tools for public entities, researchers, or students for processing heat demand input data associated with an administrative area (point or polygon), with a building footprint (polygon), with a street segment (line), or with an address directly provided in MWh but also as gas usage, district heating usage, or other sources of heat. The resulting heat demand map data can be analyzed using zonal statistics and can be compared to other administrative areas when working on regional or national scales. If heat demand maps already exist for a specific region, they can be analyzed using tools within **PyHeatDemand**. With **PyHeatDemand**, it has never been easier to create and analyze heat demand maps. +Evaluating the annual heat demand (HD, usually in MWh = megawatt Hours) on a national or regional scale, including space and water heating for each apartment or each building for every day of a year separately is from a perspective of resolution (spatial and temporal scale) and computing power not feasible. Therefore, heat demand maps summarize the heat demand on a lower spatial resolution (e.g., 100 m $\times$ 100 m raster) cumulated for one year (lower temporal resolution) for different sectors such as the residential and tertiary sectors. Maps for the industrial heat demand are not available as the input data is not publicly available or can be deduced from cultural data. Customized solutions are therefore necessary for this branch to reduce greenhouse gas emissions. Heat demand input values for the residential and commercial sectors are easily accessible and assessable. With the new directives regarding energy efficiency, it becomes necessary for every city or commune to evaluate their heat demand. And this is where **PyHeatDemand** comes into place. Combining the functionality of well-known geospatial Python libraries, the open-source package **PyHeatDemand** provides tools for public entities, researchers, or students for processing heat demand input data associated with an administrative area (point or polygon), with a building footprint (polygon), with a street segment (line), or with an address directly provided in MWh but also as gas usage, district heating usage, or other sources of heat. The resulting heat demand map data can be analyzed using zonal statistics and can be compared to other administrative areas when working on regional or national scales. If heat demand maps already exist for a specific region, they can be analyzed using tools within **PyHeatDemand**. With **PyHeatDemand**, it has never been easier to create and analyze heat demand maps. Python libraries for calculating heat demands are sparse, especially for aggregating heat demand on various scales and categories. While UrbanHeatPro [@urbanheatpro] utilizes a bottom-up approach to calculate heat demand profiles for urban areas, the Heat package by Malcolm Peacock [@heat] generates heat demand time series from weather for EU countries. Repositories containing processing code for larger transnational heat demand projects like Hotmaps and Heat Roadmap Europe are unknown. @@ -42,18 +42,18 @@ Python libraries for calculating heat demands are sparse, especially for aggrega ## Processing Heat Demand Input Data -Heat demand maps can be calculated using either a top-down approach or a bottom-up approach (Fig. \ref{fig0}). For the top-down approach, aggregated heat demand input data for a certain area will be distributed according to higher resolution data sets (e.g. population density, landuse, etc.). In contrast to that, the bottom-up approach allows aggregating heat demand of higher resolution data sets to a lower resolution (e.g. from building level to a 100 m x 100 m raster). +Heat demand maps can be calculated using either a top-down approach or a bottom-up approach (Fig. \ref{fig0}). For the top-down approach, aggregated heat demand input data for a certain area will be distributed according to higher resolution data sets (e.g., population density, land use). In contrast to that, the bottom-up approach allows aggregating heat demand of higher resolution data sets to a lower resolution (e.g., from building level to a 100 m $\times$ 100 m raster). -**PyHeatDemand** processes geospatial data such as vector data (points, lines, polygons), raster data or address data. Therefore, we make use of the functionality implemented in well-known geospatial packages such as GeoPandas [@geopandas], Rasterio [@rasterio], Rasterstats [@rasterstats], GeoPy [@geopy], or OSMnx [@osmnx] and their underlying dependencies such as Shapely [@shapely], Pandas [@pandas], or NumPy [@numpy]. In particular, we are utilizing the powerful implementation of [Spatial Indices](https://geopandas.org/en/stable/docs/reference/sindex.html) in GeoPandas allowing for processing speed-ups by orders of magnitudes compared to performing regular overlays and spatial joins for the processing of heat demand input data. Example data for the state of North Rhine-Westphalia can be downloaded at https://www.opengeodata.nrw.de/produkte/umwelt_klima/klima/raumwaermebedarfsmodell/. +**PyHeatDemand** processes geospatial data such as vector data (points, lines, polygons), raster data or address data. Therefore, we make use of the functionality implemented in well-known geospatial packages such as GeoPandas [@geopandas], Rasterio [@rasterio], Rasterstats [@rasterstats], GeoPy [@geopy], or OSMnx [@osmnx] and their underlying dependencies such as Shapely [@shapely], Pandas [@pandas], or NumPy [@numpy]. In particular, we are utilizing the powerful implementation of [Spatial Indices](https://geopandas.org/en/stable/docs/reference/sindex.html) in GeoPandas allowing for processing speed-ups by orders of magnitudes compared to performing regular overlays and spatial joins for the processing of heat demand input data. Example data for the state of North Rhine-Westphalia can be downloaded at . -![Input and output data for top-down and bottom-up approaches. Note, that the resulting spatial resolution can be the same for both approaches, but the spatial value of information is usually lower using a top-down approach. \label{fig0}](../docs/images/fig0.png) +![Input and output data for top-down and bottom-up approaches. Note that the resulting spatial resolution can be the same for both approaches, but the spatial value of information is usually lower using a top-down approach. \label{fig0}](../docs/images/fig0.png) The creation of a heat demand map follows a general workflow (Fig. \ref{fig1}) followed by a data-category-specific workflow for five defined input data categories (Fig. \ref{fig2} \& \ref{fig3}). The different input data categories are listed in the table below. | Data category | Description | |---------------|----------------------------------------------------------------------------------------------------------------------------------| -| 1 | HD data provided as (e.g. $100\ast100\:m^2$) raster or polygon grid with the same or in a different coordinate reference system | +| 1 | HD data provided as (e.g., $100\times 100\:\textrm{m}^2$) raster or polygon grid with the same or in a different coordinate reference system | | | | | 2 | HD data provided as building footprints or street segments | | | | @@ -64,14 +64,14 @@ The creation of a heat demand map follows a general workflow (Fig. \ref{fig1}) f | 5 | No HD data available for the region | | | | -Depending on the scale of the heat demand map (local, regional, national, or even transnational), a global polygon mask is created from provided administrative boundaries with a cell size of 10 km by 10 km, for instance, and the target coordinate reference system. This mask is used to divide the study area into smaller chunks for a more reliable processing as only data within each mask will be processed separately. If necessary, the global mask will be cropped to the extent of the available heat demand input data and populated with polygons having already the final cell size such as 100 m x 100 m. For each cell, the cumulated heat demand in each cell will be calculated. The final polygon grid will be rasterized and merged with adjacent global cells to form a mosaic, the final heat demand map. If several input datasets are available for a region, i.e. different sources of energy, they can either be included in the calculation of the heat demand or the resulting rasters can be added to a final heat demand map. In addition to a uniform polygon mask with equal cell sizes, **PyHeatDemand** also offers the possibility to refine the polygon mask based on the centroid density of building footprints (Fig. \ref{fig10}) based on a simple QuadTree algorithm [@quadtree]. This allows to identify areas of high heat demand originating from a small number of buildings and areas of high heat demand from a large number of small buildings. +Depending on the scale of the heat demand map (local, regional, national, or even transnational), a global polygon mask is created from provided administrative boundaries with a cell size of 10 km by 10 km, for instance, and the target coordinate reference system. This mask is used to divide the study area into smaller chunks for a more reliable processing as only data within each mask will be processed separately. If necessary, the global mask will be cropped to the extent of the available heat demand input data and populated with polygons having already the final cell size such as 100 m $\times$ 100 m. For each cell, the cumulated heat demand in each cell will be calculated. The final polygon grid will be rasterized and merged with adjacent global cells to form a mosaic, the final heat demand map. If several input datasets are available for a region, e.g., different sources of energy, they can either be included in the calculation of the heat demand or the resulting rasters can be added to a final heat demand map. In addition to a uniform polygon mask with equal cell sizes, **PyHeatDemand** also offers the possibility to refine the polygon mask based on the centroid density of building footprints (Fig. \ref{fig10}) based on a simple QuadTree algorithm [@quadtree]. This allows to identify areas of high heat demand originating from a small number of buildings and areas of high heat demand from a large number of small buildings. ![The main steps from creating a coarse matrix to a fine matrix to calculating the final heat demand data to merging and rasterizing the data. \label{fig1}](../docs/images/fig1.png) ![Grid refinement using heat demand data density. \label{fig10}](../docs/images/Grid_Refinement.png) -The data processing for data categories 1 and 2 are very similar (Fig. \ref{fig2}) and correspond to a bottom-up approach. In the case of a raster for category 1, the raster is converted into gridded polygons. Gridded polygons and building footprints are treated equally (Fig. \ref{fig3} top). The polygons containing the heat demand data are, if necessary, reprojected to the coordinate reference system and are overlain with the local mask (e.g. 100 m x 100 m cells). This cuts each heat demand polygon with the respective mask polygon. The heat demand of each subpolygon is proportional to its area compared to the area of the original polygon. The heat demand for all subpolygons in each cell is aggregated to result in the final heat demand for this cell. +The data processing for data categories 1 and 2 are very similar (Fig. \ref{fig2}) and correspond to a bottom-up approach. In the case of a raster for category 1, the raster is converted into gridded polygons. Gridded polygons and building footprints are treated equally (Fig. \ref{fig3} top). The polygons containing the heat demand data are, if necessary, reprojected to the coordinate reference system and are overlain with the local mask (e.g., 100 m $\times$ 100 m cells). This cuts each heat demand polygon with the respective mask polygon. The heat demand of each subpolygon is proportional to its area compared to the area of the original polygon. The heat demand for all subpolygons in each cell is aggregated to result in the final heat demand for this cell. ![The main steps of the methodology to process the provided HD polygons for the heat demand data categories 1 and 2. \label{fig2}](../docs/images/fig2.png)