citygml-energy issueshttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues2018-12-06T10:43:38+01:00https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/1213DCityDB Extension for Energy-ADE2018-12-06T10:43:38+01:00Moritz Robert Lauster3DCityDB Extension for Energy-ADE*Created by: yaozhihang*
Dear Energy-Team,
this Github-repository (see the link below) might be useful for some of you who have an interest in using the open source software 3DCityDB for managing CityGML-Energy-ADE data. I would be gla...*Created by: yaozhihang*
Dear Energy-Team,
this Github-repository (see the link below) might be useful for some of you who have an interest in using the open source software 3DCityDB for managing CityGML-Energy-ADE data. I would be glad about any feedbacks from you for improving my work.
https://github.com/yaozhihang/3DCityDB-Extensions-for-CityGML-ADEs
Kind regards,
Zhihang
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/74About attribute "atticType" in building2016-07-01T10:19:39+02:00Moritz Robert LausterAbout attribute "atticType" in building*Created by: gioagu*
Some comments for the next 0.7 version collected so far.
Giorgio: The attribute atticType (and the similar ones) could be renamed “atticConditioning”, as we describe just one property of the attic, not really the “...*Created by: gioagu*
Some comments for the next 0.7 version collected so far.
Giorgio: The attribute atticType (and the similar ones) could be renamed “atticConditioning”, as we describe just one property of the attic, not really the “type”. But it is just a just thought
Romain: Should be discussed. We should look for the official name in the ISO 13790 and similar norms… -> Issue for Energy ADE 0.7?
Joachim: Should be a topic for Energy ADE version 0.7
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/104About cardinality of ThermalComponents2016-06-29T20:35:22+02:00Moritz Robert LausterAbout cardinality of ThermalComponents*Created by: gioagu*
So far, each ThermalBounday MUST have at least one ThermalComponents.
If I use a single ThermalComponent, I can define the area and - e.g. by Construction - how it is made.
If I use two ThermalComponents, I may defi...*Created by: gioagu*
So far, each ThermalBounday MUST have at least one ThermalComponents.
If I use a single ThermalComponent, I can define the area and - e.g. by Construction - how it is made.
If I use two ThermalComponents, I may define how many m^2 are wall and how many are glazing.
However, if I do not have this information, but just the ThermalBoundary, I still need to generate at least one ThermalComponent for each ThermalBoudary. This makes sense if I am using the data as input for simulation software, but (sometimes) not if I simply want to transfer data.
Imagine I have a city with 1000000 ThermalBoundaries and no other information. My XML file needs 1000000 ThermalComponents to be valid. But do I really need them?
I will generate the ThermalComponents depending on the type of library I am using (e.g. from where I get the window_to_wall ratio and the construction) in order to feed the simulation tool, but do I really need to store this information in advance?
Maybe the cardinality from ThermalBoundary to ThermalComponent could be relaxed to 0..n.
If so, I would also add an area attribute also to the ThermalBoudary object.
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/1Add a license file2015-02-18T23:20:08+01:00Moritz Robert LausterAdd a license file*Created by: oliviertournaire*
Is it necessary? CityGML does not provide any license file
*Created by: oliviertournaire*
Is it necessary? CityGML does not provide any license file
v0.4.3https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/37Add a ThermalWindow type for LoD{0,1,2}2016-01-14T13:55:19+01:00Moritz Robert LausterAdd a ThermalWindow type for LoD{0,1,2}*Created by: oliviertournaire*
In CityGML standard, the class _Opening can only be used starting from LoD3. The Energy ADE extends this class with some attributes. As energy simulation requires to have building windows, it is necessary ...*Created by: oliviertournaire*
In CityGML standard, the class _Opening can only be used starting from LoD3. The Energy ADE extends this class with some attributes. As energy simulation requires to have building windows, it is necessary to create a new type. How to do this should now be discussed.
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/76Add attribute "EnergyPerformanceCertification" also in class BuildingUnit2016-07-01T10:00:49+02:00Moritz Robert LausterAdd attribute "EnergyPerformanceCertification" also in class BuildingUnit*Created by: gioagu*
Some comments/thought collected so far for release 0.7
Giorgio: The attribute “EnergyPerformanceCertification” should be added to the “Building_Unit” class as well. You can have EPC for the whole building, or for j...*Created by: gioagu*
Some comments/thought collected so far for release 0.7
Giorgio: The attribute “EnergyPerformanceCertification” should be added to the “Building_Unit” class as well. You can have EPC for the whole building, or for just a single unit. I remember we talked briefly about this in Munich, but somehow it got lost (I forgot it too…).
Romain: That’s right. -> Issue for Energy ADE 0.7?
Joachim: Should be a topic for Energy ADE version 0.7
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/6Add 'constructionOrientation' name to association between '<<ADEElement>> _Ci...2015-02-02T12:04:00+01:00Moritz Robert LausterAdd 'constructionOrientation' name to association between '<<ADEElement>> _CityObject' and 'ConstructionOrientation'*Created by: oliviertournaire*
From Marcel Bruse:
"I'm not able to create a construction or constructionOrientation underneath a roof surface (I suppose it doesn't work for any BoundarySurface). Please check if it works for buildings an...*Created by: oliviertournaire*
From Marcel Bruse:
"I'm not able to create a construction or constructionOrientation underneath a roof surface (I suppose it doesn't work for any BoundarySurface). Please check if it works for buildings and buildings parts, too."
v0.4.3https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/96Additional attribute status in EnergyDemand2018-12-06T10:43:38+01:00Moritz Robert LausterAdditional attribute status in EnergyDemand*Created by: JoachimBenner*
The featureType _EnergyDemand_ can be used either to provide input data for energy demand simulations or to represent the output data of these simulations. At the moment, _EnergyDemand_ has no property to ind...*Created by: JoachimBenner*
The featureType _EnergyDemand_ can be used either to provide input data for energy demand simulations or to represent the output data of these simulations. At the moment, _EnergyDemand_ has no property to indicate whether the property _energyAmount_ carries input data or simulation results.
**Proposal**
1. Introduce a new (mandatory?) property **status** of _EnergyDemand_ with property values defined by an enumeration
2. Introduce a new enumeration **EnergyDamandStatusValue** with items: **Simulated**, **Measured**, **Estimated**, **Unknown** (must be discussed)
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/65add Mandatory Units of Measure2019-10-08T08:32:29+02:00Moritz Robert Lausteradd Mandatory Units of Measure*Created by: RomainNouvel*
List of units of measure should be mandatory (for instance: m2 and not m² nor sqm).
Check if we can use standard list of units / uri. How do we deal with it in GML
*Created by: RomainNouvel*
List of units of measure should be mandatory (for instance: m2 and not m² nor sqm).
Check if we can use standard list of units / uri. How do we deal with it in GML
backloghttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/64Add optional geometrical attributes to ThermalZone, UsageZone, ThermalBoundary2016-01-14T13:51:17+01:00Moritz Robert LausterAdd optional geometrical attributes to ThermalZone, UsageZone, ThermalBoundary*Created by: RomainNouvel*
Introduction of optional geometrical attributes to:
- ThermalZone: volumeGeometry, type: gml:Solid, [0..1]
- UsageZone: volumeGeometry, type: gml:Solid, [0..1]
- ThermalBoundary: surfaceGeometry, type: gml:Mul...*Created by: RomainNouvel*
Introduction of optional geometrical attributes to:
- ThermalZone: volumeGeometry, type: gml:Solid, [0..1]
- UsageZone: volumeGeometry, type: gml:Solid, [0..1]
- ThermalBoundary: surfaceGeometry, type: gml:Multi-Surface, [0..1]
Agreed in Workshop Munich by Thomas, Georgio, Alexandru, Silvia, Jerome, KH
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/66Add RegularTimeSeriesFile and IrregularTimeSeriesFile Class which inherits fr...2016-01-14T13:50:58+01:00Moritz Robert LausterAdd RegularTimeSeriesFile and IrregularTimeSeriesFile Class which inherits from TimeSeries*Created by: RomainNouvel*
RegularTimeSeriesFile
-> Attributes:
- uom: UnitOfMeasure [1]
- File. type: uri [1]
- timeIntervale: TM_IntervalLength [1]
- numberOfHeaderLines [0..1](default value: 0)
- fieldSeparator [1](default value: [...*Created by: RomainNouvel*
RegularTimeSeriesFile
-> Attributes:
- uom: UnitOfMeasure [1]
- File. type: uri [1]
- timeIntervale: TM_IntervalLength [1]
- numberOfHeaderLines [0..1](default value: 0)
- fieldSeparator [1](default value: [space])
- recordSeparator [1](default value: [new line])
- regionalCode [codeList](default value: en)
- valueFieldNumber[0..1] : field number from which the value dataset must be extracted (default value: 1)
IrregularTimeSeriesFile
-> Attributes:
- uom: UnitOfMeasure [1]
- File. type: uri [1]
- numberOfHeaderLines [0..1](default value: 0)
- fieldSeparator [1](default value: [space])
- recordSeparator [1](default value: [new line])
- regionalCode [codeList](default value: en)
- valueFieldNumber[0..1] : field number from which the value dataset must be extracted (default value: 1)
- timeFieldNumber[0..1] : field number from which the time dataset must be extracted (default value: 1)
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/11ADEElement _BoundarySurface2015-03-02T22:28:19+01:00Moritz Robert LausterADEElement _BoundarySurface*Created by: oliviertournaire*
In the current model, an abstract class `_BoudarySurface` with the stereotype `ADEElement` exists. It derives from `Building:AbstractBoundarySurface`.
Some clarification are required:
1. If we want to cre...*Created by: oliviertournaire*
In the current model, an abstract class `_BoudarySurface` with the stereotype `ADEElement` exists. It derives from `Building:AbstractBoundarySurface`.
Some clarification are required:
1. If we want to create a class (i.e. a type) in the ADE which derives from `Building:AbstractBoundarySurface`, it should be done in another way (see image below)
2. The name of the derived class, if it has the stereotype `ADEElement` must have the **same name as its base class** (i.e. `AbstractBoundarySurface`)
![ade1](https://cloud.githubusercontent.com/assets/1990302/6414473/01d57a3a-be98-11e4-9823-8c4382c6d9b0.png)
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/12ADEElement _Opening2015-03-02T22:27:59+01:00Moritz Robert LausterADEElement _Opening*Created by: oliviertournaire*
In the current model, an abstract class `_Opening` with the stereotype `ADEElement` exists. It derives from `Building:AbstractOpening`.
Some clarification are required:
1. If we want to create a class (i....*Created by: oliviertournaire*
In the current model, an abstract class `_Opening` with the stereotype `ADEElement` exists. It derives from `Building:AbstractOpening`.
Some clarification are required:
1. If we want to create a class (i.e. a type) in the ADE which derives from `Building:AbstractOpening`, it should be done in another way (see image below)
2. The name of the derived class, if it has the stereotype `ADEElement` must have the **same name as its base class** (i.e. `AbstractOpening`)
![ade1](https://cloud.githubusercontent.com/assets/1990302/6414473/01d57a3a-be98-11e4-9823-8c4382c6d9b0.png)
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/101attribute Emissivity instead of Emittance2016-06-29T21:12:16+02:00Moritz Robert Lausterattribute Emissivity instead of Emittance*Created by: RomainNouvel*
For the last Energy ADE 0.6 release, we agreed to rename the attribute Emittance -> Emissivity. However, only the type has been changed, not the attribute name.
This should be correct in the new release.
*Created by: RomainNouvel*
For the last Energy ADE 0.6 release, we agreed to rename the attribute Emittance -> Emissivity. However, only the type has been changed, not the attribute name.
This should be correct in the new release.
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/139Automatic schema validation on Github2017-12-11T09:46:26+01:00Moritz Robert LausterAutomatic schema validation on Github*Created by: pascal-schetelat*
I've merged the automatic validation process into the master and realease branche v0.8 and v0.9.0
## What it does:
If any of you add a sample file in the v0.8 release branch, github will automaticall...*Created by: pascal-schetelat*
I've merged the automatic validation process into the master and realease branche v0.8 and v0.9.0
## What it does:
If any of you add a sample file in the v0.8 release branch, github will automatically test wether this sample file validate against the most recent version of the v0.8 energy.xsd
## How it does it :
- For every commit done on the master or release branches (since v0.8), github launches a test procedure with travi-ci
- The test try to validate all the *.gml files that it founds in citygml-energy/samples/ against the energy.xsd schema
- If any file fails to validate, the test will be reported as failing
- If all the files validate, the test will be reported as passing
- It will update the build status badge displayed in the main page of the repository. If you switch to a specific branch on the main page, the badge will actually reflect the status of that branch.
Here are the current status of the different branches :
- master : [![Build Status](https://travis-ci.org/cstb/citygml-energy.svg?branch=master)](https://travis-ci.org/cstb/citygml-energy)
- v0.8 : [![Build Status](https://travis-ci.org/cstb/citygml-energy.svg?branch=v0.8)](https://travis-ci.org/cstb/citygml-energy)
- v0.9.0 : [![Build Status](https://travis-ci.org/cstb/citygml-energy.svg?branch=v0.9.0)](https://travis-ci.org/cstb/citygml-energy)
As of today (17/05/2017, v0.9.0 is just a copy of v0.8)
To see which files fail to validate, click on the badge, click on the branches tab and select the build at fault. Skip to the bottom of the test log and look at **"KO"**
For instance, as of today, there is an issue the a sample file in the master :
```python
../samples/Rotterdam_Bospolder_bldgAttr.gml
KO
/home/travis/build/cstb/citygml-energy/samples/Rotterdam_Bospolder_bldgAttr.gml:2:0:ERROR:SCHEMASV:SCHEMAV_CVC_ELT_1: Element '{http://www.opengis.net/citygml/1.0}CityModel': No matching global declaration available for the validation root.
```
Meaning this sample file does not validate because it is compliant with citygml 1.0
# what next ?
That kind of procedure could be extended to test any kind of tools that rely on the ADE, for instance if the 3DCityDB Extension for Energy-ADEdatabase is working as expected.
Let me know if any of you have any remarks/ questions regarding this new feature and if you wish to extend it, I'll briefly talk about it next week on the workshop
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/43averageCeilingHeight2016-01-14T13:54:39+01:00Moritz Robert LausteraverageCeilingHeight*Created by: RomainNouvel*
The attribute "averageStoreyHeight" of _AbstractBuilding in the Energy ADE version 0.5 is partly redundant with the attribute storeysHeightAboveGround[0..*] of CityGML, and seems not very useful.
PROPOSITION:
...*Created by: RomainNouvel*
The attribute "averageStoreyHeight" of _AbstractBuilding in the Energy ADE version 0.5 is partly redundant with the attribute storeysHeightAboveGround[0..*] of CityGML, and seems not very useful.
PROPOSITION:
It could be renamed in "averageCeilingHeight" which is a parameter used in many Heating Demand calculation norms for instance (the difference between both is the thickness of the ceiling)
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/146Bug Fix: Derive Facilities from _CityObject2019-05-14T10:47:06+02:00Moritz Robert LausterBug Fix: Derive Facilities from _CityObject*Created by: JoachimBenner*
One of the change requests for version 0.9.0 was to derive the FeatureType _Facilites_ from __CityObject_. This was forgotten and should now be performed in the next version.*Created by: JoachimBenner*
One of the change requests for version 0.9.0 was to derive the FeatureType _Facilites_ from __CityObject_. This was forgotten and should now be performed in the next version.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/147Bug Fix: Rename relations staticConstruction and openingConstruction2019-05-14T10:48:01+02:00Moritz Robert LausterBug Fix: Rename relations staticConstruction and openingConstruction*Created by: JoachimBenner*
One of the change requests for version 0.9.0 was to rename the relations _staticConstruction_ (_ThermalBoundary_ --> _AbstractConstruction_) and _openingConstruction_ (_ThermalOpening_ --> _AbstractConstructi...*Created by: JoachimBenner*
One of the change requests for version 0.9.0 was to rename the relations _staticConstruction_ (_ThermalBoundary_ --> _AbstractConstruction_) and _openingConstruction_ (_ThermalOpening_ --> _AbstractConstruction_) to **_construction_**. This was forgotten and should be performed in the next versionhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/47Building Floor Areas2016-01-14T13:53:32+01:00Moritz Robert LausterBuilding Floor Areas*Created by: RomainNouvel*
Many different floor area definitions exist, depending on the application (e.g. heating, living, working), the country. In US, you have for instance the choice between gross floor area, gross internal area, ne...*Created by: RomainNouvel*
Many different floor area definitions exist, depending on the application (e.g. heating, living, working), the country. In US, you have for instance the choice between gross floor area, gross internal area, net internal area, usable floor area... with sizeable difference of results when you're using consumption ratio and criterias refering to them.
In the version 0.5, different Floor areas are used in _AbstractBuilding (referenceHeatedFloorArea) and in ThermalZone (heatedFloorArea, cooledFloorArea). This is quite incomplete and confusing...
PROPOSITION:
- replace referenceHeatedFloorArea by a type FloorArea precising the area and the area definition (CodeList?), which could be associated to _AbstractBuilding, _ThermalZone, _UsageZone etc.
- replace heatedFloorArea and cooledFloorArea of ThermalZone by this new type FloorArea and the parameters isHeated[Boolean] and isCooled[Boolean]
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/44building Physics Description / construction type2016-07-05T23:05:11+02:00Moritz Robert Lausterbuilding Physics Description / construction type*Created by: RomainNouvel*
Some information about the building contruction type could be useful, for instance to assess the materials of a buildings (information about building type and year of construction is sometimes not enough).
A...*Created by: RomainNouvel*
Some information about the building contruction type could be useful, for instance to assess the materials of a buildings (information about building type and year of construction is sometimes not enough).
A attribute called "buildingPhysicsDescription" or "constructionType" (the "constructionStyle" of the version 0.5 doesn't look like a reference name) should be precisely defined and maybe set as a hierarchical CodeList.
(Some information about building construction type: http://www.wikihow.com/Determine-a-Building%27s-Construction-Type)
v0.7.0