Guidelines_EnergyADE.md 73.6 KB
Newer Older
1
# Overview of the Energy Application Domain Extension
2

RomainNouvel's avatar
RomainNouvel committed
3
## Motivation and design objectives
4

RomainNouvel's avatar
RomainNouvel committed
5
The CityGML Energy Application Domain Extension (Energy ADE) aims at extending the CityGML 2.0 standard with energy-related entities and attributes necessary to perform energy analyses at urban scale, such as energy demand diagnostics, solar potential study, simulation of low-carbon energy strategies etc...
Esteban Munoz's avatar
Esteban Munoz committed
6

RomainNouvel's avatar
RomainNouvel committed
7
8
9
In accordance with the philosophy of CityGML, the Energy ADE aims to be flexible in terms of compatibility with different data qualities and levels of details. His design is driven by the following objectives : 
- store and manage energy-related data collected at urban scale, based on the standard data specification of INSPIRE Directive of the European Parliament, as well as the recent US Building Energy Data Exchange Specification (BEDES). 
- provide information data required by different urban energy models and simulation (e.g. from standard energy balance methods as of ISO 13790, to sub-hourly dynamic simulations by means of software programs like CitySim or EnergyPlus)
10

RomainNouvel's avatar
RomainNouvel committed
11
12
13
## General structure overview

Its structure is conceived to be modular, so as to be potentially used and extended also for other applications (e.g. module Occupancy for socio-economics, module Construction and Materials for acoustics or statics, etc). It consists of 5 modules:
gioagu's avatar
gioagu committed
14
15
16
- Building Physics module,
- Occupancy module,
- Construction and Material module,
RomainNouvel's avatar
RomainNouvel committed
17
- Energy Use and System module,
gioagu's avatar
gioagu committed
18
19
- Timeseries and Schedules module.

RomainNouvel's avatar
RomainNouvel committed
20
21
22
23
24
25
The Building Physics module is the core of the Energy ADE. It extends the existing CityGML objects (Abstract Building, BoundarySurface and Opening) and relate them to new thermal entities (ThermalZone, ThermalBoundary, resp. ThermalComponent). Its central object is the ThermalZone, which is the volume unit for heat/cool energy demand calculation.

The Occupancy module is related to the CityGML model (AbstractBuilding) and Building Physics Module (ThermalZone) through its central object : UsageZone. The latter is the spatial unit for user-depending energy use study (e.g. domestic hot water, electrical appliances) and can provide usage boundary conditions for the heat/cool energy demand calculations.

The Construction and Material, Energy Use and System, and Timeseries and Schedules modules are independant « floating modules » which may be connected to different CityGML and Energy ADE CityObjects. 

gioagu's avatar
gioagu committed
26

RomainNouvel's avatar
RomainNouvel committed
27
This document is intended to explain the characteristics and purposes of each module, their entities and attributes. It provides also a number of XML examples, illustrating how and where the Energy ADE entities and attributes may be embedded into CityGML.
28

29
# Building Physics Module
30

31
32
## Module overview and main relationships

RomainNouvel's avatar
RomainNouvel committed
33
34
![Class diagram of Building Physics Module](fig/BuildingPhysics_onlyFeature.png)

RomainNouvel's avatar
RomainNouvel committed
35
...and its types and codelists
RomainNouvel's avatar
RomainNouvel committed
36
![Types and Codelists of Building Physics Module](fig/BuildingPhysics_onlyTypesAndCodelists.png)
RomainNouvel's avatar
RomainNouvel committed
37

38
39
40
41
42
Main purpose of this module is building thermal modeling (e.g. calculation of space heating and space cooling demands).

Thus, it extends the existing CityGML objects `_AbstractBuilding`, `_BoundarySurface`and `_Opening` with energy-related attributes, and define new thermal building objects `ThermalZone`, `ThermalBoundary`, respectively `ThermalComponent` related to them.

The `ThermalZone `is the unit volume for heating and cooling demand calculation. A Building may have several `ThermalZone`, for instance in the case of mixed-usage building, or to distinguish rooms or zones with different orientations (i.e. solar gains) and/or thermal behaviour.
Esteban Munoz's avatar
Esteban Munoz committed
43

44
These `ThermalZone` objects are separated from each other and from the outside by `ThermalBoundary` objects. These `ThermalBoundary` objects may or not correspond to the CityGML `_BoundarySurface`.
45

46
If occupied, a `ThermalZone` must be related to at least 1 `UsageZone`, which contains the usage boundary conditions required for the heating and cooling demand calculation (see Occupancy Module). One `ThermalZone` may be related to several `UsageZone` for simplified modelling of mixed-usage space, in which case the usage boundary conditions of the `UsageZone` should be aggregated or weighted according with their floorArea.
47

RomainNouvel's avatar
RomainNouvel committed
48
## Extension of CityGML building objects
49

50
### \_AbstractBuilding
gioagu's avatar
gioagu committed
51

Esteban Munoz's avatar
Esteban Munoz committed
52
The Energy ADE extends the CityGML _AbstractBuilding by a number of
Esteban Munoz's avatar
Esteban Munoz committed
53
energy-related attributes, e.g with regards to the geometrical characteristics
54
(`referencePoint`, `volume`, `floorArea`, `hightAboveGround`), to the
Esteban Munoz's avatar
Esteban Munoz committed
55
56
available energy certificates (`energyPerformanceCertification`) and
refurbishment measures (`RefurbishmentMeasureOnBuilding`), and other building
57
58
information useful for building typology categorisations (`buildingType`,
`constructionWeight`,`isLandmarked`).
59

60
All these attributes are optional. Some of them, like `volume`, `floorArea` and  
Esteban Munoz's avatar
Esteban Munoz committed
61
62
`energyPerformanceCertification`, have a cardinality [0..*] and may
consequently be attributed several times to a building, specifying different
63
values for different kinds of `VolumeType`, `FloorArea` and `ÈnergyPerformanceCertification`respectively.
64

Esteban Munoz's avatar
Esteban Munoz committed
65
Finally, because `_AbstractBuilding` inherits from `_CityObject`, further
66
objects may be assigned to it, like `WeatherData`and `EnergyDemand`(see Module
Esteban Munoz's avatar
Esteban Munoz committed
67
Energy and Systems).
68

Esteban Munoz's avatar
Esteban Munoz committed
69
70
In the following, an extract of CityGML file for a building is given, included
some of its Energy ADE attributes.
gioagu's avatar
gioagu committed
71
72

