Difference between revisions of "Transnational methodology"

From MyWiki
Jump to: navigation, search
(Conceptual data model)
(Conceptual data model)
Line 189: Line 189:
 
| style="text-align: center;" | ROOF_TYPE
 
| style="text-align: center;" | ROOF_TYPE
 
| style="text-align: center;" | Roof type
 
| style="text-align: center;" | Roof type
 +
| style="text-align: center;" | CODELIST
 +
| style="font-style: center;" |
 +
|-
 +
| style="text-align: center;" | DATE_C_BEGINNING
 +
| style="text-align: center;" | Construction year (begin)
 +
| style="text-align: center;" | integer number (yyyy)
 +
| style="font-style: center;" | If the exact construction year is known it should be written here. If only a reference period is known, write here the year at the beginning of the period.
 +
|-
 +
| style="text-align: center;" | DATE_C_END
 +
| style="text-align: center;" | Construction year (end)
 +
| style="text-align: center;" | integer number (yyyy)
 +
| style="font-style: center;" | Optional. If only a reference period is known, write here the year at the end of the period.
 +
|-
 +
| style="text-align: center;" | HEIGHT_HEIGHT_LOW
 +
| style="text-align: center;" | Lower reference for height value
 +
| style="text-align: center;" | CODELIST
 +
| style="font-style: center;" | Where the height is considered to be starting from: e.g. "from the ground level"
 +
|-
 +
| style="text-align: center;" | HEIGHT_HEIGHT_REF
 +
| style="text-align: center;" | Higher reference for height value
 +
| style="text-align: center;" | CODELIST
 +
| style="font-style: center;" | Where the height is considered to be finishing at e.g. "at the rooftop"
 +
|-
 +
| style="text-align: center;" | HEIGHT_HEIGHT_STAT
 +
| style="text-align: center;" | Heigth value type
 +
| style="text-align: center;" | text string
 +
| style="font-style: center;" | How was determined the height: measured, estimated, etc
 +
|-
 +
| style="text-align: center;" | HEIGHT_HEIGHT_VAL
 +
| style="text-align: center;" | Height value (m)
 +
| style="text-align: center;" | real number
 +
| style="font-style: center;" |
 +
|-
 +
| style="text-align: center;" | FLOORS
 +
| style="text-align: center;" | Number of floors
 +
| style="text-align: center;" | integer number
 +
| style="font-style: center;" |
 +
|-
 +
| style="text-align: center;" | H_FLOOR
 +
| style="text-align: center;" | Average floor height
 +
| style="text-align: center;" | real number
 +
| style="font-style: center;" |
 +
|-
 +
| style="text-align: center;" | UNITS
 +
| style="text-align: center;" | Number of building units
 +
| style="text-align: center;" | integer number
 +
| style="font-style: center;" |
 +
|-
 +
| style="text-align: center;" | USE_S
 +
| style="text-align: center;" | Predominant use
 
| style="text-align: center;" | CODELIST
 
| style="text-align: center;" | CODELIST
 
| style="font-style: center;" |  
 
| style="font-style: center;" |  

Revision as of 11:09, 23 February 2018

Introduction

The road towards achievement of the climate protection goals requires, among the rest, a thorough rethinking of the energy planning tools (and policies) at all levels, from local to global.

Nevertheless, it is in the cities where the largest part of energy is produced and consumed, and therefore it makes sense to focus the attention particularly on the cities as they yield great potentials in terms of energy consumption reduction and efficiency increase. As a direct consequence, a comprehensive knowledge of the demand and supply of energy resources, including their spatial distribution within urban areas, is therefore of utmost importance.

Precise, integrated knowledge about urban space, energy infrastructures, buildings’ functional and semantic characteristics, and their mutual dependencies and interrelations play a relevant role for advanced simulation and analyses .

As reported by the Joint Research Centre of the European Commission in Location data for buildings related energy efficiency policies "to implement and monitor energy efficiency policies effectively, local authorities and Member States are required to report on baseline scenarios (e.g. the Baseline Emissions Inventories in the Covenant of Mayors initiative) and on progress made at regular intervals (Annual Reports for the Energy Efficiency Directive and the Energy Performance of Buildings Directive and Monitoring Emissions Inventories every two years for the CoM)”.

Indeed, reporting tools are already available to local authorities and Member States, but they are very basic and only allow users to input aggregated and approximated values (for example, local authorities may rely on national data when local data are not available) for planning and monitoring progress towards targets. Therefore, a common framework for monitoring of energy efficiency policies, with harmonised data from building to district and ending at national level could improve the interoperability of the different directives / initiatives.

