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/117missing <gml:reverseProperty> element for binary association2018-12-06T10:43:38+01:00Moritz Robert Laustermissing <gml:reverseProperty> element for binary association*Created by: yaozhihang*
Hi,
after checking the Energy-ADE XSD schema file I've noticed the following issue:
According to the ISO 19136;2009(E), an annotation tag with gml:reverseProperty element is needed to represent the assocation ...*Created by: yaozhihang*
Hi,
after checking the Energy-ADE XSD schema file I've noticed the following issue:
According to the ISO 19136;2009(E), an annotation tag with gml:reverseProperty element is needed to represent the assocation which is navigable in both directions. For example, the following XML code should be embedded into the XML code of the _EnergyConversionSystem_ class:
```
<element name="provides" minOccurs="0" maxOccurs="unbounded" type="energy:EnergyDemandPropertyType" />
<annotation>
<appinfo><gml:reverseProperty>energy:isProvidedBy</gml:reverseProperty></appinfo>
</annotation>
</element>
```
Zhihang
backloghttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/114Restrict Construction / ConstructionOrientation to relevant ADE features2018-12-06T10:43:38+01:00Moritz Robert LausterRestrict Construction / ConstructionOrientation to relevant ADE features*Created by: JoachimBenner*
In ADE version 0.6.0, we defined the new classes **Construction** and **ConstructionOrientation**, and simultaneously introduced the extension attribute **construction** of **_CityObject**. This allows that ...*Created by: JoachimBenner*
In ADE version 0.6.0, we defined the new classes **Construction** and **ConstructionOrientation**, and simultaneously introduced the extension attribute **construction** of **_CityObject**. This allows that every CityGML feature of the base standard as well as of the Energy ADE can refer to layered material information.
This is problematic due to two different reasons:
- It is not the task of the Energy ADE to define general extensions of the base standard, especially in cases where a corresponding change request for CityGML 3.0 already exists.
- Concerning the specific features of the EnergyADE, there are many of them where the **construction** relation does not make sense (e.g. **ThermalZone**, **UsageZone**, ..) or where the specification of material information is even forbidden (**ThermalBoundary**).
I therefore propose to delete the _general_ **construction** relation from **_CityObject** to **Construction / ConstructionOrientation**, and to introduce _specific relations_ for those classes of the base standard and the extension where the concept is really needed: **_BoundarySurface** and **ThermalComponent**.
For simplifying the schema, I furthermore propose to introduce a new, abstract super class **AbstractConstruction** of **Construction** and **ConstructionOrientation**, which can be used as relation target.
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/105Clarification of attribute "buildingType"2018-12-06T10:43:38+01:00Moritz Robert LausterClarification of attribute "buildingType"*Created by: JoachimBenner*
The ADEElement _AbstractBuilding has an attribute _buildingType_, defined as
> Classification of building according with their usage and form (e.g. single-family house, multi-family house, office building,...*Created by: JoachimBenner*
The ADEElement _AbstractBuilding has an attribute _buildingType_, defined as
> Classification of building according with their usage and form (e.g. single-family house, multi-family house, office building, industrial building).
I thik that a usage classification and a form classification are two different topics which should not be mixed. For the usage classification, there already exist two attributes in the CityGML base standard (_function_ - originally intended building function; _usage_ - actual building usage). Thus, I think the attribute buildingType should only define a form typology. In this context, is the actually existing Codelist BuildingType really adequate?
backloghttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/106Relation "correspondsTo" from ThermalBoundary to _BoundarySurface2018-12-06T10:43:38+01:00Moritz Robert LausterRelation "correspondsTo" from ThermalBoundary to _BoundarySurface*Created by: JoachimBenner*
The ADE class ThermalBoundary has a relation _correspondsTo_ of carnilality 0..1 to the CityGML base class _BoundarySurface. In case on an LOD4 model with Room, InteriorWallSurface, FloorSurface and CeilingSu...*Created by: JoachimBenner*
The ADE class ThermalBoundary has a relation _correspondsTo_ of carnilality 0..1 to the CityGML base class _BoundarySurface. In case on an LOD4 model with Room, InteriorWallSurface, FloorSurface and CeilingSurface objects, this is problematic, because a ThermalBoundry will be related with **two** _BoundarySurface objects:
- For exterior thermal boundaries, it is related with one exterior boundary surface (e.g. a WallSurface) and one interior boundary surface (e.g. a InteriorWallSurface)
- For interior thermal boundaries, it is related with two interior boundary surfaces (e.g. two objects InteriorWallSurface)
Therefore, I propose to change the cardinality of _correspondsTo_ to **0..2**.
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/150Unification of CodeList Element styles in the UML model2019-05-14T10:49:38+02:00Moritz Robert LausterUnification of CodeList Element styles in the UML model*Created by: JoachimBenner*
The UML model of the Energy ADE actually refers to 6 CodeLists, which partly explicitly specify codes (OfficialAreaReferenceValue, EnergyCarrierTypeValue, RefurbishmentClassValue, OwbershipTypeValue, Occupant...*Created by: JoachimBenner*
The UML model of the Energy ADE actually refers to 6 CodeLists, which partly explicitly specify codes (OfficialAreaReferenceValue, EnergyCarrierTypeValue, RefurbishmentClassValue, OwbershipTypeValue, OccupantTypeFalue) and partly are empty (BuildingTypeValue, CurrentUseValue). This shound be unified.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/149Modularization of the Energy ADE UML model2018-12-06T10:43:38+01:00Moritz Robert LausterModularization of the Energy ADE UML model*Created by: JoachimBenner*
We frequently speak about Energy ADE modules like "Building physics module" or "Energy systems module", but formally speaking the UML model has no modular structure. This at least hinders the maintenance of t...*Created by: JoachimBenner*
We frequently speak about Energy ADE modules like "Building physics module" or "Energy systems module", but formally speaking the UML model has no modular structure. This at least hinders the maintenance of the data model.
Therefore, for a first official version a number of sub-folders should be integrated in the main folder EnergyADE of the UML model:
- EnergyADE Core
- Building Physics
- Occupance
- Material and Construction
- Energy systems
- Time series and schedules
In each of these sub-folders the corresponding UML elements and diagrams are aggeegated. It is debatable whether this modular structure of the conceptional model is also reflected in the GML encoding (separate namespaces and XML-schema files for different modules). I personally strongly prefer to stay with one Energy ADE namespace and one schema file.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/148Eliminate inconsistencies between ThermalBoundary and ThermalOpening2019-05-14T10:48:44+02:00Moritz Robert LausterEliminate inconsistencies between ThermalBoundary and ThermalOpening*Created by: JoachimBenner*
In the FeatureType _ThermalBoundary_, the properties _area_ and _staticConstruction_ (better _construction_, see #147) are **optional**. On the other hand, in _ThermalBoundary_ the corresponding properties ar...*Created by: JoachimBenner*
In the FeatureType _ThermalBoundary_, the properties _area_ and _staticConstruction_ (better _construction_, see #147) are **optional**. On the other hand, in _ThermalBoundary_ the corresponding properties are both mandatory. There is no real reason for this inconsistency. Furthermore, if an explicit geometry of the _ThermalOpening_ is available (_surfaceGeometry_), the _area_ can be calculated.
Proposal: Define _area_ and _openingConstruction_ (_construction_, see #147) as **optional** (0..1) properties.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/90DailyPatternSchedule2018-12-06T10:43:38+01:00Moritz Robert LausterDailyPatternSchedule*Created by: jaykae26*
The daily pattern schedules can be defined according to:
- Detailed schedule composed of daily schedules associated to recurrent day types (weekday, weekend etc.).
But.. how do you specify WHEN these days happen ...*Created by: jaykae26*
The daily pattern schedules can be defined according to:
- Detailed schedule composed of daily schedules associated to recurrent day types (weekday, weekend etc.).
But.. how do you specify WHEN these days happen during the year? Of course an easy answer can be formulated for Monday to Sunday, but what about a Holiday? It can be at different periods of the year depending on the country.
v0.7.0https://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/145Should all Enumeration items start with a small or capital letter?2019-10-08T08:31:04+02:00Moritz Robert LausterShould all Enumeration items start with a small or capital letter?*Created by: JoachimBenner*
In order to be consistent with CityGML and UtilityNetworks ADE, in version 0.9.0 all Enumerations items were adapted to start with a small letter. On the other hand, all Codelist items now start with a capita...*Created by: JoachimBenner*
In order to be consistent with CityGML and UtilityNetworks ADE, in version 0.9.0 all Enumerations items were adapted to start with a small letter. On the other hand, all Codelist items now start with a capital letter, which again is some knd of inconsistency. Thus, the appropriate style for Enumeration and Codelist items should be reconsidered.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/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/95Mandatory and additional properties for _TimeSeries2018-12-06T10:43:38+01:00Moritz Robert LausterMandatory and additional properties for _TimeSeries*Created by: JoachimBenner*
For the processing of time series (__TimeSeries_), it is essential to know how the different values need to be interpreted, e.g. whether they represent the total amount of a measure value or a single value, w...*Created by: JoachimBenner*
For the processing of time series (__TimeSeries_), it is essential to know how the different values need to be interpreted, e.g. whether they represent the total amount of a measure value or a single value, whether the measure values are related with the preceeding or the succeding time interval, and whether it is feasible to interpolate between different values. This indispensible information can be stated with the property _interpolationType_ of _TimeValuesProperties_, with actually is optional but should be mandatory.
In several use cases, the time series will be generated by "meters" (e.g. electricity or gas meters), and the values of the time series represent a "total amount" (InterpolationType _InstantaneousTotal_, _PreceedingTotal_ or _SucceedingTotal_). The meters normally have a value different from zero at the starting time of the time series, and this starting value must be known to interpret the time series values.
**Proposal**
1. Make property _variableProperties_ of __TimeSeries_ **mandatory**
2. Make property _interpolationType" of *TimeValuesProperties_ **mandatory**
3. **Add optional property** _startValue_ (type _Measure_) to _TimeValuesProperties_
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/144EnergyConversionSystem as abstract class2017-11-27T14:53:30+01:00Moritz Robert LausterEnergyConversionSystem as abstract class*Created by: JoachimBenner*
In the actual version, we declared __EnergyDistributionSystem_ and __StorageSystem_ as **abstract** classes, because we want to ensure that only the specializations like _ThermalDistributionSystem_ are instan...*Created by: JoachimBenner*
In the actual version, we declared __EnergyDistributionSystem_ and __StorageSystem_ as **abstract** classes, because we want to ensure that only the specializations like _ThermalDistributionSystem_ are instanziated in an EnergyADE document. Is there a reason why we treat _**EnergyConversionSystem**_ in a different manner? There are many specific classes for energy conversion systems being derived from the base class _EnergyConversionSystem_, but it is still possible to use the base class.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/143Stereotype of OfficialAreaReferenceValue and VolumeTypeValue2019-10-08T08:30:01+02:00Moritz Robert LausterStereotype of OfficialAreaReferenceValue and VolumeTypeValue*Created by: JoachimBenner*
From my point of view, there is an inconsistancy in the modelling of _OfficialAreaReferenceValue_ (Entries: _NetFloorArea_, _GrossFloorArea_, _EnergyReferenceArea_, Stereotype **CodeList**) and _VolumeTypeVal...*Created by: JoachimBenner*
From my point of view, there is an inconsistancy in the modelling of _OfficialAreaReferenceValue_ (Entries: _NetFloorArea_, _GrossFloorArea_, _EnergyReferenceArea_, Stereotype **CodeList**) and _VolumeTypeValue_ (Entries _NetVolume_, GrossVolume, _EnergyReferenceVolume_, Stereotype **Enumeration**). I see no reason to use different modelling concepts and therefore propose to define **Enumerations** in both cases.https://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/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/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/141Sensors, Timeseries and measurements requirements2018-12-06T10:43:38+01:00Moritz Robert LausterSensors, Timeseries and measurements requirements*Created by: pascal-schetelat*
This issue is meant to discuss all energy-ade partners needs and use case concerning time series, measurement, sensor and other related concepts.*Created by: pascal-schetelat*
This issue is meant to discuss all energy-ade partners needs and use case concerning time series, measurement, sensor and other related concepts.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/79Time series for weather / climate data2016-07-01T10:01:56+02:00Moritz Robert LausterTime series for weather / climate data*Created by: JoachimBenner*
Weater or climate data are important input data for energy simulations. In version 0.6.0 we can specify time series of global solar irradiance and daylight illumanance for Boundary Surfaces. But there are man...*Created by: JoachimBenner*
Weater or climate data are important input data for energy simulations. In version 0.6.0 we can specify time series of global solar irradiance and daylight illumanance for Boundary Surfaces. But there are many more relevant meteorological parameters like temperature, wind speed, relative humidity, .... Most of them must be connected to the building as a whole, as this is not possible in the actual version of the Energy ADE.
Thus, I propose to add the property **climateData: _TimeSeries[0..*]** as ADE attribute of _AbstractBuilding
v0.7.0