```xml
gioagu's avatar
gioagu committed
73
74
<!--Examples of Building with Energy ADE attributes-->
<bldg:Building gml:id="id_building_1">
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
  <gml:description>Description of Building 1</gml:description>
  <gml:name>Name of Building 1</gml:name>
  <energy:referencePoint>
   <gml:Point gml:id="id_building_referencepoint_1" srsName="EPSG:31256" srsDimension="3">
    <gml:pos>2525.5 338567.5 162.6</gml:pos>
   </gml:Point>
  </energy:referencePoint>
  
  <energy:energyPerformanceCertification>
   <!--Here come the EnergyPerformanceCertification objects (see later) -->
  </energy:energyPerformanceCertification>
  
  <energy:heightAboveGround>
   <energy:HeightAboveGround>
    <energy:heightReference>highestEave</energy:heightReference>
    <energy:value uom="m">10.0</energy:value>
   </energy:HeightAboveGround>
  </energy:heightAboveGround>
  
  <energy:heightAboveGround>
   <energy:HeightAboveGround>
    <energy:heightReference>topOfConstruction</energy:heightReference>
    <energy:value uom="m">13.0</energy:value>
   </energy:HeightAboveGround>
  </energy:heightAboveGround>
100
 
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
<energy:volume>
 <energy:VolumeType>
  <energy:type>GrossVolume</energy:type>
  <energy:value uom="m3">1050</energy:value>
 </energy:VolumeType>
</energy:volume> 
  
  <energy:refurbishmentMeasureOnBuilding>
   <energy:RefurbishmentMeasure>
    <!--Here come all attributes of a RefurbishmentMeasure object (omitted here)-->
   </energy:RefurbishmentMeasure>
  </energy:refurbishmentMeasureOnBuilding>
    
  <!--Here may come a list of UsageZone of the building (see Module Occupancy) -->
  
  <energy:isLandmarked>false</energy:isLandmarked>
  <energy:floorArea>
   <!--Here come the floorArea objects (see later)-->
  </energy:floorArea>
  
  <energy:constructionWeight>Heavy</energy:constructionWeight>
  <energy:buildingType>MultiFamilyHouse</energy:buildingType>
  
  <!--Here follow all ThermalZone objects, each inside a "thermalZones" tag-->
  <energy:thermalZone>
   <energy:ThermalZone gml:id="id_thermalzone_1">
    <!--Here come all attributes of the first ThermalZone (omitted here)-->
   </energy:ThermalZone>
  </energy:thermalZone>
  <energy:thermalZone>
   <energy:ThermalZone gml:id="id_thermalzone_2">
    <!--Here come all attributes of the second ThermalZone (omitted here)-->
   </energy:ThermalZone>
  </energy:thermalZone>
 </bldg:Building>
gioagu's avatar
gioagu committed
136
137
138
139
```

#### FloorArea

Esteban Munoz's avatar
Esteban Munoz committed
140
141
Buildings (`_AbstractBuilding`) and building zones (`ThermalZone` and
`UsageZone`) may have several `floorArea`, related to several `FloorAreaType`
142
(e.g. net floor area, gross floor area, energy reference area).
143

gioagu's avatar
gioagu committed
144
```xml
145
<!--Examples of three floor areas-->
gioagu's avatar
gioagu committed
146
<energy:FloorArea>
147
148
149
150
151
152
153
154
155
156
157
158
	<energy:FloorArea>
		<energy:type>GrossFloorArea</energy:type>
		<energy:value uom="m^2">50.0</energy:value>
	</energy:FloorArea>
	<energy:FloorArea>
		<energy:type>NetFloorArea</energy:type>
		<energy:value uom="m^2">40.0</energy:value>
	</energy:FloorArea>
	<energy:FloorArea>
		<energy:type>EnergyReferenceArea</energy:type>
		<energy:value uom="m^2">43.0</energy:value>
	</energy:FloorArea>
gioagu's avatar
gioagu committed
159
</energy:FloorArea>
gioagu's avatar
gioagu committed
160
161
162
163
```

#### EnergyPerformanceCertification

164
165
A building may present several  
`energyPerformanceCertification` related to
Esteban Munoz's avatar
Esteban Munoz committed
166
167
different `certificationName` (e.g. PassivHaus, LEED) and/or different
certification dates (specificied by `certificationId`).
168

gioagu's avatar
gioagu committed
169
```xml
170
<!--Example of two energy performance certifications-->
Joachim Benner's avatar
Joachim Benner committed
171
172
<energy:energyPerformanceCertification>
    <energy:EnergyPerformanceCertification>
173
174
        <energy:certificationRating>Platinum</energy:certificationRating>
        <energy:certificationName>LEED</energy:certificationName>
Joachim Benner's avatar
Joachim Benner committed
175
        <energy:certificationId>0815</energy:certificationId>
176
177
178
179
180
    </energy:EnergyPerformanceCertification>
    <energy:EnergyPerformanceCertification>
        <energy:certificationRating>Passive house</energy:certificationRating>
        <energy:certificationName>EnerPHit</energy:certificationName>
        <energy:certificationId>4756</energy:certificationId>
181
    </energy:EnergyPerformanceCertification>
Joachim Benner's avatar
Joachim Benner committed
182
</energy:energyPerformanceCertification>
183

gioagu's avatar
gioagu committed
184
185
186
187
```

#### RefurbishmentMeasure

Esteban Munoz's avatar
Esteban Munoz committed
188
189
190
191
Energy-efficient refurbishment operations and measures may be indicated as
attribute of `_AbstractBuilding`, `_BoundarySurface` and `_Opening`. The
`RefurbishmentMeasure` object contains two information: the date and level of
refurbishment.
192

Esteban Munoz's avatar
Esteban Munoz committed
193
194
195
196
197
198
199
The attribute `levelOfRefurbishment` is a codeList whose elements generally
relates to refurbishment measure libraries or to a building typology
categorisation.

The attribute `dateOfRefurbishment` is defined by the GML type `DateOfEvent`,
and may consequently be specified in different manners (see the 3 examples
below).
200

gioagu's avatar
gioagu committed
201
```xml
202
<!--Example of a Refurbishment Measure on a building with a very vague date ("before June 2010") -->
Joachim Benner's avatar
Joachim Benner committed
203
204
205
206
207
208
209
210
<energy:refurbishmentMeasureOnBuilding>
    <energy:RefurbishmentMeasure>
        <energy:dateOfRefurbishment>
            <energy:DateOfEvent>
                <energy:instant indeterminatePosition="before">2010-06</energy:instant>
            </energy:DateOfEvent>
        </energy:dateOfRefurbishment>
        <energy:levelOfRefurbishment>UsualRefurbishment</energy:levelOfRefurbishment>
211
        <gml:description>Refurbishment consisting of an outside insulation of walls etc.</gml:description>
Joachim Benner's avatar
Joachim Benner committed
212
213
    </energy:RefurbishmentMeasure>
</energy:refurbishmentMeasureOnBuilding>
gioagu's avatar
gioagu committed
214
215
```

216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
```xml
<!--Example of an advanced Refurbishment Measure in the years 1998 and 1999 -->
<energy:refurbishmentMeasureOnBuilding>
    <energy:RefurbishmentMeasure>
        <energy:dateOfRefurbishment>
            <energy:DateOfEvent>
                <energy:period>
                    <gml:TimePeriod>
                        <gml:beginPosition>1998</gml:beginPosition>
                        <gml:endPosition>2000</gml:endPosition>
                    </gml:TimePeriod>
                </energy:period>
            </energy:DateOfEvent>
        </energy:dateOfRefurbishment>
        <energy:levelOfRefurbishment>AdvancedRefurbishment</energy:levelOfRefurbishment>
    </energy:RefurbishmentMeasure>
232
</energy:refurbishmentMeasureOnBuilding>
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
```

