citygml-energy issueshttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues2019-05-14T10:48:44+02:00https://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/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.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/139Automatic schema validation on Github2017-12-11T09:46:26+01:00Moritz Robert LausterAutomatic schema validation on Github*Created by: pascal-schetelat*
I've merged the automatic validation process into the master and realease branche v0.8 and v0.9.0
## What it does:
If any of you add a sample file in the v0.8 release branch, github will automaticall...*Created by: pascal-schetelat*
I've merged the automatic validation process into the master and realease branche v0.8 and v0.9.0
## What it does:
If any of you add a sample file in the v0.8 release branch, github will automatically test wether this sample file validate against the most recent version of the v0.8 energy.xsd
## How it does it :
- For every commit done on the master or release branches (since v0.8), github launches a test procedure with travi-ci
- The test try to validate all the *.gml files that it founds in citygml-energy/samples/ against the energy.xsd schema
- If any file fails to validate, the test will be reported as failing
- If all the files validate, the test will be reported as passing
- It will update the build status badge displayed in the main page of the repository. If you switch to a specific branch on the main page, the badge will actually reflect the status of that branch.
Here are the current status of the different branches :
- master : [![Build Status](https://travis-ci.org/cstb/citygml-energy.svg?branch=master)](https://travis-ci.org/cstb/citygml-energy)
- v0.8 : [![Build Status](https://travis-ci.org/cstb/citygml-energy.svg?branch=v0.8)](https://travis-ci.org/cstb/citygml-energy)
- v0.9.0 : [![Build Status](https://travis-ci.org/cstb/citygml-energy.svg?branch=v0.9.0)](https://travis-ci.org/cstb/citygml-energy)
As of today (17/05/2017, v0.9.0 is just a copy of v0.8)
To see which files fail to validate, click on the badge, click on the branches tab and select the build at fault. Skip to the bottom of the test log and look at **"KO"**
For instance, as of today, there is an issue the a sample file in the master :
```python
../samples/Rotterdam_Bospolder_bldgAttr.gml
KO
/home/travis/build/cstb/citygml-energy/samples/Rotterdam_Bospolder_bldgAttr.gml:2:0:ERROR:SCHEMASV:SCHEMAV_CVC_ELT_1: Element '{http://www.opengis.net/citygml/1.0}CityModel': No matching global declaration available for the validation root.
```
Meaning this sample file does not validate because it is compliant with citygml 1.0
# what next ?
That kind of procedure could be extended to test any kind of tools that rely on the ADE, for instance if the 3DCityDB Extension for Energy-ADEdatabase is working as expected.
Let me know if any of you have any remarks/ questions regarding this new feature and if you wish to extend it, I'll briefly talk about it next week on the workshop
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/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/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/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/133Change cardinality of relation ThermalOpening-->_Opening2017-11-27T09:24:37+01:00Moritz Robert LausterChange cardinality of relation ThermalOpening-->_Opening*Created by: gioagu*
The current relation "relatesTo" has cardinality 0..1.
We should extend it to 0..* in order to be able to also define _ThermalOpenings (e.g. just in terms of global area in m^2) that actually correspond to (the s...*Created by: gioagu*
The current relation "relatesTo" has cardinality 0..1.
We should extend it to 0..* in order to be able to also define _ThermalOpenings (e.g. just in terms of global area in m^2) that actually correspond to (the sum of) multiple _Openings.
Agree?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/132Occupancy Module: about class type of Facilities2017-11-27T09:23:25+01:00Moritz Robert LausterOccupancy Module: about class type of Facilities*Created by: gioagu*
Hello!
This is, as a matter of fact, a direct continuation of the previous issue regarding the EnergySystem.
Piergiorgio and I were wondering whether it coule make sense to derive the class Facilities directly f...*Created by: gioagu*
Hello!
This is, as a matter of fact, a direct continuation of the previous issue regarding the EnergySystem.
Piergiorgio and I were wondering whether it coule make sense to derive the class Facilities directly from _CityObject, similarly to the UsageZone and the BuildingUnit.
Or, on the other hand, why where they defined as Features (as they are now) and not as CityObjects?
What do you think?
g & pg
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