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/136New optional attribute thematicDescription in TimeValuesProperties2018-12-06T10:43:38+01:00Moritz Robert LausterNew optional attribute thematicDescription in TimeValuesProperties*Created by: JoachimBenner*
The data type **TimeValueProperties** enables the specification of a number of meta data of the related time series. I miss a textual property for a thematic sedcription of the time series values (e.g. dry-bu...*Created by: JoachimBenner*
The data type **TimeValueProperties** enables the specification of a number of meta data of the related time series. I miss a textual property for a thematic sedcription of the time series values (e.g. dry-bulb temperature, relative humidity, hourly energy demand, ...), One purpose of the proposed property is to use it in the legend of a diagram visualizing the time series values.
It might be that the attribute **source** is provided for this role, but the definition is too vague.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/127Management of codelists and codelists' values2018-12-06T10:43:38+01:00Moritz Robert LausterManagement of codelists and codelists' values*Created by: pgcipriano*
Dear all,
please find enclosed three Excel files I already shared with some of you in June.
[3_Codelist.xlsx](https://github.com/cstb/citygml-energy/files/579097/3_Codelist.xlsx)
[4_CodelistValue.xlsx](https:...*Created by: pgcipriano*
Dear all,
please find enclosed three Excel files I already shared with some of you in June.
[3_Codelist.xlsx](https://github.com/cstb/citygml-energy/files/579097/3_Codelist.xlsx)
[4_CodelistValue.xlsx](https://github.com/cstb/citygml-energy/files/579096/4_CodelistValue.xlsx)
[2_ApplicationSchema.xlsx](https://github.com/cstb/citygml-energy/files/579095/2_ApplicationSchema.xlsx)
They are examples of "list of applicationSchemas", "list of codelists" and "codelist' values" based on INSPIRE Re3gistry (http://inspire.ec.europa.eu/codelist/) and already extended in GeoSmartCity project (http://hub.geosmartcity.eu/registry/codelist/).
As agreed in Wien, in the CityGML Energy ADE we need something like this.
For all the Excel files (in particular for "codelists" and "codelistValue") we need to collect “labels” and “definitions” in different languages (at least German, Italian, French).
We might have the “list of codelists” for Energy ADE (based on the enclosed Excel file "3_codelist") with national labels and definitions before the workshop in Ferrara.
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/126GasStorageSystem2018-12-06T10:43:38+01:00Moritz Robert LausterGasStorageSystem*Created by: kwakuwulf*
_As discussed in Vienna I'm adding some issues from the viewpoint of industrial process modelling:_
Waste water treatment plants may even have `GasStorageSystems` from sludge treatment (biogas).
Attributes: ...*Created by: kwakuwulf*
_As discussed in Vienna I'm adding some issues from the viewpoint of industrial process modelling:_
Waste water treatment plants may even have `GasStorageSystems` from sludge treatment (biogas).
Attributes:
- `powerCapacity`
- `volume`
- `methan-content`https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/125Heat Recovery in EnergySystem2018-12-06T10:43:38+01:00Moritz Robert LausterHeat Recovery in EnergySystem*Created by: kwakuwulf*
_As discussed in Vienna I'm adding some issues from the viewpoint of industrial process modelling:_
We've discussed internal heat recovery, which I would define in our context as follows: Using waste heat from...*Created by: kwakuwulf*
_As discussed in Vienna I'm adding some issues from the viewpoint of industrial process modelling:_
We've discussed internal heat recovery, which I would define in our context as follows: Using waste heat from within the company/building via heat exchanger or heat pump for an energy demand in the same company/building.
I can't right remember what the best way of defining internal heat recovery in the EnergyADE would be. We've discussed adding another `EnergyConversionSystem` named `(Waste)HeatExchanger` or even a generic EnergyConversionSystem.
I leave this open for discussion.
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/124Steam distribution systems2018-12-06T10:43:38+01:00Moritz Robert LausterSteam distribution systems*Created by: kwakuwulf*
_As discussed in Vienna I'm adding some issues from the viewpoint of industrial process modelling:_
I was wondering how one would define a steam system in the EnergyADE. Two areas of concern:
- `ThermalDist...*Created by: kwakuwulf*
_As discussed in Vienna I'm adding some issues from the viewpoint of industrial process modelling:_
I was wondering how one would define a steam system in the EnergyADE. Two areas of concern:
- `ThermalDistributionSystem`: most distribution system in industries are based on steam. For that purpose the `returnTemperature `and `supplyTemperature` are insufficient information. The pressure of the supply line and the condensate return percentage would be important information. Maybe we could add another inheritance to `EnergyDistributionSystem `named `SteamDistributionSystem ` that specifically addresses the requirements of steam distribution and does not affect the "normal" distribution systems of buildings.
- Similary a `SteamBoiler `could be added to `EnergyConversionSystems` to allow a more specific definition of a steam boiler
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/123Include required temperature for thermal energy demands2018-12-06T10:43:38+01:00Moritz Robert LausterInclude required temperature for thermal energy demands*Created by: kwakuwulf*
_As discussed in Vienna I'm adding some issues from the viewpoint of industrial process modelling:_
In the feature type `EnergyDemand` the required temperature should be included. I think not only in industria...*Created by: kwakuwulf*
_As discussed in Vienna I'm adding some issues from the viewpoint of industrial process modelling:_
In the feature type `EnergyDemand` the required temperature should be included. I think not only in industrial modelling the required temperature (maybe: _setTemperature_ ) of the energy demand is a key information for simulation.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/120Optional property construction for ThermalBoundary2018-12-06T10:43:38+01:00Moritz Robert LausterOptional property construction for ThermalBoundary*Created by: JoachimBenner*
While developping an interface of the Energy ADE to the commercial Energy Simulation System we are using, we got a problem. Our system needs the material/construction properties and the area of the complete T...*Created by: JoachimBenner*
While developping an interface of the Energy ADE to the commercial Energy Simulation System we are using, we got a problem. Our system needs the material/construction properties and the area of the complete Thermal Boundary (i.e. the area including windows), and directly related with the Thermal Boundary the material properties and areas of the corresponding Openings (windows or doors), The area of Openings is always regarded as **difference areas**, which need to be subtracted from the total area of the Thermal Boundary.
Because gxXML models openings in a similar way, I expect the other simulation systems implement a similar logics. However, the actual version 0.7.0. of the Energy ADE is not very good suited to represent a hierarcy of Thermal Boundaries and corresponding Openings, because all ThermalComponents are on the same level, regardless whether they represent opaque or transparent parts of the Thermal Boundary.
I therefore propose to allow a Thermal Boundary optionally to be related with a Construction. This would introduce much more flexibility into our data model.
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/1213DCityDB Extension for Energy-ADE2018-12-06T10:43:38+01:00Moritz Robert Lauster3DCityDB Extension for Energy-ADE*Created by: yaozhihang*
Dear Energy-Team,
this Github-repository (see the link below) might be useful for some of you who have an interest in using the open source software 3DCityDB for managing CityGML-Energy-ADE data. I would be gla...*Created by: yaozhihang*
Dear Energy-Team,
this Github-repository (see the link below) might be useful for some of you who have an interest in using the open source software 3DCityDB for managing CityGML-Energy-ADE data. I would be glad about any feedbacks from you for improving my work.
https://github.com/yaozhihang/3DCityDB-Extensions-for-CityGML-ADEs
Kind regards,
Zhihang
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/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/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/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/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/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/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!
g