```xml
<!--Example of an usual Refurbishment Measure in June 2012 -->
<energy:refurbishmentMeasureOnBuilding>
    <energy:RefurbishmentMeasure>
        <energy:dateOfRefurbishment>
            <energy:DateOfEvent>
                <energy:instant>2012-06</energy:instant>
            </energy:DateOfEvent>
        </energy:dateOfRefurbishment>
        <energy:levelOfRefurbishment>UsualRefurbishment</energy:levelOfRefurbishment>
    </energy:RefurbishmentMeasure>
</energy:refurbishmentMeasureOnBuilding>
```

249
250
### \_Opening

Esteban Munoz's avatar
Esteban Munoz committed
251
252
The CityGML abstract class `_Opening` (inherited by the objects `Window` and
`Door`) is extended in this Energy ADE by a number of energy-related
253
attributes.
254

Esteban Munoz's avatar
Esteban Munoz committed
255
256
257
258
259
260
261
262
First of all, an optional attribute `openableRatio` details the proportion of
the opening area which may be opened. An indoor and an outdoor shading system
may complement the opening, with a `ShadingType` characterized by a
`transmittance` (see details in Module Materials and Constructions) and a
`maximumCoverRatio`. Finally, information about possible refurbishment measures
and operations may also be added at the level of the opening (e.g window
exchange), through the attribute `refurbishmentMeasureOnOpening` of type
`RefurbishmentMeasure`.
263

Esteban Munoz's avatar
Esteban Munoz committed
264
265
266
As in the Building example shown before, the standard CityGML attributes have
been omitted for better readability. The door example is simpler and contains
also information about construction and construction orientation (by means of
Esteban Munoz's avatar
Esteban Munoz committed
267
Xlinks).
268
269
270
271

```xml
<!--Example of a Window object -->
<bldg:Window gml:id="id_window_1">
272
	<gml:description>This is window with an outside rolling shutter and curtains inside</gml:description>
273
	<gml:name>Window with rolling shutter and curtains</gml:name>
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305

	<energy:outdoorShading>
		<energy:ShadingType>
			<energy:maximumCoverRatio uom="ratio">1</energy:maximumCoverRatio>
			<energy:name>Rolling shutter</energy:name>
			<energy:transmittance>
				<energy:Transmittance>
					<energy:fraction uom="ratio">0</energy:fraction>
					<energy:wavelengthRange>Total</energy:wavelengthRange>
				</energy:Transmittance>
			</energy:transmittance>
		</energy:ShadingType>
	</energy:outdoorShading>

	<energy:indoorShading>
		<energy:ShadingType>
			<energy:maximumCoverRatio uom="ratio">0.5</energy:maximumCoverRatio>
			<energy:name>Curtain</energy:name>
			<energy:transmittance>
				<energy:Transmittance>
					<energy:fraction uom="ratio">0.8</energy:fraction>
					<energy:wavelengthRange>Total</energy:wavelengthRange>
				</energy:Transmittance>
			</energy:transmittance>
		</energy:ShadingType>
	</energy:indoorShading>

	<energy:openableRatio uom="ratio">0.9</energy:openableRatio>

</bldg:Window>
```

306
### \_BoundarySurface, globalSolarIrradiance and daylightIlluminance
307

Esteban Munoz's avatar
Esteban Munoz committed
308
309
310
311
312
313
314
The CityGML abstract class `_BoundarySurface` is extended by a number of Energy
ADE attributes, in order in particular to store the incident global solar
irradiances and the daylight illuminances available on each outside boundary
surface of the building. Moreover,  information about refurbishment measures on
roof or facade can characterised the `_BoundarySurface` objects, in the same
way that the buildings and openings, through the attribute
`refurbishmentMeasureOnBoundarySurface` of type `RefurbishmentMeasure`.
315

Esteban Munoz's avatar
Esteban Munoz committed
316
317
318
319
320
321
The `globalSolarIrradiance` is the sum of the direct, diffuse and reflected
irradiance incident on a outside boundary surface and is generally expressed in
Watts per square metre.  These global solar irradiance is generally used for
the thermal calculations within the buildings, but also for the calculation of
the energy yield produced by the solar systems (e.g. photovoltaic and solar
thermal panels).
322

Esteban Munoz's avatar
Esteban Munoz committed
323
The `daylightIlluminance` is the sum of the direct, diffuse and reflected solar
Esteban Munoz's avatar
Esteban Munoz committed
324
325
326
327
illuminance incident on a outside boundary surface. It is generally expressed
in Lux. Daylight illuminance is typically used for outside and inside
daylighting study, as well as the calculation of the energy consumptions of
lighting systems required to reach the room illuminance threshold when the
Esteban Munoz's avatar
Esteban Munoz committed
328
daylight illuminance is not enough.
Esteban Munoz's avatar
Esteban Munoz committed
329

Esteban Munoz's avatar
Esteban Munoz committed
330
331
332
Both `globalSolarIrradiance` and `daylightIlluminance` attributes are
`_Timeseries` data (see details in Temporal Data Module).  In the following, a
XML example of a roof is given.
333
334
335

```xml
<!--Example of a Roof object -->
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
<bldg:RoofSurface gml:id="id_roof_1">
	<gml:description>Description of Roof 1</gml:description>
	<gml:name>Name of Roof 1</gml:name>

	<energy:refurbishmentMeasureOnBoundarySurface>
		<energy:RefurbishmentMeasure>
			<!--Here come all attributes of a RefurbishmentMeasure object (omitted here)-->
		</energy:RefurbishmentMeasure>
	</energy:refurbishmentMeasureOnBoundarySurface>

	<energy:globalSolarIrradiance>
		<!--Add here the TimeSeries data -->
	</energy:globalSolarIrradiance>

	<energy:daylightIlliminance>
		<!--Add here the TimeSeries data -->
	</energy:daylightIlliminance>

</bldg:RoofSurface>
355
356
```

RomainNouvel's avatar
RomainNouvel committed
357
358
## Thermal zones, thermal boundaries and thermal components

359
### ThermalZone
360

Esteban Munoz's avatar
Esteban Munoz committed
361
362
363
364
365
366
The `ThermalZone` is a new object introduced in the Energy ADE to realize
building heating and cooling demand calculation. A `ThermalZone` is a zone of a
`Building` (or of a `BuildingPart`) which serves as the smallest spatial zone
for building heating and cooling demand calculation. It is generally a "thermal
homogeneous" space considered as isothermal, but may also refer to several
building rooms and zones with different usage boundary conditions for
367
simplified building energy modelling.
Esteban Munoz's avatar
Esteban Munoz committed
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382

A `ThermalZone` contains a series of energy-related attributes which
characterize its geometry (`floorArea`, `grossVolume`, `netVolume`,
`volumeGeometry`), its conditioning status (`isCooled`, `isHeated`,
`indirectlyHeatedAreaRatio`) and overall building physics properties
(`additionalThermalBridgeUValue`, `infiltration rate`,
`effectiveThermalCapacity`).

