citygml-energy issueshttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues2016-07-01T10:21:30+02:00https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/23Expand BuildingType Codelist2016-07-01T10:21:30+02:00Moritz Robert LausterExpand BuildingType Codelist*Created by: oliviertournaire*
[Reported by Piergiorgio Cipriano]
In general, an alignment with INSPIRE codelists is suggested.
BuildingType: at the moment the codelist (BuildingType.xml) is only containing 3 possible values:
- Singl...*Created by: oliviertournaire*
[Reported by Piergiorgio Cipriano]
In general, an alignment with INSPIRE codelists is suggested.
BuildingType: at the moment the codelist (BuildingType.xml) is only containing 3 possible values:
- SingleFamilyHouse
- MultiFamilyHouse
- ApartmentBlock
We suggest to expand the codelist with the following:
- SFH (Single Family House)
- MFH (Multi Family House)
- TH (Terraced House)
- AB (Apartment Block)
- HLB (Historical large building)
- HSB (Historical small building)
The latter are crucial to estimate energy needs in historical centres (e.g. Ferrara, in Sunshine project).
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/119How to specify U-values at building scale?2017-11-27T09:10:03+01:00Moritz Robert LausterHow to specify U-values at building scale?*Created by: oliviertournaire*
I am wondering how it is possible to define U values at building scale only. Let's say that a building is modeled in LOD 0 (lod0Footprint + measuredHeight) or in LOD 1, it can be interesting for some simul...*Created by: oliviertournaire*
I am wondering how it is possible to define U values at building scale only. Let's say that a building is modeled in LOD 0 (lod0Footprint + measuredHeight) or in LOD 1, it can be interesting for some simulation tools to define a single U value for the walls and / or the ground and / or the roof.
I can use several `Construction` instances and attach them to the building, but how can I differentiate them (except using a convention that fills the `gml:name` or `gml:description`)?
v0.8.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/32Internal Gains management2015-11-27T11:41:03+01:00Moritz Robert LausterInternal Gains management*Created by: bahujean*
**-- Label Building occupants --**
**1-** Up to now, internal gains are attributes in the featureTypes:
- as "internGains" within the "occupancy" featureType
- as "heatLosses" within the "electricalAppliances" f...*Created by: bahujean*
**-- Label Building occupants --**
**1-** Up to now, internal gains are attributes in the featureTypes:
- as "internGains" within the "occupancy" featureType
- as "heatLosses" within the "electricalAppliances" featureType
They design the same effect and are at the same level. That's why it could be relevant to **rename both attributes "heatDissipation"**.
**2-** It could be also relevant to **insert an "internalGains" attribute within the "UsageZone" featureType**. User could then choose if he wants to directly use a simplified attribute or provide more detailed calculation for internal Gains.
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/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/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/51Relation between _AbstractBuilding and ThermalZone2015-10-23T08:56:34+02:00Moritz Robert LausterRelation between _AbstractBuilding and ThermalZone*Created by: Maryamzk*
Hi again,
Another recommendation:
The relation between _AbstractBuilding and ThermalZone is recommended to be composition hierarchy, since energy need of thermal zone is strongly dependent on the entire building...*Created by: Maryamzk*
Hi again,
Another recommendation:
The relation between _AbstractBuilding and ThermalZone is recommended to be composition hierarchy, since energy need of thermal zone is strongly dependent on the entire building (effects of unconditioned spaces for example). This is the same for relation between ThermalBoundarySurface and ThermalZone, where, no thermal zone can exist without thermal boundary surface.
https://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/54footprintArea2015-11-11T14:41:19+01:00Moritz Robert LausterfootprintArea*Created by: RomainNouvel*
the footprint area of a building is sometimes required for the calculation of performance, environmental and planning ratio.
-> a parameter footprintArea may be added in the _AbstractBuilding class
*Created by: RomainNouvel*
the footprint area of a building is sometimes required for the calculation of performance, environmental and planning ratio.
-> a parameter footprintArea may be added in the _AbstractBuilding class
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/107Relation "consistsOf" instead of "consiststOf"2016-05-10T17:14:34+02:00Moritz Robert LausterRelation "consistsOf" instead of "consiststOf"*Created by: RomainNouvel*
Small type mistake on the relation between Occupants and Household.
Please correct relation name -> consistsOf. The relation name could be even improved/simplified ("are", "groupedIn", "arrangedIn"...)
*Created by: RomainNouvel*
Small type mistake on the relation between Occupants and Household.
Please correct relation name -> consistsOf. The relation name could be even improved/simplified ("are", "groupedIn", "arrangedIn"...)
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/131EnergySystem Module: no _CityObjects?2017-05-29T14:01:36+02:00Moritz Robert LausterEnergySystem Module: no _CityObjects?*Created by: gioagu*
Hello,
I have noticed that none of the EnergySystem classes is derived from a _CityObject, but is "just" a Feature.
I my opinion, many of them (EnergyDistributionSystem, EnergyStorageSystem, Emitter, EnergyCon...*Created by: gioagu*
Hello,
I have noticed that none of the EnergySystem classes is derived from a _CityObject, but is "just" a Feature.
I my opinion, many of them (EnergyDistributionSystem, EnergyStorageSystem, Emitter, EnergyConversionSystem) should actually be derived from a _CityObject.
If so, I believe this change should be backported directly to the 0.8 version.
What do you think?
Greetings,
g
https://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/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/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/24Vacant in HouseholdType Codelist2015-11-27T11:46:14+01:00Moritz Robert LausterVacant in HouseholdType Codelist*Created by: oliviertournaire*
[Reported by Piergiorgio Cipriano]
The term “Vacant” is already included in the ResidenceType codelist.
We propose to remove "Vacant" from this list.
Household is "A unit for the population census, every ...*Created by: oliviertournaire*
[Reported by Piergiorgio Cipriano]
The term “Vacant” is already included in the ResidenceType codelist.
We propose to remove "Vacant" from this list.
Household is "A unit for the population census, every individual or group of individuals residing in the same dwelling"; therefore this codelist should not contain values referring to the status of the dwelling.
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/27Tag version to v0.5.02015-03-12T20:27:58+01:00Moritz Robert LausterTag version to v0.5.0*Created by: oliviertournaire*
When everyone will agree, tag version to v0.5.0.
The version in the UML model will also have to be upgraded.
*Created by: oliviertournaire*
When everyone will agree, tag version to v0.5.0.
The version in the UML model will also have to be upgraded.
0.5.0https://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/30Missing association between ThermalZone and UsageZone2015-11-24T11:49:38+01:00Moritz Robert LausterMissing association between ThermalZone and UsageZone*Created by: 900k*
There was once an association from ThermalZone to UsageZone [0..\* -> 0..*]. The role name was "relatesTo". It must have gone lost during the separation of the modules.
*Created by: 900k*
There was once an association from ThermalZone to UsageZone [0..\* -> 0..*]. The role name was "relatesTo". It must have gone lost during the separation of the modules.
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/33Rename the "Occupancy" featureType2015-11-27T11:41:18+01:00Moritz Robert LausterRename the "Occupancy" featureType*Created by: bahujean*
-- Label Building Occupant --
**Rename the "Occupancy" featureType "Occupants"** in order to avoid misunderstanding regarding the multiplicity indices with BuildingUnit or UsageZone.
*Created by: bahujean*
-- Label Building Occupant --
**Rename the "Occupancy" featureType "Occupants"** in order to avoid misunderstanding regarding the multiplicity indices with BuildingUnit or UsageZone.
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/35Labels by creating issues2015-11-10T22:48:51+01:00Moritz Robert LausterLabels by creating issues*Created by: bahujean*
-- label bug --
Be able to insert directly a label by creating an issue would be very useful.
*Created by: bahujean*
-- label bug --
Be able to insert directly a label by creating an issue would be very useful.
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/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/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/40new sample file2015-05-07T14:11:52+02:00Moritz Robert Lausternew sample file*Created by: PRemmen*
I created a first CityGML file for our internal workflow. What we basically do is to create archetype building with help of statistical data. The input is very generall (in this case: Type of Building: Residantial,...*Created by: PRemmen*
I created a first CityGML file for our internal workflow. What we basically do is to create archetype building with help of statistical data. The input is very generall (in this case: Type of Building: Residantial, year of construction: 1988, number of storys: 1, height of storys: 3 and net floor area: 200) According to this data typical wall construction for this type of building are selected. I saved the whole data set using following ADE Energy Classes:
- _AbstractBuilding
- ThermalZone
- ThermalBoundarySurface
- Construction including Glazing and OpaqueMaterial
Don't know if that sample file helps, but since I had to create it anyway I will provide it to you. Any comments are welcome
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/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/48Schedule LoD1/ daily usage ending and starting time2015-11-27T11:43:16+01:00Moritz Robert LausterSchedule LoD1/ daily usage ending and starting time*Created by: Maryamzk*
Usage time defined by starting time and ending time cannot be adapted to all cases. For example, for cases that starting time and ending time of different days a week varies, like a restaurant with off-day on Thur...*Created by: Maryamzk*
Usage time defined by starting time and ending time cannot be adapted to all cases. For example, for cases that starting time and ending time of different days a week varies, like a restaurant with off-day on Thursdays. Maybe changing starting time and ending time to usage hour per week is more accurate, as it is defined in ISO 13790, as well. Moreover, switched-off time is also required, since for considering intermittency effects on heating demand according to ISO 13790, the longest and shortest switched-off time during calculation time (month for Monthly balance) is required.
Therefore, we can modify the schedule in LoD1 as:
• Changing starting time and ending time to longest and shortest switched off time in month
• Adding usage hour per week
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/53Identify BuildingUnit also with address(parts)?2015-11-27T11:43:50+01:00Moritz Robert LausterIdentify BuildingUnit also with address(parts)?*Created by: gioagu*
Hi,
I am thinking whether and how a BuildingUnit (e.g. a flat) could be futher identified with the useful parts of the address after the house number.
Example: "Hauptstraße 10/A/15"
Generally, I'd use only Haupts...*Created by: gioagu*
Hi,
I am thinking whether and how a BuildingUnit (e.g. a flat) could be futher identified with the useful parts of the address after the house number.
Example: "Hauptstraße 10/A/15"
Generally, I'd use only Hauptstraße 10/A as address, as the remaining parts refers only to the door number. (In Austria it can be even more complex, but let's keep it simple).
Maybe we could add an attribute to BuildingUnit which contains this remaining part, while the normal address is associated with the whole building (as usual)?
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/59Window missing in ThermalBoundarySurfaceTypeType2015-10-29T16:04:51+01:00Moritz Robert LausterWindow missing in ThermalBoundarySurfaceTypeType*Created by: PRemmen*
A window can also be a ThermalBoundarySurface but is not part of the Enumeration "ThermalBoundarySurfaceTypeType" am I missing something ?
*Created by: PRemmen*
A window can also be a ThermalBoundarySurface but is not part of the Enumeration "ThermalBoundarySurfaceTypeType" am I missing something ?
https://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/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/67Modelling the time period of a time series2017-11-27T09:06:19+01:00Moritz Robert LausterModelling the time period of a time series*Created by: JoachimBenner*
Actually, we are using the ISO type _TM_Period_ for beginning and end of both, regular and irregular time series, In the irregular time series, each value has an absolute time position (_TP_Position_), which ...*Created by: JoachimBenner*
Actually, we are using the ISO type _TM_Period_ for beginning and end of both, regular and irregular time series, In the irregular time series, each value has an absolute time position (_TP_Position_), which means that the definition of a TemporalExtent in principle is superflous. The only use case could be to enable the validation, whether a certain value falls into the specified temporal extent. Is this really needed?
I propose to shift the the attribute _temporalExtent \* from *_TimeSeries_ to _RegularTimeSeries_.
In GML, TM_Period is encoded as _gml:TimePeriodType_. This type works very well to define **absulute** time periods, e.g.
1. January 2014 - 14. march 2014
2010 - 2012
January 2010 - march 2012
8.00 h - 12:00 h
What is **not possible** with gml:TimePeriodType is to specify a date interval without an explicit year, e.g.
January - October
1. January - 31. January
I think this is a problem, because e.g. statistical climate data do not refer to a specific year, but to specific days, years and months within a year. Actually, I do not know a good way to express this type of information in GML. Has anyone ideas?
I would like to label this issue, but I do not know how to do this!
v0.8.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/68Schedule - change type and rename2016-01-14T13:49:33+01:00Moritz Robert LausterSchedule - change type and rename*Created by: gioagu*
Hello,
as discussed in Munich yesterday during the workshop, there are some requests regarding the schedules. The following proposals are from Giorgio, Thomas and Romain, but they were also (briefly) discussed with...*Created by: gioagu*
Hello,
as discussed in Munich yesterday during the workshop, there are some requests regarding the schedules. The following proposals are from Giorgio, Thomas and Romain, but they were also (briefly) discussed with the other participants during the afternoon brainstorming.
1) Rename the exising schedules as follows:
- ScheduleLoD0 --> ConstantValueSchedule
- ScheduleLoD1 --> DualValueSchedule
- ScheduleLoD2 --> DailyPatternSchedule
- ScheduleLoD3 --> TimeSeriesSchedule
The reason is that using the LoDx naming leads to confusion. What is more, a schedule does not correspond to a specific LoD of a building.
2) As a schedule may be reused several times, the type should be changed from "DataType" to "FeatureType"
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/69TimeSeries - optional/obsolete attributes2016-01-14T13:49:02+01:00Moritz Robert LausterTimeSeries - optional/obsolete attributes*Created by: gioagu*
Hello,
as discussed yesterday in Munich during the workshop, some attributes in the _TimeSeries need to be removed or changed. In detail:
1) the id attribute is obsolete and should be deleted.
2) the temporalExte...*Created by: gioagu*
Hello,
as discussed yesterday in Munich during the workshop, some attributes in the _TimeSeries need to be removed or changed. In detail:
1) the id attribute is obsolete and should be deleted.
2) the temporalExtent (which is not necessary for instance for irregular time series, or regular time series used for a DailySchedule) should be an optional attribute.
3) in TimeValuesProperties, the qualityDescription and the source should be also optional attributes.
4) The variableLabel is obsolete since it is already included in GML, and should be then removed.
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/70UML Diagrams in readme2016-01-15T14:07:10+01:00Moritz Robert LausterUML Diagrams in readme*Created by: mlauster*
The UML Diagrams are currently linked in readme.md (source: doc/UML_diagrams/) as well as in Guidelines_EnergyADE.md (source: guidelines/fig/), what in turn is linked in readme.md. I propose to keep them solely in...*Created by: mlauster*
The UML Diagrams are currently linked in readme.md (source: doc/UML_diagrams/) as well as in Guidelines_EnergyADE.md (source: guidelines/fig/), what in turn is linked in readme.md. I propose to keep them solely in Guidelines_EnergyADE.md, this will improve readability and we don't have two different versions of UML's.
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/71move guidelines to doc2016-02-03T12:06:34+01:00Moritz Robert Laustermove guidelines to doc*Created by: mlauster*
Would it make sense to move guidelines to doc?
*Created by: mlauster*
Would it make sense to move guidelines to doc?
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/73Name/Rename of "landmarked" attribute in class building2016-07-01T09:55:21+02:00Moritz Robert LausterName/Rename of "landmarked" attribute in class building*Created by: gioagu*
Some comments to consider for the 0.7 version
Giorgio: In class Building_ADE, given that it is boolean, we should rename the attribute to “isLandmark”, for consistence with other attributes (isSunExposed, etc.)
Ro...*Created by: gioagu*
Some comments to consider for the 0.7 version
Giorgio: In class Building_ADE, given that it is boolean, we should rename the attribute to “isLandmark”, for consistence with other attributes (isSunExposed, etc.)
Romain: We’ve decided that heritage and landmark building information would be not mentioned in the Energy ADE (but a proposition will be made to the CityGML 3.0 working group). As a consequence, this attribute should be deleted from the Energy ADE 0.6.
Joachim: I suggest to leave this attribute and follow Giorgio’s proposition to rename it to “isLandmarked”. It is correct that this is a general CityGML issue, but I expect CityGML 3.0 not before late 2017, if any. In IFC, a building also has such an attribute, which shows that it might be relevant for some applications.
v0.7.0https://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/78Images not resized in guidelines (PDF file)2016-01-15T16:33:24+01:00Moritz Robert LausterImages not resized in guidelines (PDF file)*Created by: oliviertournaire*
In the guidelines pdf file, images are not resized to fit page width. Thus, UML diagrams are cropped and not fully visible.
@mlauster can you take care of this?
*Created by: oliviertournaire*
In the guidelines pdf file, images are not resized to fit page width. Thus, UML diagrams are cropped and not fully visible.
@mlauster can you take care of this?
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/81EnergyCarrierTypeValues - need Fernwaerme2016-02-17T14:09:50+01:00Moritz Robert LausterEnergyCarrierTypeValues - need Fernwaerme*Created by: anetefr*
If in real data there is energy source fernwärme, there is no place where to properly map it in enumeration EnergyCarrierTypeValues.
I image that fernwärma will appear quite often in data. It could be added to enu...*Created by: anetefr*
If in real data there is energy source fernwärme, there is no place where to properly map it in enumeration EnergyCarrierTypeValues.
I image that fernwärma will appear quite often in data. It could be added to enumeration.
However, then mandatory nature of "co2EmssionFactor" and "primaryEnergyFactor" might arise problems then.
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/85Little BUG in Energy ADE 0.6 due to typo2016-06-29T20:37:01+02:00Moritz Robert LausterLittle BUG in Energy ADE 0.6 due to typo*Created by: gioagu*
In the relation between Occupants and Households, there is a typo (both in the xsd and in the UML diagram) which reads:
consiststOf
Please note the double "st", which is an involuntarily typo - but definitely hard...*Created by: gioagu*
In the relation between Occupants and Households, there is a typo (both in the xsd and in the UML diagram) which reads:
consiststOf
Please note the double "st", which is an involuntarily typo - but definitely hard to spot ;-)
I think this should be corrected in the 0.6 version, too.
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/91_SolarEnergySystem2016-07-01T09:53:45+02:00Moritz Robert Lauster_SolarEnergySystem*Created by: RomainNouvel*
In the Energy ADE 0.6:
1. the SolarEnergySystem present only the geometrical information "collectorSurface", "panelAzimuth" and "panelInclination", and not a given geometrical surface.
2. Furthermore, it is li...*Created by: RomainNouvel*
In the Energy ADE 0.6:
1. the SolarEnergySystem present only the geometrical information "collectorSurface", "panelAzimuth" and "panelInclination", and not a given geometrical surface.
2. Furthermore, it is linked only to BoundarySurface with an optional double relations:
a) The "installedOn" relation from SolarEnergySystem to BoundarySurface is the mostly used case, where we want to calculate the photovoltaic electricity production of a given PV system, in particular to cover the electrical demand. This relation should be mandatory.
b) The "equippedWith" relation from BoundarySurface to SolarEnergySystem has been originally designed for Photovoltaic Potential study, where the SolarEnergySystem is a floating object not related to an EnergyDemand. This relation could be avoid if the SolarEnergySystem is related in a way with a Building (which is possible with the relation "has" from AbstractBuilding to EnergyConversionSystem.
3. The case of tilted PV panels on flat roof is not considered in our Schema (here, the SolarEnergySystem MUST be laid on a Roof/facade)
4. The attribute _area_ of SolarEnergySystem should be detailed (aperture area, module area, gross area?).
5. The present schema does not allow to integrate Hybrid PVT panels
**Propositions for Energy ADE 0.7:**
- It should be possible to relate SolarEnergySystem with a (outer) BuildingInstallation instead of a _BoundarySurface
- An optional attribute _surfaceGeometry_ , type GM_MultiSurface[0..1], would be required in the case that the solar panels do not correspond 1-to-1 to the BoundarySurface
- the attribute panelAzimuth and panelInclination are not necessary/relevant, from the moment that a relation exist between SolarEnergySystem and BoundarySurface, respectively BuildingInstallation (or if the optional attribute _surfaceGeometry_ is indicated).
- the relation "equippedWith" from BoundarySurface to SolarEnergySystem could be deleted.
- the relation "installedOn" from SolarEnergySystem to BoundarySurface, respectively BuildingInstallation, should have the cardinality 0..1 (if a Solar installation covers really several BoundarySurface, then it should be divided in several SolarEnergySystem).
- The SolarEnergySystem should be distinguished between "PhotovoltaicSystem" (with only attributes _moduleArea_ and _cellMaterialType_, since installedNominalPower (=peak power) and nominalEfficiency (=performance ratio) are already the attributes of EnergyConversionSystem), "SolarThermalSystem" (with attributes _apertureArea_, _eta0_, _a1_, _a2_ and _technologyType_) and "PhotovoltaicThermalSystem" (with all attributes of the two latters).
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/92Double Relation EnergyConversionSystem <-> _AbstractBuilding2016-06-29T22:43:51+02:00Moritz Robert LausterDouble Relation EnergyConversionSystem <-> _AbstractBuilding*Created by: RomainNouvel*
in the version Energy ADE 0.6: 2 relations exist to link EnergyConversionSystem and _AbstractBuilding:
1- "has" goes from _AbstractBuilding to EnergyConversionSystem.
2- 'installedIn" goes from _EnergyConversi...*Created by: RomainNouvel*
in the version Energy ADE 0.6: 2 relations exist to link EnergyConversionSystem and _AbstractBuilding:
1- "has" goes from _AbstractBuilding to EnergyConversionSystem.
2- 'installedIn" goes from _EnergyConversionSystem
This loop isn't very pretty/practical for modellers
I wonder why the second relation is useful. Couldn't we delete "installedIn"?
"has" is a pretty general term. Couldn't we use "equippedWith" instead?
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/94Rename relations *usageZones* and *thermalZones*2016-06-29T20:56:56+02:00Moritz Robert LausterRename relations *usageZones* and *thermalZones**Created by: JoachimBenner*
In the CityGML standard as well as in the EnergyADE, most relation names are stated in singular. This has a good reason, because in the XML encoding the relation property either points to (via xlink:href) or ...*Created by: JoachimBenner*
In the CityGML standard as well as in the EnergyADE, most relation names are stated in singular. This has a good reason, because in the XML encoding the relation property either points to (via xlink:href) or imbeds exactly one related XML-element. Thus, the new relation _thermalZones_ (_AbstractBuilding --> ThermalZone) must be instanciated once for every ThermalZone of the building, and the plural usage in the relation name is misleading and inconsistant with the rest of the data model. The same situation occurs with the relation _usageZones_ (_AbstractBuilding --> UsageZone).
**Proposal:**
1. Rename _thermalZones_ --> _thermalZone_
2. Rename _usageZones_ --> _usageZone_
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/97Order of object attributes in XSD file2016-06-29T22:23:17+02:00Moritz Robert LausterOrder of object attributes in XSD file*Created by: RomainNouvel*
Hi,
I wonder how have been ordered the attributes of the different objects, and if there is a way to list them alphabetically, in order to find out quickly the different attributes and possible XML errors
*Created by: RomainNouvel*
Hi,
I wonder how have been ordered the attributes of the different objects, and if there is a way to list them alphabetically, in order to find out quickly the different attributes and possible XML errors
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/98LevelOfRefurbishment -> codeList2016-06-29T22:22:17+02:00Moritz Robert LausterLevelOfRefurbishment -> codeList*Created by: RomainNouvel*
I think we agreed last meeting in Munich to set the LevelOfRefurbishment as a codeList (extendable) rather than a enumeration, so that anybody may extend this list, depending on the case study and its building...*Created by: RomainNouvel*
I think we agreed last meeting in Munich to set the LevelOfRefurbishment as a codeList (extendable) rather than a enumeration, so that anybody may extend this list, depending on the case study and its building libraries.
Do you confirm?
v0.7.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/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/108Cardinality of relation "energyDistribution"2016-06-29T21:20:04+02:00Moritz Robert LausterCardinality of relation "energyDistribution"*Created by: RomainNouvel*
In the version 0.6 of the Energy ADE, an EnergyDemand may have several EnergyDistributionSystem, because of the cardinality 0..\* of the relation "energyDistribution". Is that possible? Will that be useful / u...*Created by: RomainNouvel*
In the version 0.6 of the Energy ADE, an EnergyDemand may have several EnergyDistributionSystem, because of the cardinality 0..\* of the relation "energyDistribution". Is that possible? Will that be useful / useable in urban energy modelling?
I will suggest to fix a maximum of 1 EnergyDistributionSystem per EnergyDemand -> Cardinality of relation energyDistribution : 0..1.
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/110Integrate Parameters for LCA - phase construction/refurbishment2016-07-01T11:41:03+02:00Moritz Robert LausterIntegrate Parameters for LCA - phase construction/refurbishment*Created by: RomainNouvel*
Up to know, we've only considered the primary energy and CO2 emissions for the operational phase of the building. More and more urban analyses consider also the "grey energy" and the "embodied carbon" to take ...*Created by: RomainNouvel*
Up to know, we've only considered the primary energy and CO2 emissions for the operational phase of the building. More and more urban analyses consider also the "grey energy" and the "embodied carbon" to take some decision.
Here is a proposal discussed with Alessio, to integrate (step by step) the construction/refurbishment phase in our Energy ADE:
In the Construction Module:
- introduction of the new attribute EmbodiedCarbon in the class "SolidMaterial" : optional, measureType (generally kgCO2/m3 or kgCO2/kg), definition : CO2 equivalent emissions caused by the fabrication and transportation on site of the material.
- introduction of the new attribute EmbodiedEnergy in the class "SolidMaterial" : optional, measureType (generally J/m3 or J/kg), definition : Primary energy consumed for the fabrication and transportation on site of the material.
- introduction of the new attribute LifeSpan in the class "Construction" : optional, TimePeriod type (or Time length), definition: Period of service life, including the construction/installation date and the expected end of life.
- introduction of the new attribute LifeSpan in the class "Layer" : optional, TimePeriod type (or Time length), definition: Period of service life, including the construction/installation date and the expected end of life.
In the Energy and System Module:
- introduction of the new attribute LifeSpan in the class "EnergyConversionSystem", "EnergyDistributionSystem" and "_StorageSystem" : optional, TimePeriod type (or Time length), definition: Period of service life, including the construction/installation date and the expected end of life.
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/113New efficiency related attributes in HeatPump and CombinedHeatAndPower2016-06-29T20:50:42+02:00Moritz Robert LausterNew efficiency related attributes in HeatPump and CombinedHeatAndPower*Created by: RomainNouvel*
Request of Change: (coming from WG conf call discussion):
1- in object HeatPump :
- Delete carnotEfficiency
- Add the optional attributes "copSourceTemperature" (Type: MeasureType, Definition: Source temperat...*Created by: RomainNouvel*
Request of Change: (coming from WG conf call discussion):
1- in object HeatPump :
- Delete carnotEfficiency
- Add the optional attributes "copSourceTemperature" (Type: MeasureType, Definition: Source temperature defining the Coefficient Of Performance of the heat pump) and "copOperationTemperature" (Type: MeasureType, Definition: Operation or supply water temperature defining the Coefficient Of Performance of the heat pump)
2- in object ConbinedHeatPower:
- Add the optional attributes "thermalEfficiency" (Type: ScaleType, Definition : Efficiency of the heat production, corresponding to the quotient of the thermal output over the fuel input) and "electricalEfficiency" (Type: ScaleType, Definition : Efficiency of the power production, corresponding to the quotient of the electrical output over the fuel input)
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/118Mandatory relation between ThermalZone and ThermalBoundary?2017-11-27T09:09:22+01:00Moritz Robert LausterMandatory relation between ThermalZone and ThermalBoundary?*Created by: oliviertournaire*
I am wondering if the _boundedBy_ relation between `ThermalZone` and `ThermalBoundary` is really mandatory. The cardinality is set to `1..*`.
However, if one just want to model a building and attached the...*Created by: oliviertournaire*
I am wondering if the _boundedBy_ relation between `ThermalZone` and `ThermalBoundary` is really mandatory. The cardinality is set to `1..*`.
However, if one just want to model a building and attached the properties `isCooled` or `isHeated`, he has to define a `ThermalZone`. Sounds good. However, as long as you define a `ThermalZone`, you are obliged to also model a `ThermalBoundary`. I do not think this is really necessary.
Your opinions?
v0.8.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/129Emitters2017-05-29T14:06:49+02:00Moritz Robert LausterEmitters*Created by: RomainNouvel*
Emitters (also called end use unit or zoning system) have been modelled in an earlier version of the Energy ADE (0.4.3) before to be removed for simplification purpose.
They mainly relate to the end use types...*Created by: RomainNouvel*
Emitters (also called end use unit or zoning system) have been modelled in an earlier version of the Energy ADE (0.4.3) before to be removed for simplification purpose.
They mainly relate to the end use types SpaceHeating, SpaceCooling and Ventilation.
It could be interested to integrate them again in the schema, either directly connected to the EnergyDemand object or as attribute of the DistributionSystem.
Emitters could be an object with as attributes: emitter type (radiators ect.), heatExchangeType, installed power, number etc...https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/134Solar thermal parameters2017-11-27T09:25:01+01:00Moritz Robert LausterSolar thermal parameters*Created by: RomainNouvel*
To be more comprehensible, we could replace the attribute names of SolarThermalSystem and PhotovoltaicThermalSystem:
eta0 -> zero heat loss efficiency (scaletype[0.1]), also called optical efficiency
a1 -> l...*Created by: RomainNouvel*
To be more comprehensible, we could replace the attribute names of SolarThermalSystem and PhotovoltaicThermalSystem:
eta0 -> zero heat loss efficiency (scaletype[0.1]), also called optical efficiency
a1 -> linear heat loss coefficient (numerical)
a2 -> quadratic heat loss coefficient (numerical)https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/137Classification of Emitter in EnergySystem module2017-11-27T09:26:14+01:00Moritz Robert LausterClassification of Emitter in EnergySystem module*Created by: gioagu*
In a first attempt to reorganise hierarchically most of the entities in the Energy System module, the classification of Emitter is somehow unclear. We have so far three "big families" of classes: Conversion, Storage...*Created by: gioagu*
In a first attempt to reorganise hierarchically most of the entities in the Energy System module, the classification of Emitter is somehow unclear. We have so far three "big families" of classes: Conversion, Storage and Distribution. The emitter is however alone and only connected to a Distribution class.
I was wondering, together with Joachim and Romain, whether there could be a way to characterise it a bit better. On one side, it is delivering energy to satisfy an energy demand, but it is not connected to it. On the other side, is it really a device which distributes energy (e.g. heat?), or just the end node of a distribution system?
The general idea is to define a general abstract class _EnergySystem which generalises all Conversion, Distribution and Storage Systems. An UML diagramme, and a new ticket, will be ready issued soon (thx Joachim!).
Dear members of the Energy System team, could you please help?
Thank you for your help!
ghttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/142Version 0.9.0, first draft2017-11-27T14:49:22+01:00Moritz Robert LausterVersion 0.9.0, first draft*Created by: JoachimBenner*
I finalized a first draft of the next version **EnergyADE 0.9.0,**
The following issues have been regarded in the new data model: #118, #119, #133, #135, #136 and #137
There are three other open issue...*Created by: JoachimBenner*
I finalized a first draft of the next version **EnergyADE 0.9.0,**
The following issues have been regarded in the new data model: #118, #119, #133, #135, #136 and #137
There are three other open issues concerning the EnergySystem (#123, #124 and #134) where obviously there is not yet a hamonized solution within the Energy System working group. As soon as a proposal from the working group exists, I can try to integrate it into the new version.
The same is applies for issue #138, up to now I do not totally understand it.
[EnergyADE_0_9_0.zip](https://github.com/cstb/citygml-energy/files/1108926/EnergyADE_0_9_0.zip)
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/173Use of <gml:targetElement>2021-06-17T15:55:28+02:00Ghost UserUse of <gml:targetElement>The xsd of the Energy ADE v1.0 makes use of the GML element `<gml:targetElement>`. This element is part of the GML 3.2 encoding rule. It does not exist in GML 3.1.1. Was there a specific reason, why you made use of this element, altough ...The xsd of the Energy ADE v1.0 makes use of the GML element `<gml:targetElement>`. This element is part of the GML 3.2 encoding rule. It does not exist in GML 3.1.1. Was there a specific reason, why you made use of this element, altough the xsd of the Energy ADE is based on GML 3.1.1.?
I am asking, because we came across this issue in the Utility Network ADE recently: https://github.com/TatjanaKutzner/CityGML-UtilityNetwork-ADE/issues/12https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/174Lack of "equippedWith" association for EnergySystems2021-06-17T15:59:51+02:00Giorgio AgugiaroLack of "equippedWith" association for EnergySystemsAlthough the Energy Systems module may need a major overhaul for the next version (or a drastic simplification?), I noticed that as of now an EnergySystem has a "installedIn" association, but we are missing a rather useful "equippedWith"...Although the Energy Systems module may need a major overhaul for the next version (or a drastic simplification?), I noticed that as of now an EnergySystem has a "installedIn" association, but we are missing a rather useful "equippedWith" association of a _CityObject to an EnergySystem. I fear, this has been "lost" in the process of moving from previous versions to v. 1.0... ;-)
As of now, EnergySystems are written as root elements with an Xlink to the _CityObject they are installed in. But it'd be more reasonable to have them as child elements of the _CityObject they are installed in (e.g. of a building).
Any thoughts?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/175Missing Inclination and Azimuth attributes for SolarEnergySystems2021-06-17T16:05:04+02:00Giorgio AgugiaroMissing Inclination and Azimuth attributes for SolarEnergySystemsAs of Energy ADE v. 1.0, we can optionally store the geometry of the (solar/PV/...) panels. In that case, azimuth and tilting angles can be derived from geometry. But if we do not have geometry (which sometime happens...), we have no way...As of Energy ADE v. 1.0, we can optionally store the geometry of the (solar/PV/...) panels. In that case, azimuth and tilting angles can be derived from geometry. But if we do not have geometry (which sometime happens...), we have no way to store those attributes.
I'd propose to add them (back) again.
Any comments?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/176windDirection as WeatherDataTypeValue2022-12-07T15:54:10+01:00Giuseppe PeronatowindDirection as WeatherDataTypeValueWind direction is crucial to calculate Heat Transfer Coefficients for each surface and is normally contained in weather files for Building Performance Simulations. However, this parameter is not part of the Enumeration **WeatherDataTypeV...Wind direction is crucial to calculate Heat Transfer Coefficients for each surface and is normally contained in weather files for Building Performance Simulations. However, this parameter is not part of the Enumeration **WeatherDataTypeValue**.
In my opinion, the arguments against a soilTemperature parameter (see https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/154) do not apply in this case, as the wind direction is a basic parameter in weather stations and does not need a specific model.
I would then propose to extend the Enumeration **WeatherDataTypeValue** with a new item **windDirection**.