Scaling and relation between EU Directives and location (source: EC JRC, 2015, Location data for buildings related energy efficiency policies)

Within such a framework, geo-referencing all the relevant building data accurately and consistently will significantly improve data quality and reliability, enable effective scenario modelling to fill gaps in data, and support the overall policy process. Furthermore, from a potential market perspective, web-based tools providing access to the energy performance of geo-referenced buildings could improve territorial knowledge, and support, for example, the activities of energy service companies and companies involved in construction / renovation of buildings..

Scope and targets of this section

In the CitiEnGov project, Participant Partners have been asked to collect energy-related data about buildings, transport and public lighting and made them available (whole or subset) defining a harmonized “energy data model” together with ICT services for sharing energy-related data. This document describes a transnational methodology, based on one hand on the evaluation of tools implemented by CitiEnGov partners, and on the other hand on standards and technologies already available at European scale for sharing interoperable energy-related data.

Due to the technical its nature, the text presented here is mainly addressed to ICT and geo-ICT experts, with sufficient skills on:

  • Data and database modelling, data extraction/transformation/load
  • Web services for presenting and sharing data
  • Standards for interoperability, in particular related to geographic information


This text is also available in pdf version, available here.


The CitEnGov harmonized data model

In CitiEnGov the three main “sectors” considered are:

  • Buildings
  • Mobility
  • Public lighting

Actually, as described in the Covenant of Mayors’ website, “action plans (SEAPs or SECAPs) should include actions that cover the sectors of activity from both public and private actors, covering the whole geographical area of the local authority committed” (open reference).

Signatories are free to choose their main areas of action. In principle, it is anticipated that most action plans will cover the sectors that are taken into account within the emission inventory and risk and vulnerability assessment (for SECAP only). For the mitigation part (both SEAP and SECAP), it is recommended to include actions targeting the Covenant key sectors:

  • Municipal buildings, equipment/facilities
  • Tertiary (non municipal) buildings, equipment/facilities
  • Residential buildings
  • Transport
  • Industry
  • Local electricity production
  • Local heat/cold production
  • Others (e.g. Agriculture, Forestry, Fisheries)

For the adaptation part (SECAP only), the identification of the sectors to increase the resilience in a city is highly contextual; some of the main sectors that can improve the resilience of cities include:

  • Infrastructure
  • Public Services
  • Land Use Planning
  • Environment & Biodiversity
  • Agriculture & Forestry
  • Economy

Transnationality and the need for using INSPIRE

The idea presented here is to build up the “transnational template” starting from initiatives already defined at European level by the data specifications related to the INSPIRE Directive.

The conceptual model starts from the Data Specifications defined by the INSPIRE Directive as baseline, and considers all requirements and characteristics of energy data that partners provided.

Even though the implementation of INSPIRE data models is not the focus neither the goal of CitiEnGov they will be used as a starting point and as a common approach to get a common view and common semantics about energy-data.

Therefore, the objective of this activity will be twofold:

  • a common conceptual data model, to be considered as a possible target schema for exporting and sharing data outside the local context and outside the organization;
  • a reference implementation, as SQL-based relational database (possibly for Oracle and PostGIS platforms)

It is noteworthy that the final goal is not to force CitiEnGov partners to change the way they use energy-related data internally, but to help them to generate a neutral and standardized semantics.

The importance of sharing the same semantics about energy-related data can be simply clarified with the following example: on March 2017, during a CitiEnGov videoconference (SIPRO, GOLEA, DEDAGROUP PUBLIC SERVICES) it was discussed a practical requirement coming from Slovenian regions, where data about energy consumptions are usually shared from utilities (data providers/custodians) and Public Authorities. Data about consumption are:

  • temporally aggregated on annual basis
  • divided by fuel (e.g. gas, electricity, district heating, … )
  • divided by “building” categories

In the case of building “categories” GOLEA mentioned that they usually get these data divided in terms of “uses of buildings”:

  • residential
  • industrial
  • offices
  • commerce

Indeed, even though these categories are quite similar in different countries, often they do not have the same meaning. That’s why we need to look at INSPIRE in terms of semantics (and not merely in terms of Directive’s principles, data requirements or technical specifications); semantics practically means that we already have some basic concepts like buildings’ typologies, or (better) “uses of buildings” already defined by INSPIRE: http://inspire.ec.europa.eu/codelist/CurrentUseValue