All these attributes are optional. Among those, `floorArea` may be attributed
several times to a building, specifying different values for different
`FloorAreaType`. A `ThermalZone` may optionally contain an explicit volume
geometry (specified by `volumeGeometry`), useful in particular for
visualisation purposes, but not necessary for heating and cooling demand
calculations. The `ThermalZone` may also be related to a room (`gml:Room`). The
actual surface boundaries of a `ThermalZone` are defined by means of
Esteban Munoz's avatar
Esteban Munoz committed
383
`ThermalBoudary` objects (see later).
384

Esteban Munoz's avatar
Esteban Munoz committed
385
386
387
388
389
390
391
If occupied, a `ThermalZone` must be related to at less one `UsageZone` object
(see Occupancy Module), which contains the usage boundary conditions for the
heating and cooling demand calculation (see Occupancy Module). `ThermalZone`
may even be related to several `UsageZone` for simplified modelling of
mixed-usage space, in which case the usage boundary conditions of the UsageZone
should be aggregated or weighted according with their `floorArea`.

Esteban Munoz's avatar
Esteban Munoz committed
392
The class `ThermalZone` inherits from `_CityObject`, and may therefore be
393
associated to one or more `EnergyDemand` objects (see module Energy Systems).
Esteban Munoz's avatar
Esteban Munoz committed
394
395
396

In the following, Two XML examples present a `ThermalZone`, with and without
explicit volume geometry.
397

398
```xml
399
<!--Example of a ThermalZone without explicit volume geometry-->
gioagu's avatar
gioagu committed
400
401
402
<energy:ThermalZone gml:id="id_thermalzone_1">
	<gml:description>Description of Thermal Zone 1</gml:description>
	<gml:name>Name of Thermal Zone 1</gml:name>
403
404
	<energy:additionalThermalBridgeUValue uom="W/(K*m^2)">0.5</energy:additionalThermalBridgeUValue>
	<energy:effectiveThermalCapacity uom="J/K">500</energy:effectiveThermalCapacity>
gioagu's avatar
gioagu committed
405
406
	<energy:floorArea>
		<energy:FloorArea>
407
408
			<energy:type>EnergyReferenceArea</energy:type>
			<energy:value uom="m^2">55.0</energy:value>
gioagu's avatar
gioagu committed
409
410
411
		</energy:FloorArea>
	</energy:floorArea>
	<energy:grossVolume uom="m^3">200.0</energy:grossVolume>
412

413
	<!-- here follows a related usage zone -->
gioagu's avatar
gioagu committed
414
	<energy:relates xlink:href="#id_usagezone_1"/>
415

416
417
	<energy:indirectlyHeatedAreaRatio uom="ratio">0.15</energy:indirectlyHeatedAreaRatio>
	<energy:infiltrationRate uom="1/h">1.2</energy:infiltrationRate>
gioagu's avatar
gioagu committed
418
419
	<energy:isCooled>true</energy:isCooled>
	<energy:isHeated>true</energy:isHeated>
420
	<energy:netVolume uom="m^3">180.0</energy:netVolume>
421

gioagu's avatar
gioagu committed
422
423
424
425
426
427
428
429
430
431
432
	<!--Here follow all ThermalBoundary objects, each inside a "boundedBy" tag-->
	<energy:boundedBy>
		<energy:ThermalBoundary gml:id="id_thermalboundary_1">
			<!--Here come all attributes of the first ThermalBoundary (omitted here)-->
		</energy:ThermalBoundary>
	</energy:boundedBy>
	<energy:boundedBy>
		<energy:ThermalBoundary gml:id="id_thermalboundary_2">
			<!--Here come all attributes of the second ThermalBoundary (omitted here)-->
		</energy:ThermalBoundary>
	</energy:boundedBy>
433

gioagu's avatar
gioagu committed
434
</energy:ThermalZone>
435
```
436

gioagu's avatar
gioagu committed
437
438
439
440
```xml
<!--Example of a ThermalZone with explicit volume geometry-->
<energy:ThermalZone gml:id="id_thermalzone_2">
	<!--Additional attributes of the ThermalZone (omitted here)-->
441

gioagu's avatar
gioagu committed
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
	<energy:volumeGeometry>
		<gml:Solid gml:id="id_thermalzone_volume_geometry_1" srsName="EPSG:31256" srsDimension="3">
			<gml:exterior>
				<gml:CompositeSurface>
					<gml:surfaceMember>
						<gml:Polygon>
							<gml:exterior>
								<gml:LinearRing>
									<gml:posList>0 0 0 0 10 0 5 10 0 5 0 0 0 0 0</gml:posList>
								</gml:LinearRing>
							</gml:exterior>
						</gml:Polygon>
					</gml:surfaceMember>
					<gml:surfaceMember>
						<gml:Polygon>
							<gml:exterior>
								<gml:LinearRing>
									<gml:posList>0 0 4 5 0 4 5 10 4 0 10 4 0 0 4</gml:posList>
								</gml:LinearRing>
							</gml:exterior>
						</gml:Polygon>
					</gml:surfaceMember>
					<!--Here come further surfaceMember objects-->
					</gml:CompositeSurface>
			</gml:exterior>
		</gml:Solid>
	</energy:volumeGeometry>
</energy:ThermalZone>
```

### ThermalBoundary
473

Esteban Munoz's avatar
Esteban Munoz committed
474
475
476
A `ThermalBoundary` represent the physical relationship between two
`ThermalZone`, or one `ThermalZone` and the building environment. Its
geometrical representation is a coplanar, or quasi coplanar, surface.
477

Esteban Munoz's avatar
Esteban Munoz committed
478
479
Each `ThermalZone` is geometrically closed by its whole set of bounding
`ThermalBoundary` (specificied in the relationship "boundedBy").
480

Esteban Munoz's avatar
Esteban Munoz committed
481
482
483
484
485
486
487
488
489
In the case where the `ThermalBoundary` delimits one `ThermalZone` from the
building environment, corresponding then to the external boundary of a
building, its geometrical representation coincides with the external surfaces
of the related outer wall/roof/basement floor. In this case, the
`ThermalBoundary` should be linked to the corresponding `_BoundarySurface`
object (e.g. a `WallSurface`, a `RoofSurface`, a `GroundSurface` in LoD2) if
existing, through the relationship "correspondsTo". It may however occurs that
such `ThermalBoundary` does not match with any `_BoundarySurface` (e.g.
basement ceiling, attic floor).
gioagu's avatar
gioagu committed
490

Esteban Munoz's avatar
Esteban Munoz committed
491
492
493
494
495
496
In the case where the `ThermalBoundary` separate two adjacent `ThermalZone`,
corresponding then to an intermediate floor, ceiling, or a shared wall, its
geometrical representation coincides with the plan laying at the middle of this
construction thickness.

