citygml-energy issueshttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues2016-01-14T13:51:32+01:00https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/63Space-separated values in regular time series2016-01-14T13:51:32+01:00Moritz Robert LausterSpace-separated values in regular time series*Created by: RomainNouvel*
Make possible to store time series under the form of space separated values inside the same tag.
Proposition of Jerome, agreed by Joachim and Thomas.
*Created by: RomainNouvel*
Make possible to store time series under the form of space separated values inside the same tag.
Proposition of Jerome, agreed by Joachim and Thomas.
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/60ThermalBoundarySurface Types2016-01-14T13:51:55+01:00Moritz Robert LausterThermalBoundarySurface Types*Created by: RomainNouvel*
The first goal of ThermalBoundarySurfaceType was to identify specific Thermal boundary surface typologies which are likely to have similar Constructions in a building (and possibly relate them with a construct...*Created by: RomainNouvel*
The first goal of ThermalBoundarySurfaceType was to identify specific Thermal boundary surface typologies which are likely to have similar Constructions in a building (and possibly relate them with a construction library). Indeed, the unique use of BoundarySurfaceType for this purpose is not enough (is floor surface directly in contact to the ground, or the ceiling of the basement floor?). Moreover, for Buildings LOD4, 2 BoundarySurfaces of different rooms (FloorSurface or Room 1 and CeilingSurface of Room2) may corresponds to a unique ThermalBoundarySurface (IntermediaryFloor).
Presently in the Energy ADE v0.5, the ThermalBoundarySurfaceType Codelist is uncomplete and not fully clear.
For the Building LOD4, we should introduced:
- **InteriorWall**. Definition: Vertical partition separating two ThermalZones of a same building.
- **IntermediaryFloor**. Definition: Horizontal partition separating two ThermalZones of a same building.
Further proposed specifications of existing ThermalBoundarySurfaceType:
- **SharedWall**. Definition: Vertical partition separating two different buildings.
- **OuterWall** (or Outwall). Definition: Vertical thermal boundary surface with one side facing outdoor.
- **BasementFloor**. Definition: Lower horizontal thermal boundary surface of the ThermalZone, built direct on the ground.
- **BasementCeiling** (instead of cellarCeiling). Definition: Horizontal partition separating the basement floor and the ground floor.
- **AtticFloor** (instead of TopCeiling which can also be a FlatRoof). Definition: Horizontal partition separating the attic and the highest full storey.
Concerning the roof, flat roofs and pitched roofs obviously don't have the same constructions (as well as copular). However, should we distinguish them in the ThermalBoundarySurfaceType? or should we only right Roof, and the constructions could be deduced from the roof type for instance?
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/57Contruction and material names2016-01-14T13:52:09+01:00Moritz Robert LausterContruction and material names*Created by: RomainNouvel*
Presently, for the identification and management of the Construction objects, no name / description exist.
- it would be useful to add an attribute name[CharacterString].
for instance: "28cm brick wall".
Co...*Created by: RomainNouvel*
Presently, for the identification and management of the Construction objects, no name / description exist.
- it would be useful to add an attribute name[CharacterString].
for instance: "28cm brick wall".
Concerning the Material, What contains precisely the attribute referenceURI? Can we get the material name through it? or it is just an reference id?
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/55ThermalZone Volume2016-01-14T13:52:29+01:00Moritz Robert LausterThermalZone Volume*Created by: RomainNouvel*
In the ADE Energy v0.5, the ThermalZone does not include a parameter volume.
In the case that a Building includes several ThermalZone (or if the ThermalZone does not correspond exactly to the 3D building geom...*Created by: RomainNouvel*
In the ADE Energy v0.5, the ThermalZone does not include a parameter volume.
In the case that a Building includes several ThermalZone (or if the ThermalZone does not correspond exactly to the 3D building geometry), information about the Abstract building volume and the ThermalZone floor area are not sufficient to calculate the space heating of the ThermalZone.
Therefore, a parameter volume is required for the ThermalZone.
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/52More solar-related attributes for SurfaceComponent?2016-01-14T13:52:50+01:00Moritz Robert LausterMore solar-related attributes for SurfaceComponent?*Created by: gioagu*
Hi!
As of now, there is only a boolean isSunExposed attribute to the SurfaceComponent class.
I think it would be useful to be able to store (for example):
direct_solar_irradiance: _Timeseries
diffuse_solar_irradi...*Created by: gioagu*
Hi!
As of now, there is only a boolean isSunExposed attribute to the SurfaceComponent class.
I think it would be useful to be able to store (for example):
direct_solar_irradiance: _Timeseries
diffuse_solar_irradiance: _Timeseries
global_solar_irradiance: _Timeseries
insolation_time:_Timeseries (e.g. sun hours per day, per month, per year, etc.)
shadowing_ratio: _Timeseries (for example due to adjacent buildings)
This could for example speed up simulations where these parameters are computed only once and then simply reused whenever necessary.
What do you think?
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/50Structure of adjacentTo:2016-01-14T13:53:06+01:00Moritz Robert LausterStructure of adjacentTo:*Created by: Maryamzk*
Hi everybody,
I have a doubt about structure of "adjacentTo" association, which I think is needed to be discussed here.
The recent structure of adjacent association is not able to identify the thermal characteri...*Created by: Maryamzk*
Hi everybody,
I have a doubt about structure of "adjacentTo" association, which I think is needed to be discussed here.
The recent structure of adjacent association is not able to identify the thermal characteristics of the adjacent surface but the whole adjacent zone. Therefore, if some thermal parameter of the adjacent surface should be specified, the defined adjacent association should be modified. Below you can find some examples about the parameter of adjacent zone in ISO 13790 and DIN 15899 which are required for heating demand of the thermal zone. I have explained where re-structuring of the adjacent association might be required, but the energy-expert persons can approve it.
In ISO 13790:
- Time-averaged heat flux from all solar sources in the unconditioned adjacent zone. This heat flux in unconditioned is calculated like heat flux in thermal zone for all surfaces (see equations bellow), therefore the adjacent surface should not necessarily be identified. In other words, according to the current definition of ThermalZone class and adjacentTo association, when solar sources of thermal zone are identified, the solar sources for unconditioned adjacent zone are also identified. The only missing point is to recognize an adjacent zone is conditioned or not, right?
Solar heat gain:
![image](https://cloud.githubusercontent.com/assets/12936292/10601511/9994580e-7712-11e5-9aef-77d65cf02dfa.png)
![image](https://cloud.githubusercontent.com/assets/12936292/10601520/ac4e70ce-7712-11e5-9fef-489504c031f7.png)
the time-average heat flow rate from solar heat source l in the adjacent unconditioned space,
,in W
,and
![image](https://cloud.githubusercontent.com/assets/12936292/10601542/b881aee2-7712-11e5-85c8-29de124f2c1f.png)
In DIN 15899:
-Solar radiation passing through the sunspace into the adjacent building. For calculating this we need to know the area of the adjacent surface (see the equations bellow), we need re-structuring in adjacent (DIN 18599-section 6.4)
heat flow into the unheated or uncooled sunspace:
![image](https://cloud.githubusercontent.com/assets/12936292/10601827/9a60a894-7714-11e5-8c5b-d070e137b594.png)
![image](https://cloud.githubusercontent.com/assets/12936292/10601831/a0373dbe-7714-11e5-88eb-8d9e7cd406de.png)
is the total solar radiation passing through the sunspace into the adjacent building zone, calculated using equation (below) for all transparent elements of the partition separating the building zone considered and the unheated sunspace;
![image](https://cloud.githubusercontent.com/assets/12936292/10601834/a5cd9584-7714-11e5-8169-23112a1d843d.png)
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/49EnergySupply, Energy carrier, Energy source2016-01-14T13:53:20+01:00Moritz Robert LausterEnergySupply, Energy carrier, Energy source*Created by: RomainNouvel*
1- In our EnergyADE version 0.5, the feature "EnergySource" can be a Primary our Secondary Energy Source, renewable or not. It is therefore not systematically an energy carrier ("energy form which has been tra...*Created by: RomainNouvel*
1- In our EnergyADE version 0.5, the feature "EnergySource" can be a Primary our Secondary Energy Source, renewable or not. It is therefore not systematically an energy carrier ("energy form which has been transformed from primary energy sources, such as electricity"), like in the case of Solar Energy.
Beside, some energy carrier (hot water, chilled air etc.) related to EnergySupply does not have related CO2 emission factor, primary energy factor etc...
We should therefore rethink our EnergySupply, EnergySource and EnergyCarrier structures, contents and wordings...
2- Other issue: how do we model the (PV) electrical production feeding the grid? Should we only add an EndUseType "GridFeedIn"?
https://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/46Energy Performance Certification2016-01-14T13:53:42+01:00Moritz Robert LausterEnergy Performance Certification*Created by: RomainNouvel*
Different labels (e.g. LEED, KfW Effizienzhaus) and degrees (e.g. of Platine, KfW 100) of energy performance certification exist in the world.
PROPOSITION:
a hierarchical CodeList should be defined to manage t...*Created by: RomainNouvel*
Different labels (e.g. LEED, KfW Effizienzhaus) and degrees (e.g. of Platine, KfW 100) of energy performance certification exist in the world.
PROPOSITION:
a hierarchical CodeList should be defined to manage the different energy performance certifications
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/45Landmarked / Historical Buildings2016-01-14T13:54:24+01:00Moritz Robert LausterLandmarked / Historical Buildings*Created by: RomainNouvel*
Different status of landmarked/historical buildings exist in Europe with different degrees of protection.
Therefore, a simple landmarked[Boolean] as attribute of _AbstractBuilding should be not enough.
PROPOSI...*Created by: RomainNouvel*
Different status of landmarked/historical buildings exist in Europe with different degrees of protection.
Therefore, a simple landmarked[Boolean] as attribute of _AbstractBuilding should be not enough.
PROPOSITION:
- Use the Hierarchical/multi-lingual CodeList Re3gistry as developed by JRC to manage the different certification labels and degrees.
- Rename this attribute (culturalHeritageStatus?)
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/39g-value and conductivity for Windows2016-01-14T13:54:56+01:00Moritz Robert Lausterg-value and conductivity for Windows*Created by: PRemmen*
A widley used property for the calculation of transmitted solar gains through a window is the g-value. Right now it seems that it is missing in the schema, correct me if I'm wrong.
The g-value is comparable to the...*Created by: PRemmen*
A widley used property for the calculation of transmitted solar gains through a window is the g-value. Right now it seems that it is missing in the schema, correct me if I'm wrong.
The g-value is comparable to the uValue, since it is typically calculated for the whole window and not single panes.
Considering that, I would suggest to implement the gValue in _Opening, but I'm not a expert in UML Design.
Also it seems that thermal properties like conductivity, density etc. can't be set for glazing, again: correct me if I'm wrong :)
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/38Optical Properties2016-01-14T13:55:11+01:00Moritz Robert LausterOptical Properties*Created by: RomainNouvel*
Optical properties (reflectance, transmittance, emittance, absorptance etc...) are presently spread off in different objects of the Material Module (Construction and Glazing), with different level of details (...*Created by: RomainNouvel*
Optical properties (reflectance, transmittance, emittance, absorptance etc...) are presently spread off in different objects of the Material Module (Construction and Glazing), with different level of details (distinction hemispherical/normalIncidence in Glazing).
For more readibility and flexibility, it would be interesting to pick out all optical properties and gather them in a single object "OpticalProperties", possibly assigned to Construction or LayerComponent.
In this case, the specification of a "GlazingObject", hybrid object between a layer and material, would not be required anymore. Instead, we could only distinguish Materials between Gas and SolidMaterial. The transparence characteristic would come only from the OpticalProperties...
https://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/36Update README.md2016-01-14T13:55:34+01:00Moritz Robert LausterUpdate README.md*Created by: oliviertournaire*
Update REAME.md:
- Add a section "How to contribute?"
- Add some links to the main SIG3D webpage
- Add links to workshops meetings
- Add an "Announcement" section
*Created by: oliviertournaire*
Update REAME.md:
- Add a section "How to contribute?"
- Add some links to the main SIG3D webpage
- Add links to workshops meetings
- Add an "Announcement" section
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/31Lighting in Building2016-01-14T13:55:43+01:00Moritz Robert LausterLighting in Building*Created by: RomainNouvel*
Up to now, the building model do not integrate specific attributes for lighting.
- Luminance Threshold (Lux) could be included in UsageZone for instance...
- LightingFacilities/Systems could be specificied suc...*Created by: RomainNouvel*
Up to now, the building model do not integrate specific attributes for lighting.
- Luminance Threshold (Lux) could be included in UsageZone for instance...
- LightingFacilities/Systems could be specificied such as DHWFacilities...
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/28Verbose definition of energy:values in RegularTimeSeries type2016-01-14T13:55:55+01:00Moritz Robert LausterVerbose definition of energy:values in RegularTimeSeries type*Created by: 900k*
While writing an updated sample file for v0.5 I find it superfluous to have an opening and closing tag for each value of a time series. For 12 monthly values you will end up with this ...
```
<energy:values>
66.5...*Created by: 900k*
While writing an updated sample file for v0.5 I find it superfluous to have an opening and closing tag for each value of a time series. For 12 monthly values you will end up with this ...
```
<energy:values>
66.5
</energy:values>
<energy:values>
66.5
</energy:values>
<energy:values>
39.9
</energy:values>
...
<energy:values>
66.5
</energy:values>
```
I suggest to define the values element in such a way so that instances of it look like this ...
```
<energy:values>
66.5 66.5 39.9 26.6 26.6 13.3 13.3 26.6 26.6 39.9 66.5 66.5
</energy:values>
```
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/26Update TwoSimpleBuildings.xml sample2016-01-14T14:05:15+01:00Moritz Robert LausterUpdate TwoSimpleBuildings.xml sample*Created by: oliviertournaire*
The sample currently validates against the XSD schema. However, it is not complete. To have a better sample, it should:
- use all classes defined in the ADE
- use all relations defined in the ADE
- use all...*Created by: oliviertournaire*
The sample currently validates against the XSD schema. However, it is not complete. To have a better sample, it should:
- use all classes defined in the ADE
- use all relations defined in the ADE
- use all possible variants for relations (_i.e._ `inline` or `byReference`)
The sample should also be commented to be easily understandable.
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/25Version value2016-01-14T14:05:27+01:00Moritz Robert LausterVersion value*Created by: oliviertournaire*
I am just wondering which version to use in the namespace and codelists: the version of the ADE (`x.y.z`), or the CityGML version to which the ADE complies (i.e `2.0`)
*Created by: oliviertournaire*
I am just wondering which version to use in the namespace and codelists: the version of the ADE (`x.y.z`), or the CityGML version to which the ADE complies (i.e `2.0`)
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/15Split diagram2016-01-14T14:05:39+01:00Moritz Robert LausterSplit diagram*Created by: oliviertournaire*
The diagram is pretty big and thus should be divided in several parts:
- Occupancy
- Material
- Energy systems
- Core
- ...
*Created by: oliviertournaire*
The diagram is pretty big and thus should be divided in several parts:
- Occupancy
- Material
- Energy systems
- Core
- ...
v0.6.0