The codelist above contains what INSPIRE conceives when we think of “uses of buildings”. This codelist is:

Of course, this is just a simple example of what we mean when talking about “semantics” related to energy data. In the deliverable DT1.2.1 project partners already shared a common definition of other “concepts” like:

  • energy type (primary, estimated, final, …)
  • energy source (biogas, natural gas, electricity, solid fuels, warm water o stream, …)
  • heating systems (central heating, district heating, electric radiators, solar heating, stove, …)
  • … etc

A first conceptual version of the data model has been provided to CitiEnGov partners in July 2017. To facilitate the understanding and the further agreement of the conceptual model (by September 15th, 2017), CitiEnGov partners have been provided 2 different documents:

  • PowerPoint slides, explaining the rationale of the proposed data model
  • Excel spreadsheet, containing the list of classes/tables and their attributes needed to cover all possible aspects of “energy database” related to buildings, transport and public lighting

The data model consists of 3 main classes (that will be tables in the physical database implementation) corresponding to the 3 sectors the project is focused on:

  • building
  • transport
  • installation (public light)

A physical implementation of the data model has been developed in CitiEnGov with a standard SQL structure provided to all CitiEnGov partners; the CitiEnGov SQL data model is available for the two spatial relational database platforms mostly used: Oracle and PostgreSQL/PostGIS.


Conceptual data model

As aforementioned, the data model relies on the INSPIRE Data Specifications: for instance for the "Buildings" sector the Technical Guidelines considered are available at: http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_BU_v3.0.pdf

The following tables contain the draft version of the conceptual model provided to partners.


Table 1 - Building

Attribute Name Attribute Description Data type Notes
UUID Primary ID text string Unique ID for the record (building unit , building or district)
UUID_BDG2BDG Parent building ID text string The primary ID of the element (building unit , building or district) of which the record is part: e.g. a building unit pointing to the building it is part of.
GEOMETRY Geomerty Geomerty Mandatory. Can be either point, 2D polygon
IDENTIFIER_ID_NAME Dataset namespace text string Allows to identify the records that refer to different sets of building data, e.g. the dataset of municipal buildings, the dataset of private buildings aggregated at district level, etc.
IDENTIFIER_ID_LOC Dataset namespace ID text string An optional local ID to identify records within the same dataset namespace
EXT_REF_INF_SYS_NAME External information system name text string Allows to link the record with an external information system where the same element is also listed: e.g. National Building Cadastre Database
EXT_REF_IDENTIFIER External information system URL text string E.g. www.nationalcadastre.eu
EXT_REF_REFERENCE External information system ID text string The ID that the element described in the record has in the external information system.

This field could be used also to store the installation address.

NAME Name of of the element in the record text string E.g. "Primary School 'Antonio Vivaldi'", or "City District 7"
LIFESPAN_BEGINNING Date of record creation date Describes when the record was created
LIFESPAN_END Date of record validity end date Optional. Describes when the information in the record stops to be valid.
BUILDINGTYPE Architectural typology CODELIST E.g. Single-family house, Monument, Office building, Gas station, etc
ROOF_TYPE Roof type CODELIST
DATE_C_BEGINNING Construction year (begin) integer number (yyyy) If the exact construction year is known it should be written here. If only a reference period is known, write here the year at the beginning of the period.
DATE_C_END Construction year (end) integer number (yyyy) Optional. If only a reference period is known, write here the year at the end of the period.
HEIGHT_HEIGHT_LOW Lower reference for height value CODELIST Where the height is considered to be starting from: e.g. "from the ground level"
HEIGHT_HEIGHT_REF Higher reference for height value CODELIST Where the height is considered to be finishing at e.g. "at the rooftop"
HEIGHT_HEIGHT_STAT Heigth value type text string How was determined the height: measured, estimated, etc
HEIGHT_HEIGHT_VAL Height value (m) real number
FLOORS Number of floors integer number
H_FLOOR Average floor height real number
UNITS Number of building units integer number
USE_S Predominant use CODELIST

Physical implementation of data model

aaaa

ICT services to share energy data

aaaa

Discovery services

aaaa

View services

aaaa

Download services

aaaa

Processing services

aaaa

Technical references for services

This section contains the technical references about interfaces, versions, operations, etc. required at server or client levels. Indeed, the details of these technical references are based on previous EU projects (e.g. eENVplus, GeoSmartCity) available at the deliverables public access pages.

The detailed list of technical specifications is available in the separate page ICT technical guidelines.