The following figure represents these 2 different cases in a building side
Esteban Munoz's avatar
Esteban Munoz committed
497
section, relating the Energy ADE objects `ThermalZone` and `ThermalBoundary` to
Esteban Munoz's avatar
Esteban Munoz committed
498
the CityGML objects `Room` and `_BoundarySurface`.
499

500
![Schema of adjacent thermal zones](fig/ThermalZoneAdjacency.png)
501

502
`ThermalBoundary` may contain attributes characterizing their type  
Esteban Munoz's avatar
Esteban Munoz committed
503
504
505
506
507
508
(`thermalBoundaryType`), orientation (`azimuth` and `inclination`) and explicit
geometry (`surfaceGeometry`). All these attributes are optional. Thus, a
`ThermalZone` may optionally contain an explicit surface geometry (specified by
`surfaceGeometry`), useful in particular for visualisation purposes if the
`ThermalBoundary` does not coincide with any `_BoundarySurface`, but not
necessary for heating and cooling demand calculations.
RomainNouvel's avatar
RomainNouvel committed
509

Esteban Munoz's avatar
Esteban Munoz committed
510
511
512
The `ThermalBoundaryType` type is slightly different to the types of
`_BoundarySurface` from CityGML, integrating further thermal boundaries like
AtticFloor, BasementCeiling, BasementFloor or SharedWall.
RomainNouvel's avatar
RomainNouvel committed
513

Esteban Munoz's avatar
Esteban Munoz committed
514
515
Each `ThermalBoundaryType` is composed of `ThermalComponent` (e.g. wall
construction, windows etc.) which holds the `Construction`.
RomainNouvel's avatar
RomainNouvel committed
516

Esteban Munoz's avatar
Esteban Munoz committed
517
518
In the following, two XML examples of `ThermalBoundary`, with and without
explicit geometry are given.
RomainNouvel's avatar
RomainNouvel committed
519

gioagu's avatar
gioagu committed
520
```xml
RomainNouvel's avatar
RomainNouvel committed
521
<!--Example of a ThermalBoundary corresponding to a building roof, delimiting a thermal zone -->
gioagu's avatar
gioagu committed
522
523
524
<energy:ThermalBoundary gml:id="id_thermalboundary_1">
	<gml:description>Thermal Boundary 1</gml:description>
	<gml:name>Thermal Boundary 1</gml:name>
gioagu's avatar
gioagu committed
525
	<energy:azimuth uom="decimal degrees">135</energy:azimuth>
RomainNouvel's avatar
RomainNouvel committed
526
	<energy:inclination uom="decimal degrees">55</energy:inclination>
gioagu's avatar
gioagu committed
527
	<energy:thermalBoundaryType>Roof</energy:thermalBoundaryType>
RomainNouvel's avatar
RomainNouvel committed
528
	<partOf xlink:href="#id_thermalzone_1"/>
gioagu's avatar
gioagu committed
529
530
531
532
533
534
535
536
537
538
	<energy:composedOf>
		<energy:ThermalComponent gml:id="id_thermalcomponent_1">
			<!--Here come all attributes of the first ThermalComponent (omitted here)-->
		</energy:ThermalComponent>
	</energy:composedOf>
	<energy:composedOf>
		<energy:ThermalComponent gml:id="id_thermalcomponent_2">
			<!--Here come all attributes of the second ThermalComponent (omitted here)-->
		</energy:ThermalComponent>
	</energy:composedOf>
RomainNouvel's avatar
RomainNouvel committed
539
	<correspondsTo xlink:href="#id_RoofSurface_1"/>
gioagu's avatar
gioagu committed
540
541
</energy:ThermalBoundary>
```
542

gioagu's avatar
gioagu committed
543
```xml
RomainNouvel's avatar
RomainNouvel committed
544
<!--Example of a ThermalBoundary with explicit surface geometry, separating two thermal zones -->
gioagu's avatar
gioagu committed
545
546
<energy:ThermalBoundary gml:id="id_thermalboundary_2">
	<!--Additional attributes of the ThermalBoundary class (omitted here)-->
547

gioagu's avatar
gioagu committed
548
549
550
551
552
553
554
555
556
557
558
559
560
	<energy:surfaceGeometry>
		<gml:MultiSurface gml:id="id_thermalboundary_2_surface_geometry" srsName="EPSG:31256" srsDimension="3">
			<gml:surfaceMember>
				<gml:Polygon>
					<gml:exterior>
						<gml:LinearRing>
							<gml:posList>0 0 0 0 10 0 5 10 0 5 0 0 0 0 0</gml:posList>
						</gml:LinearRing>
					</gml:exterior>
				</gml:Polygon>
			</gml:surfaceMember>
		</gml:MultiSurface>
	</energy:surfaceGeometry>
RomainNouvel's avatar
RomainNouvel committed
561
562
	<partOf xlink:href="#id_thermalzone_1"/>
	<partOf xlink:href="#id_thermalzone_2"/>
gioagu's avatar
gioagu committed
563
564
</energy:ThermalBoundary>
```
565

gioagu's avatar
gioagu committed
566
### ThermalComponent
567

Esteban Munoz's avatar
Esteban Munoz committed
568
569
A `ThermalComponent` object is a part of the thermal boundary corresponding to
a homogeneous construction component (e.g. windows, wall, insulated part of a
570
571
wall etc.) and either entirely above or below the terrain. 
Each `ThermalComponent` must be characterized with its `Area`, and its position relative to the Terrain (attribute `relativeToTerrain` which it inherits from `_CityObject`).
Esteban Munoz's avatar
Esteban Munoz committed
572

573
Since `ThermalComponent` inherits from `_CityObject`, it can also be associated to a
Esteban Munoz's avatar
Esteban Munoz committed
574
575
576
577
`Construction` object (see module Construction and Material). This may be done
either inline or by means of xlinks (see example below). In this way,
`ThermalComponent` provides the physical properties of the building envelope to
calculate the heating and cooling demand.
578

gioagu's avatar
gioagu committed
579
```xml
RomainNouvel's avatar
RomainNouvel committed
580
581
<!--Example of a Facade with 20% window to wall ratio -->
<energy:ThermalBoundary gml:id="Id_Facade_1">
582
583
584
585
586
	<energy:thermalBoundaryType>OuterWall</energy:thermalBoundaryType>
	<energy:partOf xlink:href="ID_ZONE_1"/>
	<energy:composedOf>
		<energy:ThermalComponent gml:id="id_Wall_1">
	  		<gml:description>Part of the facade of wall</gml:description>
587
	  		<relativeToTerrain>entirelyAboveTerrain</relativeToTerrain>
588
589
590
591
592
593
594
	  		<energy:construction xlink:href="#id_WallConstruction_1"/>
	  		<energy:area uom="m^2">40.0</energy:area>
    		</energy:ThermalComponent>
  	</energy:composedOf>
  	<energy:composedOf>
		<energy:ThermalComponent gml:id="id_Window_1">
	      		<gml:description>Part of the facade of windows</gml:description>
595
	      		<relativeToTerrain>entirelyAboveTerrain</relativeToTerrain>
596
597
598
599
600
	      		<energy:construction xlink:href="#id_WindowConstruction_1"/>
	      		<energy:area uom="m^2">10.0</energy:area>
	      		<energy:relates xlink:href="#opening_window_1"/>
    		</energy:ThermalComponent>
  	</energy:composedOf>				
RomainNouvel's avatar
RomainNouvel committed
601
</energy:ThermalBoundary>
gioagu's avatar
gioagu committed
602
```
603

604
# Temporal Data Module
605

606
607
608
609
610
611
612
613
This module introduces the two new types `_TimeSeries` and `_Schedules`,
essential to model the time-depending inputs and results of urban energy
analyses. These types are used in other Modules of the Energy ADE, in
particular the module Occupancy and module Energy and Systems.

As theses types are actually not domain-specific, we are collaborating with the
development team of the CityGML 3.0 to integrate them in the new CityGML 3.0 to
come (as Dynamizer).
614

615
## Time Series
616

RomainNouvel's avatar
RomainNouvel committed
617
![Class diagram of ADE Energy Core - Time Series](fig/TimeSeries.png)
618

Esteban Munoz's avatar
Esteban Munoz committed
619
Time series are homogeneous lists of time-depending values. They are used in
Esteban Munoz's avatar
Esteban Munoz committed
620
621
622
623
624
the Energy ADE to store energy amount or an occupancy schedule, for instance. 

All time series share some common properties, gathered in the
`TimeValuesProperties` type object. This object specifies optionally the
`acquisitionMethod` (e.g. simulated with software X, measured with heat meter),
625
626
627
628
629
`interpolationType` (based on the [WaterML ADE][] to know for instance if
measured data are "Average in Preceding Interval", or "Instantaneous Total"),
`qualityDescription` and `source` of the time series data.
Additionally, `_TimeSeries`may contain the the usual GML type attributes `name`
and `description`.
Esteban Munoz's avatar
Esteban Munoz committed
630
631
632
633
634
635
636

Time series can be either regular or irregular. `RegularTimeSeries` contain
`values` generated at regularly spaced interval of time (`timeInterval`), over
a given `temporalExtent` (i.e. start, end and duration time). They are used,
for instance, to store automatically acquired data or hourly/daily/monthly
simulation results.
In `IrregularTimeSeries`, data follows a temporal sequence, but the measurement
637
638
points may not happen at a regular time interval ([IBM knowledge Center][]).
Therefore, each value must be associated with a data or time.
Esteban Munoz's avatar
Esteban Munoz committed
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653

Time series values may be also stored on an external file (e.g. csv or text),
both for regular (`RegularTimeSeriesFile`) and irregular time series
(`IrregularTimeSeriesFile`). A number of attributes must be detailed to
retrieve the `file`, interprete the formats and values inside it
(`decimalSymbol`, `recordSeparator`, `fieldSeparator`, `numberOfHeaderLines`,
`uom`), and know which values of the file should be read (`timeColumnNumber`
for irregular time series and `valueColumnNumber` for both of them). One file
with different records may be reused by different `RegularTimeSeriesFile` or
`IrregularTimeSeriesFile` with the corresponding `valueColumnNumber`.

In the following, four examples of time series illustrates the four types of
time series. The variableProperties and gml attributes are presented in the
first example but not always repeated in the following examples for better
readibility.
654

655
Example of RegularTimeSeries object:
656

gioagu's avatar
gioagu committed
657
```xml
658
<!--Example of RegularTimeSeries object with daily values-->
659
<energy:RegularTimeSeries gml:id="id_timeseries_electricity_demand_1">
660
661
	<gml:description>Description of the time series id_timeseries_electricity_demand_1</gml:description>
	<gml:name>Name of the  time series id_timeseries_electricity_demand_1</gml:name>
662
663
	<energy:variableProperties>
		<energy:TimeValuesProperties>
664
			<energy:acquisitionMethod>Measured electronically with heat power</energy:acquisitionMethod>
665
			<energy:interpolationType>AverageInSucceedingInterval</energy:interpolationType>
666
667
			<energy:qualityDescription>Accurate (+/- 0.2 kWh)</energy:qualityDescription>
			<energy:source>Subcontracting company X</energy:source>
668
669
670
671
		</energy:TimeValuesProperties>
	</energy:variableProperties>
	<energy:temporalExtent>
		<gml:TimePeriod>
672
673
			<gml:beginPosition>2016-01-01</gml:beginPosition>
			<gml:endPosition>2016-12-31</gml:endPosition>
674
675
		</gml:TimePeriod>
	</energy:temporalExtent>
676
677
	<energy:timeInterval unit="day">1</energy:timeInterval>
	<energy:values uom="kWh">11.2 11.4 10.2 9.6 6.3 11.5 12.7 ... (truncated, set of 365 values) </energy:values>
678
</energy:RegularTimeSeries>
gioagu's avatar
gioagu committed
679
```
680

681
Example of IrregularTimeSeries object:
gioagu's avatar
gioagu committed
682
```xml
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
<!--Example of IrregularTimeSeries object listing one value per year-->
<energy:IrregularTimeSeries gml:id="id_timeseries_electricity_demand_1">
	<energy:variableProperties>
		<energy:TimeValuesProperties>
			<energy:acquisitionMethod>Manual read on electrical meter</energy:acquisitionMethod>
			<energy:interpolationType>InstantTotal</energy:interpolationType>
		</energy:TimeValuesProperties>
	</energy:variableProperties>
	<energy:uom uom="kWh"/>
	<energy:contains>
		<energy:MeasurementPoint>
			<energy:time>2010-02-24</energy:time>
			<energy:value>12050</energy:value>
		</energy:MeasurementPoint>
	</energy:contains>
	<energy:contains>
		<energy:MeasurementPoint>
			<energy:time>2011-02-15</energy:time>
			<energy:value>14050</energy:value>
		</energy:MeasurementPoint>
	</energy:contains>
	<energy:contains>
		<energy:MeasurementPoint>
			<energy:time>2012-03-01</energy:time>
			<energy:value>16245</energy:value>
		</energy:MeasurementPoint>
	</energy:contains>
710
</energy:RegularTimeSeries>
gioagu's avatar
gioagu committed
711
```
712

713
Example of RegularTimeSeriesFile object:
gioagu's avatar
gioagu committed
714
```xml
715
716
717
<!--Example of RegularTimeSeriesFile object with hourly values contained in a file-->
<energy:RegularTimeSeriesFile gml:id="id_regulartimeseries_file_1">
	<energy:uom uom="W/m^2"/>
718
	<energy:file>file_name_containing_values.csv</energy:file>
719
720
	<energy:temporalExtent>
		<gml:TimePeriod>
721
722
			<gml:beginPosition>2008-01-01</gml:beginPosition>
			<gml:endPosition>2008-12-31</gml:endPosition>
723
724
725
726
727
728
729
		</gml:TimePeriod>
	</energy:temporalExtent>
	<energy:timeInterval unit="hour">1</energy:timeInterval>
	<energy:numberOfHeaderLines>1</energy:numberOfHeaderLines>
	<energy:valueColumnNumber>1</energy:valueColumnNumber>
	<energy:fieldSeparator>\t</energy:fieldSeparator>
</energy:RegularTimeSeriesFile>
gioagu's avatar
gioagu committed
730
```
731

732
Example of IrregularTimeSeriesFile object:
gioagu's avatar
gioagu committed
733
```xml
734
735
736
737
738
739
740
741
742
743
744
<!--Example of IrregularTimeSeriesFile object-->
<energy:RegularTimeSeriesFile gml:id="id_regulartimeseries_file_1">
	<energy:uom uom="W/m^2"/>
	<energy:file>file_name_containing_values.csv</energy:file>
	<energy:numberOfHeaderLines>1</energy:numberOfHeaderLines>
	<energy:recordSeparator> </energy:recordSeparator>
	<energy:decimalSymbol>,</energy:decimalSymbol>
	<energy:valueColumnNumber>9</energy:valueColumnNumber>
	<energy:timeColumnNumber>1</energy:timeColumnNumber>
	<energy:fieldSeparator>\t</energy:fieldSeparator>
</energy:RegularTimeSeriesFile>
gioagu's avatar
gioagu committed
745
```
746

747
## Schedules
748

RomainNouvel's avatar
RomainNouvel committed
749
![Class diagram of ADE Energy Core - Schedules](fig/Schedules.png)
750

Esteban Munoz's avatar
Esteban Munoz committed
751
752
753
754
755
756
757
758
759
The type `_Schedule` is used in the Energy ADE for different kinds of schedules
related to the building usage: heating and cooling schedules (set-point
temperatures), ventilation schedules (mechanical air change rate), occupancy
rate and facilities operation schedules.

Schedules can be modelled in 4 possible "semantic levels of detail", depending
on the available information and the application requirements. These levels of
detail range from a simple constant value to a detailed schedule characterised
by a `_TimeSeries` object.
760

761
### ConstantValueSchedule
762

Esteban Munoz's avatar
Esteban Munoz committed
763
764
The simplest level of detail, this Schedule is defined by a constant measure
(`averageValue`), generally corresponding to the average parameter value.
765
766

```xml
767
768
769
770
<!--Example of a ConstantValueSchedule-->
<energy:ConstantValueSchedule gml:id="id_constant_schedule_1">
	<energy:averageValue uom="degree Celsius">26</energy:averageValue>
</energy:ConstantValueSchedule>
771
772
```

773
### DualValueSchedule
774

Esteban Munoz's avatar
Esteban Munoz committed
775
776
777
778
779
780
A two-state schedule. This schedule is defined by a `usageValue` for usage
times, and an `idleValue` outside these temporal boundaries. Usage times are
characterized by the numbers `usageHoursPerDay` and `usageHoursPerDay` (usage
hours per usage days). This schedule complies in particular with the data
requirements of the codes and norms describing the monthly energy balance (DIN
18599-2, ISO 13790).
781

782
```xml
783
<!--Example of a DualValueSchedule-->
gioagu's avatar
Typo    
gioagu committed
784
<energy:DualValueSchedule gml:id="id_dualvalue_schedule_2">
785
786
787
788
789
	<energy:usageValue uom="degree Celsius">20</energy:usageValue>
	<energy:idleValue uom="degree Celsius">16</energy:idleValue>
	<energy:usageHoursPerDay uom="hour">17</energy:usageHoursPerDay>
	<energy:usageDaysPerYear uom="day">365</energy:usageDaysPerYeary>
</energy:DualValueSchedule>
790
791
```

792
### DailyPatternSchedule
793

Esteban Munoz's avatar
Esteban Munoz committed
794
795
796
This more detailed schedule is composed of daily `schedule` associated to
recurrent `dayType` (e.g. weekday, weekend). These daily schedules are of type`
_TimeSeries`, as described above.
797
798
799

```xml
<!--Example of a daily pattern schedule for a standard week composed of weekday and weekend days-->
800
<energy:DailyPatternSchedule gml:id="id_dailypattern_schedule_3">
801
802
803
804
	<energy:dailySchedule>
		<energy:DailySchedule>
			<energy:dayType>WeekDay</energy:dayType>
			<energy:schedule>
805
				<energy:RegularTimeSeries gml:id="id_occupants_daily_timeseries_1">
806
807
					<energy:temporalExtent>
						<gml:TimePeriod>
808
							<gml:beginPosition>00:00:00</gml:beginPosition>
809
							<gml:endPosition>23:59:59</gml:endPosition>
810
811
812
813
814
815
816
817
818
819
820
821
						</gml:TimePeriod>
					</energy:temporalExtent>
					<energy:timeInterval unit="hour">1</energy:timeInterval>
					<energy:values uom="ratio">0 0 0 0.1 0.2 0.5 ... (truncated, set of 24 values)</energy:values>
				</energy:RegularTimeSeries>
			</energy:schedule>
		</energy:DailySchedule>
	</energy:dailySchedule>
	<energy:dailySchedule>
		<energy:DailySchedule>
			<energy:dayType>WeenEnd</energy:dayType>
			<energy:schedule>
822
				<energy:RegularTimeSeries gml:id="id_occupants_daily_timeseries2">
823
824
					<energy:temporalExtent>
						<gml:TimePeriod>
825
							<gml:beginPosition>00:00:00</gml:beginPosition>
826
							<gml:endPosition>23:59:59</gml:endPosition>
827
828
829
830
831
832
833
834
835
836
837
						</gml:TimePeriod>
					</energy:temporalExtent>
					<energy:timeInterval unit="hour">1</energy:timeInterval>
					<energy:values uom="ratio">0 0 0 0.11 0.22 ... (truncated, set of 24 values)</energy:values>
				</energy:RegularTimeSeries>
			</energy:schedule>
		</energy:DailySchedule>
	</energy:dailySchedule>
</energy:DailyPatternSchedule>
```

838
### TimeSeriesSchedule
839

Esteban Munoz's avatar
Esteban Munoz committed
840
841
This type is the most detailed of all `_schedule` levels of details. It
consists of a unique time series, without patterns.
842

843
844
```xml
<!--Example of a time series based schedule with hourly values for one year-->
845
846
<energy:TimeSeriesSchedule gml:id="id_timeseries_schedule_4">
	<energy:RegularTimeSeries "id_occupants_timeseries4">
847
848
849
850
851
852
853
854
855
856
857
858
			<energy:temporalExtent>
				<gml:TimePeriod>
					<gml:beginPosition>2000-01-01</gml:beginPosition>
					<gml:endPosition>2000-12-31</gml:endPosition>
				</gml:TimePeriod>
			</energy:temporalExtent>
			<energy:timeInterval unit="hour">1</energy:timeInterval>
			<energy:values uom="ratio">1 1 1 1 0.9 0.7 0.5 ... (truncated, set of 8760 values)</energy:values>
	</energy:RegularTimeSeries>
</energy:TimeSeriesSchedule>
```

859
# Construction and Material Module
860

RomainNouvel's avatar
RomainNouvel committed
861
![Class diagram of Construction Module](fig/Construction.png)
862

Esteban Munoz's avatar
Esteban Munoz committed
863
864
865
The Construction and Material module of the ADE Energy characterizes physically
the building construction parts, detailing their structure and specifiying
their thermal and optical properties. 
866

Esteban Munoz's avatar
Esteban Munoz committed
867
868
As its central object `Construction` inherits from class `_CityObject`, all
similar objects, can be described by means of construction and materials.
869

Esteban Munoz's avatar
Esteban Munoz committed
870
871
Given that the nature of this module is not domain-specific, it can be used
beyond energy-related applications (e.g. in statics, acoustics etc.) 
872

Esteban Munoz's avatar
Esteban Munoz committed
873
## Construction
874

Esteban Munoz's avatar
Esteban Munoz committed
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
This is the central object of this module, which holds the physical
characterisation of building envelop or intern room partition (e.g. wall, roof,
openings).
In the Energy ADE, the object `Construction` is generally linked to the object
`ThermalComponents` for space heating and cooling demand calculations, in order
to specified in the building model the physical parameters of walls, roofs of
windows etc. However, it may possibly be linked to any `_CityObject` for other
purposes, in particular to `_BoundarySurface`, `_Opening` or even
`_AbstractBuilding`.

Each `Construction` object may be characterised by optical and/or physical
properties.

The `OpticalProperties` type specified the `emissivity`, `reflectance`,
`transmittance` and `glazingRatio` of the construction and its surfaces:

- *Emissivity* is the ratio of the infrared (also called long-wave) radiation
  emitted by a specific surface/object to that of a black body. It is specified
  for a given surface (`SurfaceSide`). According with the Kirchoff and Lambert
  law, for a diffuse grey body the aborptance and the emittance are equal for a
  given wavelength range.

- *Reflectance* is the fraction of incident radiation which is reflected by an
  object. It is specified for a given surface (`SurfaceSide`) and for a given
  `wavelengthRange` type ("Visible", "Infrared", "Solar" or "Total" spectrums).

- *Transmittance* is the fraction of incident radiation which passes through a
  specific object. It is specified for a given `wavelengthRange` type . For
  example, the total transmittance of a window correspond to its *g-value*
  (also called Solar Heat Gain Coefficient). The transmittance value is
  included between 0 (completely opaque object) and 1 (completely transparent
  object).

- the `glazingRatio` corresponds of to proportion of the construction surface
  which is transparent and for which the transmittance is defined. For the
  modelling of window, `glazingRatio` corresponds to the proportion of window
  surface not cover by the window frame.

The thermal properties of the Construction may be characterized with two
possible "levels of details" : either with the heat transmission coefficient
`uValue` for steady-state thermal modelling, or by detailing its different
`Layer` of materials and their thermal behaviour.

In this last case, the `Construction` may be defined as an ordered combination
of `Layer`, containing possibly several `LayerComponent` made of materials.

In the following, several examples of Construction objects are presented, with
different levels of complexity.
gioagu's avatar
gioagu committed
923

924
A simple wall characterised with its U-value :
gioagu's avatar
gioagu committed
925
926

```xml
927
928
929
930
931
<!--Example of a wall construction simply characterised with a U-value-->
<energy:Construction gml:id="id_construction_1">
	<gml:description>Description of Construction 1</gml:description>
	<gml:name>Name of Construction 1</gml:name>
	<energy:uValue uom="W/(K*m^2)">1.2</energy:uValue>
gioagu's avatar
gioagu committed
932
933
934
</energy:Construction>
```

Esteban Munoz's avatar
Esteban Munoz committed
935
936
937
A window characterised with its U-value, its emissivity, its g-value and its
visible transmittance.

gioagu's avatar
gioagu committed
938
```xml
939
<!--Example of low-emissivity window Construction object-->
gioagu's avatar
gioagu committed
940
941
942
943
944
945
<energy:Construction gml:id="id_construction_2">
	<gml:description>Description of the windows Construction</gml:description>
	<gml:name>Name of the window Construction</gml:name>
	<energy:uValue uom="W/(K*m^2)">1.9</energy:uValue>
	<energy:opticalProperties>
		<energy:OpticalProperties>
946
947
			<energy:emittance>
				<energy:Emissivity>
948
949
					<energy:fraction uom="ratio">0.04</energy:fraction>
					<energy:surface>Inside</energy:surface>
950
951
				</energy:Emissivity>
			</energy:emittance>
952
			<!-- Here follows the g-value (or SHGC) characterization-->
gioagu's avatar
gioagu committed
953
954
			<energy:transmittance>
				<energy:Transmittance>
955
956
957
958
959
960
961
962
963
					<energy:fraction uom="ratio">0.65</energy:fraction>
					<energy:wavelengthRange>Total</energy:wavelengthRange>
				</energy:Transmittance>
			</energy:transmittance>
			<!-- Here follows the visible transmittance characterization-->
			<energy:transmittance>
				<energy:Transmittance>
					<energy:fraction uom="ratio">0.55</energy:fraction>
					<energy:wavelengthRange>Visible</energy:wavelengthRange>
gioagu's avatar
gioagu committed
964
965
				</energy:Transmittance>
			</energy:transmittance>
966
			<energy:glazingRatio uom="ratio">0.8</energy:glazingRatio>
gioagu's avatar
gioagu committed
967
968
969
970
		</energy:OpticalProperties>
	</energy:opticalProperties>
</energy:Construction>
```
971

972
### ConstructionOrientation
973

Esteban Munoz's avatar
Esteban Munoz committed
974
975
976
977
978
This class defines the orientation convention of the `Construction` object it
is referred to. In other words, it indicates in which order the layers are to
be considered (from inside to outside, or viceversa), because the same
construction, if common to different zones or buildings, might be orientated in
two different directions for instance.
979

gioagu's avatar
gioagu committed
980
981
982
983
984
985
986
987
988
```xml
<!--Example of ConstructionOrientation object-->
<energy:ConstructionOrientation gml:id="id_construction_orientation_ground_1">
	<gml:description>Description of Construction Orientation 1 (from inside to outside)</gml:description>
	<gml:name>Name of Construction Orientation 1</gml:name>
	<energy:orientation>true</energy:orientation>
	<energy:baseConstruction xlink:href="#id_construction_1"/>
</energy:ConstructionOrientation>
```
989

RomainNouvel's avatar
RomainNouvel committed
990
## Layers and layer components
991

Esteban Munoz's avatar
Esteban Munoz committed
992
993
994
995
A `Construction` may be defined as an ordered combination of layers, themselves
composed of one or more `LayerComponent`.
A `LayerComponent` is a homogeneous part of a `Layer` (composed of a unique
material) covering a given fraction (`areaFraction`) of it.
996

Esteban Munoz's avatar
Esteban Munoz committed
997
998
The materials of each `LayerComponent` may be specified either inline or by
means of xlinks (more adapted to materials  reused in different constructions).
999

Esteban Munoz's avatar
Esteban Munoz committed
1000
The XML example below characterizes a insulated outer wall construction with