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/138Wall interior to ThermalZone2018-12-06T10:43:38+01:00Moritz Robert LausterWall interior to ThermalZone*Created by: LydiaTC*
The CSTB needs to be able to create walls (or slabs) interior to a thermal zone (but not boundaries).
Previously, in v.0.7, we would connect a thermalZone to 0..* thermalComponents to do this.
This is no longer ...*Created by: LydiaTC*
The CSTB needs to be able to create walls (or slabs) interior to a thermal zone (but not boundaries).
Previously, in v.0.7, we would connect a thermalZone to 0..* thermalComponents to do this.
This is no longer possible in v0.8. in which we can only connect to thermalBoundaries.
We would suggest creating a parent class thermalComponent, with a specialisation as thermalBoundaries, and containing the 0..* thermalOpenings. https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/140Codelists: values, definitions and translations2019-10-08T08:31:43+02:00Moritz Robert LausterCodelists: values, definitions and translations*Created by: lucagiovannini*
Thank you all for the discussion we started during the workshop in Grenoble!
As agreed, I'm opening this issue to support the discussion and finalize the activity on codelists.
Here you can find the **go...*Created by: lucagiovannini*
Thank you all for the discussion we started during the workshop in Grenoble!
As agreed, I'm opening this issue to support the discussion and finalize the activity on codelists.
Here you can find the **google spreadsheet** updated with the workshop decisions:
https://docs.google.com/spreadsheets/d/1QosN8dEW757ht1OqTdTOicw2Yy57syTqrXZA3tcAVUY/edit#gid=454796838
This is my suggestion on how to proceed:
- To avoid branches we should work on the **English version** of the codelist. Once that is agreed and fixed we can just translate into the other languages.
- Please check **codelist sources, values and descriptions**. Use the column "comments" to propose changes, improvements or doubts.
- If you have suggestions for **major modifications** (like for BuildingTypeValue, CurrentUseValue), please make your point here on this issue thread and not on the spreadsheet
To keep the momentum I propose to put a **deadline for this activity on mid-june**, with a final skype call among the people (Mariam, Joachim, Usman, Romain, Lydia, Emilien, Piergiorgio, Luca) identified during the workshop in Grenoble in order to finalize the English version.
Here is a **doodle** for this skype call, please fill it: http://doodle.com/poll/5n8qkmgkac9aw5qa
After that I would put a **final deadline for end-June for the translations** in German, French and Italian.
What do you think?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/130Simulation results2018-12-06T10:43:38+01:00Moritz Robert LausterSimulation results*Created by: JoachimBenner*
I think the EnergyADE should be able to represent also the **output data of simulation systems**. At the moment, it is possible to include simulated energy demands into an EnergyADE file, but not, e.g., the s...*Created by: JoachimBenner*
I think the EnergyADE should be able to represent also the **output data of simulation systems**. At the moment, it is possible to include simulated energy demands into an EnergyADE file, but not, e.g., the simulated actual temperature of a Thermal Zone.
Because the ADE supports different types of simulations and mutiple simulation systems, it is quite difficult to model arbitrary simulation results. Therefore, I propose to start with a very simple and generic data type **_SimulationData_:** A **text attribute** describing the simulated quantity (e.g. actual temperature) and a **Time Series** with time dependent, scalar data. This data structure can be referenced by every city object (ADE attribute of _CityObject). In future versions of the standard, it might be extended for other types of simulation data, or for supporting references to data bases.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/135New feature type / city object for aggregations of weather data2018-12-06T10:43:38+01:00Moritz Robert LausterNew feature type / city object for aggregations of weather data*Created by: JoachimBenner*
Energy ADE version 0.8.0 defines a new type WeatherData, providing a time series of data for one meteorological or physical parameter. In order to sufficiently support energy related simulations, a new featur...*Created by: JoachimBenner*
Energy ADE version 0.8.0 defines a new type WeatherData, providing a time series of data for one meteorological or physical parameter. In order to sufficiently support energy related simulations, a new feature type / city object is needed, which (1) aggregates **all weather data time series** which shall be used by a specific simulation and (2) can be integrated into an Energy ADE model as city object. Attached a proposal for a corresponding feature type **WeatherStation**. Comments are welcome
![weatherstation](https://cloud.githubusercontent.com/assets/6430204/24095997/f00ebf82-0d5f-11e7-96a3-ee90ae13f69a.jpg)
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/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/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/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/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/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/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/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/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/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/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/93Relation ThermalZone --> UsageZone2018-12-06T10:43:38+01:00Moritz Robert LausterRelation ThermalZone --> UsageZone*Created by: JoachimBenner*
The relation _relates_ from _ThermalZone_ to _UsageZone_ has cardinality **0..**, which means that one ThermalZone may be related with multiple UsageZones. Furthermore, the UML model indicates that one UsageZ...*Created by: JoachimBenner*
The relation _relates_ from _ThermalZone_ to _UsageZone_ has cardinality **0..**, which means that one ThermalZone may be related with multiple UsageZones. Furthermore, the UML model indicates that one UsageZone may be related with more than one ThermalZone. **From my point of view, both cardinalities are not useful**.
**1.) Thermal Zone referencing multiple UsageZones (BLDG_1 in attached example)**
A basic feature of a ThermalZone is to be **isotherm**, which means that heat transfer can only occur via a ThermalBoundary, but not within a ThermalZone. However, if we have two UsageZones with different temperature level within one ThermalZone, there will be heat transfer within the ThermalZone. Thus, a ThermalZone cannot be geometrically separated into different UsageZones. What is the sense to partition the same volumetric part of a building into different UsageZones, how are, for instance, different heating or cooling schedules overlayed?
**2.) Two ThermalZones reference the same UsageZone (BLDG_2 in attached example)**
For energy simulations, the main purpose of the UsageZone concept is to provide the different ThermalZones with input data like set-point temperatures and internal gains. I can imagine that different ThermalZones can use the same heating, cooling or ventilation schedules, but the UsageZone also has a property **internalGains** (specifying the total internal losses or gains within this UsageZone), and relations to the building units, occupants and facilities related with the UsageZone. If the UsageZone is related with different ThermalZones, how shall the heat sources and heat sinks be distributed among the ThermalZones? There is no information available for doing this, and therefore the concept is not really useful in practice.
[ThermalZone-UsageZone.zip](https://github.com/cstb/citygml-energy/files/193034/ThermalZone-UsageZone.zip)
v0.7.0https://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/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/103Choose a license2018-12-06T10:43:38+01:00Moritz Robert LausterChoose a license*Created by: mlauster*
We currently do not have a license for CityGML ADE Energy.
That means, we are quite restrictive, to cite github:
"You're under no obligation to choose a license. It's your right not to include one with your code...*Created by: mlauster*
We currently do not have a license for CityGML ADE Energy.
That means, we are quite restrictive, to cite github:
"You're under no obligation to choose a license. It's your right not to include one with your code or project, but please be aware of the implications. Generally speaking, the absence of a license means that the default copyright laws apply. This means that you retain all rights to your source code and that nobody else may reproduce, distribute, or create derivative works from your work. This might not be what you intend."
https://help.github.com/articles/open-source-licensing/
To open the discussion, what about MIT license?
http://choosealicense.com/
http://choosealicense.com/licenses/mit/
backloghttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/122Industrial FeatureTypes in EnergyConversionSystem2018-12-06T10:43:38+01:00Moritz Robert LausterIndustrial FeatureTypes in EnergyConversionSystem*Created by: kwakuwulf*
_As discussed in Vienna I'm adding some issues from the viewpoint of industrial process modelling:_
Adding _chiller_ and _air compressor_ as feature types in `EnergyConversionSystem`.
*Created by: kwakuwulf*
_As discussed in Vienna I'm adding some issues from the viewpoint of industrial process modelling:_
Adding _chiller_ and _air compressor_ as feature types in `EnergyConversionSystem`.
v0.8.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/65add Mandatory Units of Measure2019-10-08T08:32:29+02:00Moritz Robert Lausteradd Mandatory Units of Measure*Created by: RomainNouvel*
List of units of measure should be mandatory (for instance: m2 and not m² nor sqm).
Check if we can use standard list of units / uri. How do we deal with it in GML
*Created by: RomainNouvel*
List of units of measure should be mandatory (for instance: m2 and not m² nor sqm).
Check if we can use standard list of units / uri. How do we deal with it in GML
backloghttps://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/56Building Key Performance Indicators (KPI)2018-12-06T10:43:38+01:00Moritz Robert LausterBuilding Key Performance Indicators (KPI)*Created by: RomainNouvel*
Key Performance Indicators may be important for energy analyses at urban scale, helping for example to understand building consumptions, plan an energy refurbishment strategy, or compare different energy plann...*Created by: RomainNouvel*
Key Performance Indicators may be important for energy analyses at urban scale, helping for example to understand building consumptions, plan an energy refurbishment strategy, or compare different energy planning variants.
They are generally intermediary/final outputs, deduced from other geometry and physical parameters of the 3d city model.
Some useful KPI:
- surfaceAreaToVolumeRatio (index of compacity)
- meanUValue (global envelope insulation level)
- specificPrimaryEnergyDemand (global efficiency of the building)
This issue is a general question: do we want to include some KPIs in our ADE Energy? If yes, they would be parameters of _AbstractBuilding.
backloghttps://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/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/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/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/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/151Typo in relation "emitts"2019-05-14T10:33:02+02:00Giorgio AgugiaroTypo in relation "emitts"If you look at the UML diagram, you will notice that relation between EnergyFlow and EmitterSystem is written eimiTTs (with double T).
This is clearly a small typo to be corrected.If you look at the UML diagram, you will notice that relation between EnergyFlow and EmitterSystem is written eimiTTs (with double T).
This is clearly a small typo to be corrected.Joachim BennerJoachim Bennerhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/152Redundant relation "parameter" for WeatherStation2019-10-28T08:30:44+01:00Giorgio AgugiaroRedundant relation "parameter" for WeatherStationA _CityObject is extended to have 0..* WeatherData objects through "weatherData" relation.
A WeatherStation is derived from _CityObject, and can have additionally 0..* Weatherdata through "parameter" relation.
This ("parameter") is IMO...A _CityObject is extended to have 0..* WeatherData objects through "weatherData" relation.
A WeatherStation is derived from _CityObject, and can have additionally 0..* Weatherdata through "parameter" relation.
This ("parameter") is IMO redundant and should hence be removed.Joachim BennerJoachim Bennerhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/153Missing Logo of Dedagroup Public Services2019-07-11T13:03:17+02:00Avichal MalhotraMissing Logo of Dedagroup Public Services@pgcipriano Could you please check once again the logo of the Dedagroup Public Services. Please upload it under : ..//citygml-energy/doc/logos@pgcipriano Could you please check once again the logo of the Dedagroup Public Services. Please upload it under : ..//citygml-energy/doc/logosPiergiorgioPiergiorgiohttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/154Specification of soil temperatures2022-12-07T15:17:21+01:00Joachim BennerSpecification of soil temperaturesThe energy exchange between a building and the surrounding soil definitely affects the energetic behavior of the building. An important parameter to model this effect is the time-varying soil temperature. Thus, it should be possible to s...The energy exchange between a building and the surrounding soil definitely affects the energetic behavior of the building. An important parameter to model this effect is the time-varying soil temperature. Thus, it should be possible to specify a time series of soil temperatures in the Energy ADE.
One way to realize this is to consider soil temparatures as additional weather data parameters by extending the Enumeration **WeatherDataTypeValue** with a new item **soilTemperature**.
![SoilTemperature](/uploads/b1a21a93e7a84034974987d23e92671e/SoilTemperature.png)Joachim BennerJoachim Bennerhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/155Modelling of partly touching buildings2019-10-24T15:02:36+02:00Joachim BennerModelling of partly touching buildingsEspecially in densly populated city centers, it often occurs that neighboring buildings partly or fully touch each other. In this case, the building's energetic behavior significantly differs from a free-standing building. Unfortunately,...Especially in densly populated city centers, it often occurs that neighboring buildings partly or fully touch each other. In this case, the building's energetic behavior significantly differs from a free-standing building. Unfortunately, CityGML completely lacks a concept for "shared walls/roofs", and existing CityGML building models therefore do not represent closed building structures correcty. A single CityGML Building object is always bounded by *exterior* BoundarySurfaces (WallSurface, RoofSurface, GroundSurface).
In the Energy ADE, a ThermalBoundary object can be specified as "sharedWall". In reality, often only a part of a wall or roof surface is shared with a neighboring building, and the remaining part is facing the outside air. Thus, for transforming CityGML BoundarySurface into Energy ADE ThermalBoundary objects, a separation of the BoundarySurface geometry is needed, which is a time consuming and error-prone process. In most cases, it is much faster and much more robust only to calculate the **size of the shared area**. It is therefore proposed to add a numeric attribute to ThermalBoundary to either specify the absolute **sharedAreaSize** (type Area), or the ratio of shared area to total BoundarySurface area (**sharedAreaRatio**, type Scale).
![ThermalBoundary](/uploads/d4dd82a831a7ada79985f04c29193aac/ThermalBoundary.png)Joachim BennerJoachim Bennerhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/156Explicit specification of convective heat transfer coefficients2019-10-24T15:48:09+02:00Joachim BennerExplicit specification of convective heat transfer coefficientsMost building energy simulation systems automatically calculate the inside and outside convective heat transfer coefficients. In some cases, especially for modelling benchmark tests list BESTEST, it should however be possible to explicit...Most building energy simulation systems automatically calculate the inside and outside convective heat transfer coefficients. In some cases, especially for modelling benchmark tests list BESTEST, it should however be possible to explicitly specify these parameters. It is therefore proposed to extend the class **Construction** by two parameters **insideConvectionCoefficient** and **outsideConvectionCoefficient** (type Measure).
![Construction](/uploads/cb1d1af8e23a3560aa3a695587f3b89d/Construction.png)Joachim BennerJoachim Bennerhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/157Modelling of Layer and LayerComponent2019-10-24T16:22:33+02:00Joachim BennerModelling of Layer and LayerComponentAn Energy ADE Construction may refer to an ordered list of Layer objects, and a Layer is composed of one or more LayerComponents. In version 1.0, the layer thickness can be specified individually for each LayerComponent. This enables to ...An Energy ADE Construction may refer to an ordered list of Layer objects, and a Layer is composed of one or more LayerComponents. In version 1.0, the layer thickness can be specified individually for each LayerComponent. This enables to specify highly complex constructions (see below), which cannot be processed by existing building energy simulation systems. It is therefore proposed to ransfer the attribute thickness from LayerComponent to Layer.
![ComplexLayerModel](/uploads/3c91320f9856c9d7fb8891dd228b3bc0/ComplexLayerModel.png)
![NewLayerModel](/uploads/ae5259b84ba9f208bdc3bede516e5ed4/NewLayerModel.png)Joachim BennerJoachim Bennerhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/158Revision of dataType OpticalProperties2019-10-24T16:18:32+02:00Joachim BennerRevision of dataType OpticalPropertiesThe dataType OpticalProperties enables to specify reflectance, transmittance and emissivity of a construction, but not the **absorptance**. Especially for opaque materials, simulation systems like EnergyPlus support the specification of ...The dataType OpticalProperties enables to specify reflectance, transmittance and emissivity of a construction, but not the **absorptance**. Especially for opaque materials, simulation systems like EnergyPlus support the specification of this parameter. That due to physical laws the absorptance can principally be calculated on base of reflectance, transmittance and emissivity is totally irrelevant in this context: It is much better to directly specify the needed parameter instaed of three non-needed parameters.
In addition to reflectance, transmittance and emissivity, the dataType OpticalProperties has a parameter glazingRatio, specifying the glazing ratio of a ThermalOpening referencing the Construction. Conceptionally, glazing ration is not an optical property, but a structural parameter of either a Construction or a ThermalOpening.
It is therefore proposed
* to introduce a new dataType **Absorptance**,
* to extend OpticalProperties with a new attribute **absorptance: Absorptance [0..*]**,
* to eliminate the attribute **glazingRatio**.
In which class (Construction or ThermalOpening) the glazingRation shall be specified is open for discussion.
![Absorptance](/uploads/dce7226cf9a3ea76ef3882f5eeb3159f/Absorptance.png)Joachim BennerJoachim Bennerhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/159Multi-zone models2019-10-24T15:25:33+02:00Joachim BennerMulti-zone modelsFor thermal models containing more than one thermal zone, it is essential to know the topological structure of the zones. This especially means that internal thermal boundaries and their relations to the correnponding thermal zones need ...For thermal models containing more than one thermal zone, it is essential to know the topological structure of the zones. This especially means that internal thermal boundaries and their relations to the correnponding thermal zones need to be identified.
Energy ADE 1.0 represent an internal thermal boundary by **one object ThermalBoundary** (with thermalBoundaryType **interiorWall**, **intermediaryFloor**, ...), being related with **two objects ThermalZone**. This sounds good, but in fact is incorrect. In reality, thermal boundaries are **oriented surfaces** bounding the volume of the different thermal zones. The normal convention is that the **orientation** of a thermal boundary- in the Energy ADE either represented by the attributes **azimuth** / **inclination** or by an explicit surface (attribute **surfaceGeometry** ) - points out of the zone volume. In consequence, an **internal thermal boundary cannont be correctly represented by only one ThermalBoundary object**.
In the process of transforming an Energy ADE 1.0 model into a specifc simulation model like EnergyPlus IFD-file, it might principally be possible to correct this unavoidably error and switch the surface orientation for one of the two adjacent zones, but this is very difficult to implement. Therefore, a new concept is proposed to specify the topological structure in multi-zone models:
**Each ThermalBoundary object belongs to exactly one ThermalZone object. In consequence, internal thermal boundaries (and if necessary also internal thermal openings) are represented by two ThermalBoundary / ThermalOpening objects, refering each other by a relation isAdjacentTo of cardinality 0..1**.
![TwoThermalZones](/uploads/8a2e10ff479f292a55f08721ae619382/TwoThermalZones.png)
![MultiZoneModel](/uploads/741ae56a7d2e0a5067dca04cd1e53458/MultiZoneModel.png)Joachim BennerJoachim Bennerhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/160Modelling of multi-pane windows2019-10-24T16:31:28+02:00Joachim BennerModelling of multi-pane windowsIn the Energy ADE 1.0 construction model, optical properties like transmittance or reflectance can only be related with a complete construction, and not with individual layers. Due to this limitation, it is not possible to model the diff...In the Energy ADE 1.0 construction model, optical properties like transmittance or reflectance can only be related with a complete construction, and not with individual layers. Due to this limitation, it is not possible to model the different glass panes and gaps of a multi-pane window **individually**. This is inconsistant with the data model for opaque constructions, and in some cases complicates the usage of existing window data.
It is therefore proposed to enable an optional specification of optical properties on material level by introducing a new class **TransparentSolidMaterial**, derived from SolidMaterial. Furthermore, for representing gaps in multi-pane windows filled with different kinds of gases, an optional attribute **gasType** should be added to the class **Gas**.
![TransparentSolidMaterial](/uploads/a0b54c3b15d3d57dc4a38b1871dcc678/TransparentSolidMaterial.png)Joachim BennerJoachim Bennerhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/161Redundant attribute stationName in WeatherStation?2019-10-24T17:09:18+02:00Giorgio AgugiaroRedundant attribute stationName in WeatherStation?I may be wrong, but a WeatherStation is derived from a _CityObject, which itself inherits a number of attributes (e.g. id, description AND name).
I think therefore that this attribute could be dropped. Is there a specific reason for not ...I may be wrong, but a WeatherStation is derived from a _CityObject, which itself inherits a number of attributes (e.g. id, description AND name).
I think therefore that this attribute could be dropped. Is there a specific reason for not using the standard gml:name one?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/162Add attributes for File-based TimeSeries2019-10-24T16:53:35+02:00Giorgio AgugiaroAdd attributes for File-based TimeSeriesI was thinking that it might be useful to add one or two fields to the file-based TimeSeries classes, i.e.
is_compressed:Boolean=FALSE
compression_type:CompressionTypeValue[0..1]
CompressionTypeValue could be either an enumeration or a...I was thinking that it might be useful to add one or two fields to the file-based TimeSeries classes, i.e.
is_compressed:Boolean=FALSE
compression_type:CompressionTypeValue[0..1]
CompressionTypeValue could be either an enumeration or a codelist.
The attributes could be added to both classes, or an abstract class _TimeSeriesFile could be created between them and AbstractTimeSeries. In the latter case, other shared existing attributes (uom, file, etc...) could be moved to _TimeSeriesFile.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/163Minor renaming (demandedBy)2019-10-28T08:28:19+01:00Giorgio AgugiaroMinor renaming (demandedBy)For naming coherency, I'd propose to rename the role "demandedBy" to "isDemandedBy" (see EnergyDemand class).
This would be then in line with the other names we use between EnergySystems and EnergyFlow.For naming coherency, I'd propose to rename the role "demandedBy" to "isDemandedBy" (see EnergyDemand class).
This would be then in line with the other names we use between EnergySystems and EnergyFlow.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/164Minor changes to Facilities2019-10-24T16:34:20+02:00Giorgio AgugiaroMinor changes to FacilitiesFor design coherency and simmetry, I'd propose to make class Facilities abstract, and to add a subclass GenericFacilities. This would reflect what we do for example in the EnergyConversionSystems.For design coherency and simmetry, I'd propose to make class Facilities abstract, and to add a subclass GenericFacilities. This would reflect what we do for example in the EnergyConversionSystems.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/165Rename AbstractStorageSystem2019-09-09T15:31:43+02:00Giorgio AgugiaroRename AbstractStorageSystemFor naming coherency, I'd propose to rename class AbstractStorageSystem to AbstractEnergyStorageSystem. This would be in line with what we do with distribution and conversion systems.For naming coherency, I'd propose to rename class AbstractStorageSystem to AbstractEnergyStorageSystem. This would be in line with what we do with distribution and conversion systems.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/166Link SystemOperation to AbstractEnergySystem?2019-09-09T15:34:14+02:00Giorgio AgugiaroLink SystemOperation to AbstractEnergySystem?This is a question for the experts.
So far we have the SystemOperation class tied to AbstractConversionSystem.
It is (my guess) rather for historical reasons, as it was so before we changed the overall structure of the EnergySystem modul...This is a question for the experts.
So far we have the SystemOperation class tied to AbstractConversionSystem.
It is (my guess) rather for historical reasons, as it was so before we changed the overall structure of the EnergySystem module in v. 0.9.
Now, would it not make more sense to move the SystemOperation class one step higher (hence linked to AbstractEnergySystem? I can imagine that also the other systems might have some operation schedules, not only the conversion ones.
@malhotra, what do you think?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/167Possibly rename HeightAboveGround?2019-10-24T14:35:25+02:00Giorgio AgugiaroPossibly rename HeightAboveGround?Looking at the values in the enumeration, there are now indeed some values that might fit better as Height_Below_Ground, e.g. the entry "bottomThermalBoundary" or "bottomOfConstruction"
I wonder whether the overall name heightAboveGroun...Looking at the values in the enumeration, there are now indeed some values that might fit better as Height_Below_Ground, e.g. the entry "bottomThermalBoundary" or "bottomOfConstruction"
I wonder whether the overall name heightAboveGround still holds or we should rename it (or add an equivalent property heightBelowGround to ADE_AbstractBuilding)...
Any comments?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/168How to model multiple Buildings supplied by one EnergyConversionSystem2019-09-09T16:14:51+02:00Peter RemmenHow to model multiple Buildings supplied by one EnergyConversionSystemI want to model multiple buildings that are supplied by one `EnergyConversionSystem`. I only want to model the conversion system and attach a timeseries to the system. I do **not** want to model the `EnergyConversionSystem` . `EnergyFlow...I want to model multiple buildings that are supplied by one `EnergyConversionSystem`. I only want to model the conversion system and attach a timeseries to the system. I do **not** want to model the `EnergyConversionSystem` . `EnergyFlow` or the `EmitterSystem` in detail.
In previous version (I think) there was something like `EnergyConversionSystem.provides` where it was possible to link multiple `CityObject`. I do not see this link anymore.
I tried using `EnergyDemand`, but the link to `CityObject` with `demands` (in German: "verlangt") and `demandedBy` (in German: "wird verlangt von") is **very** confusing. Any ideas how to model that?
Suggestion: A direct link between `EnergyConversionSystem` and `EnergyDemand` (`EnergyDemand -> isProvidedBy -> AbstractEnergyConversionSystem`) would helpful.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/169ThermalZone should have isVentilated2019-10-24T15:36:35+02:00Peter RemmenThermalZone should have isVentilatedThe ThermalZone class should have an object, that describes if the thermal zone is ventialted through mechanical ventilation (similar to isHeated, isCooled).
Interesting enough: the UseageZone class already has an attribute "ventilatio...The ThermalZone class should have an object, that describes if the thermal zone is ventialted through mechanical ventilation (similar to isHeated, isCooled).
Interesting enough: the UseageZone class already has an attribute "ventilationSchedule".https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/170New Time Series type MonthlyTimeSeries2019-10-24T16:47:42+02:00Joachim BennerNew Time Series type MonthlyTimeSeriesIn the building simulation area, there are quite often monthly averages, and time series consisting of 12 monthly averages for a certain year. In principle, such a time series could be modelled as *IrregularTimeSeries*, but the processin...In the building simulation area, there are quite often monthly averages, and time series consisting of 12 monthly averages for a certain year. In principle, such a time series could be modelled as *IrregularTimeSeries*, but the processing would be much easier if only 12 monthly values and the corresponding year need to be specified.
It is therefore proposed to add a new class **MonthlyTimeSeries**, derived from *IrregularTimeSeries*, for specifying one value for each month of a specific year.![MonthlyTimeSeries](/uploads/74292351c03115ba65ca1103ed318c79/MonthlyTimeSeries.png)https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/171Heating and Cooling system availability schedules2019-10-24T16:45:07+02:00Joachim BennerHeating and Cooling system availability schedulesThe *UsageZone* class enables to specify schedules for heating and cooling set-point temperatures. It is implicitly assumed that the corresponding building systems are operating at any time. In practice, building systems may be not avail...The *UsageZone* class enables to specify schedules for heating and cooling set-point temperatures. It is implicitly assumed that the corresponding building systems are operating at any time. In practice, building systems may be not available at specific times of the year (e.g. heating in summer times) or of the day. At the moment, this could only be realized by specifying very low set-point temperatures for heating (or very high temperatures for the cooling system).
In order to decouple system set-point temperatures and system availability, it is proposed to introduce 2 new poptional properties in *UsageZone*:
***heatingAvailabilitySchedule: DailyPatternSchedule[0..1]***
***coolingAvailabilitySchedule: DailyPatternSchedule[0..1]***
In both schedules, there are only the values 0 (not available) and 1 (available).https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/172Provisional removal of the energy source model from the Energy ADE 2.02019-10-28T11:33:32+01:00Alexandru NichersuProvisional removal of the energy source model from the Energy ADE 2.0Dear colleagues,
As concluded at EnergyADE Stuttgart workshop 2019-10-24 we see the need to remove the existing energy source modeling schema before proceeding to the Energy ADE 2.0.
There are many reasons for this, see the slides prese...Dear colleagues,
As concluded at EnergyADE Stuttgart workshop 2019-10-24 we see the need to remove the existing energy source modeling schema before proceeding to the Energy ADE 2.0.
There are many reasons for this, see the slides presented by Joachim at the workshop for more details. Most importantly there are currently no users that have implemented an energy source with the Energy ADE and we (KIT) believe that a new schema, that makes implicit rather than explicit descriptions is required.
A short example is: in a house, we have a gas boiler, a heater and a heating network, implicitly they belong to the same network. This would replace the existing explicit description which we find to be too detailed in the current scope of the ADE (modeling districts, not a single house).
As a conclusion, we will remove it from version 2.0 (which will include all the issue changes) and will work on making a better version to include this in 2.1.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/44building Physics Description / construction type2016-07-05T23:05:11+02:00Moritz Robert Lausterbuilding Physics Description / construction type*Created by: RomainNouvel*
Some information about the building contruction type could be useful, for instance to assess the materials of a buildings (information about building type and year of construction is sometimes not enough).
A...*Created by: RomainNouvel*
Some information about the building contruction type could be useful, for instance to assess the materials of a buildings (information about building type and year of construction is sometimes not enough).
A attribute called "buildingPhysicsDescription" or "constructionType" (the "constructionStyle" of the version 0.5 doesn't look like a reference name) should be precisely defined and maybe set as a hierarchical CodeList.
(Some information about building construction type: http://www.wikihow.com/Determine-a-Building%27s-Construction-Type)
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/115Use of CodeLists in Occupancy Module2016-07-01T09:31:39+02:00Moritz Robert LausterUse of CodeLists in Occupancy Module*Created by: RomainNouvel*
The codelists OccupantType, OwnershipType, ResidenceType, HouseholdType may have some standardized equivalent in the INSPIRE directive. It would be interesting to reuse these standardised values, if adapted.
O...*Created by: RomainNouvel*
The codelists OccupantType, OwnershipType, ResidenceType, HouseholdType may have some standardized equivalent in the INSPIRE directive. It would be interesting to reuse these standardised values, if adapted.
OccupantType : http://hub.geosmartcity.eu/registry/codelist/OccupantTypeValue/
OwnershipType : http://hub.geosmartcity.eu/registry/codelist/OwnershipTypeValue/
ResidenceType and HouseholdType could be later added in the registry
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/34Hierarchy and changes within the "OwnershipType" codeList2015-11-27T11:41:35+01:00Moritz Robert LausterHierarchy and changes within the "OwnershipType" codeList*Created by: bahujean*
- Label codeList -
1- **Rename "Governement" within the "OwnershipType" codeList into "Public"**
2- **Is it possible to insert hierarchical relations within a codeList?**
It could indeed then be possible to in...*Created by: bahujean*
- Label codeList -
1- **Rename "Governement" within the "OwnershipType" codeList into "Public"**
2- **Is it possible to insert hierarchical relations within a codeList?**
It could indeed then be possible to insert more detailed code List and insert hierarchy between them, such as in the inspire codeLists:
(http://inspire.ec.europa.eu/codelist/CurrentUseValue/)
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/102Line-wrapping on guidelines2017-11-27T09:06:45+01:00Moritz Robert LausterLine-wrapping on guidelines*Created by: emunozh*
Please use hard line-wrapping on guidelines markdown file. See http://www.cirosantilli.com/markdown-style-guide/#line-wrapping for a nice explanation on why should we use hard line-wrapping within a git repository.
*Created by: emunozh*
Please use hard line-wrapping on guidelines markdown file. See http://www.cirosantilli.com/markdown-style-guide/#line-wrapping for a nice explanation on why should we use hard line-wrapping within a git repository.
backloghttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/11ADEElement _BoundarySurface2015-03-02T22:28:19+01:00Moritz Robert LausterADEElement _BoundarySurface*Created by: oliviertournaire*
In the current model, an abstract class `_BoudarySurface` with the stereotype `ADEElement` exists. It derives from `Building:AbstractBoundarySurface`.
Some clarification are required:
1. If we want to cre...*Created by: oliviertournaire*
In the current model, an abstract class `_BoudarySurface` with the stereotype `ADEElement` exists. It derives from `Building:AbstractBoundarySurface`.
Some clarification are required:
1. If we want to create a class (i.e. a type) in the ADE which derives from `Building:AbstractBoundarySurface`, it should be done in another way (see image below)
2. The name of the derived class, if it has the stereotype `ADEElement` must have the **same name as its base class** (i.e. `AbstractBoundarySurface`)
![ade1](https://cloud.githubusercontent.com/assets/1990302/6414473/01d57a3a-be98-11e4-9823-8c4382c6d9b0.png)
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/82InternalGains / HeatDissipation2016-06-29T22:37:24+02:00Moritz Robert LausterInternalGains / HeatDissipation*Created by: RomainNouvel*
In the Energy ADE 0.6, we have the parameters "internalGains" in the UsageZone class, and the parameters "heatDissipation" in the Occupants and Facilities classes. These parameters are related, internalGains b...*Created by: RomainNouvel*
In the Energy ADE 0.6, we have the parameters "internalGains" in the UsageZone class, and the parameters "heatDissipation" in the Occupants and Facilities classes. These parameters are related, internalGains beeing the sum of the different heatDissipation inside the usage zone. Without definition clarifications, they look redundant. Actually, the aim of internalGains is to provide the average aggregated heat gains dissipated by occupants and facilities inside the usage zone, in the case that these ones are not known in detailed.
Proposition:
- We should therefore rename explicitly the "internalGains" in "averageInternalGains" (unit: W or W/m2)
and clarify the definitions of heatDissipation and averageInternalGains:
- heatDissipation -> Definition: heat energy dissipated by the occupants, respectively facilities, in "nominal conditions", it means when all occupants are present, respectively the facilities are fully operating. The constant totalValue of heatDissipation is weighted by the occupancyRate, respectively the operationSchedule, to obtain the heat dissipation temporal variation.
- averageInternalGains -> Definition: aggregated average heat energy dissipated by the occupants and facilities in a usage zone over the whole year.
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/116<some stupid issue2016-05-30T14:07:39+02:00Moritz Robert Lauster<some stupid issue*Created by: gioagu*
vnbjsköhösgk
*Created by: gioagu*
vnbjsköhösgk
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/25Version value2016-01-14T14:05:27+01:00Moritz Robert LausterVersion value*Created by: oliviertournaire*
I am just wondering which version to use in the namespace and codelists: the version of the ADE (`x.y.z`), or the CityGML version to which the ADE complies (i.e `2.0`)
*Created by: oliviertournaire*
I am just wondering which version to use in the namespace and codelists: the version of the ADE (`x.y.z`), or the CityGML version to which the ADE complies (i.e `2.0`)
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/29Concrete types EnergyConversionSystem and EnergyDistributionSystem?2015-10-23T13:33:16+02:00Moritz Robert LausterConcrete types EnergyConversionSystem and EnergyDistributionSystem?*Created by: 900k*
Shouldn't the types EnergyConversionSystem and EnergyDistributionSystem be abstract?
*Created by: 900k*
Shouldn't the types EnergyConversionSystem and EnergyDistributionSystem be abstract?
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/62Test issue2015-11-30T11:32:26+01:00Moritz Robert LausterTest issue*Created by: oliviertournaire*
**Describe issue**
*Created by: oliviertournaire*
**Describe issue**
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/22TimeValuesProperties incorrect uom attribute type2015-03-03T00:14:53+01:00Moritz Robert LausterTimeValuesProperties incorrect uom attribute type*Created by: oliviertournaire*
Attribute should be `MeasureType` instead of `Measure`
*Created by: oliviertournaire*
Attribute should be `MeasureType` instead of `Measure`
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/1Add a license file2015-02-18T23:20:08+01:00Moritz Robert LausterAdd a license file*Created by: oliviertournaire*
Is it necessary? CityGML does not provide any license file
*Created by: oliviertournaire*
Is it necessary? CityGML does not provide any license file
v0.4.3https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/3Create references via xlinks2015-02-02T12:06:11+01:00Moritz Robert LausterCreate references via xlinks*Created by: oliviertournaire*
It seems that it is not possible to create references to existing elements via xlinks. Need to be fixed for first release
*Created by: oliviertournaire*
It seems that it is not possible to create references to existing elements via xlinks. Need to be fixed for first release
v0.4.3https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/15Split diagram2016-01-14T14:05:39+01:00Moritz Robert LausterSplit diagram*Created by: oliviertournaire*
The diagram is pretty big and thus should be divided in several parts:
- Occupancy
- Material
- Energy systems
- Core
- ...
*Created by: oliviertournaire*
The diagram is pretty big and thus should be divided in several parts:
- Occupancy
- Material
- Energy systems
- Core
- ...
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/5Glazing featureType bad inheritance2015-03-03T00:51:28+01:00Moritz Robert LausterGlazing featureType bad inheritance*Created by: oliviertournaire*
From Romain Nouvel:
"The featureType Glazing (which may have several glazes and gas gapes) is actually not a "Material" but a 'LayerComponent'. Then, it should not inherit from 'AbstractMaterial' but from ...*Created by: oliviertournaire*
From Romain Nouvel:
"The featureType Glazing (which may have several glazes and gas gapes) is actually not a "Material" but a 'LayerComponent'. Then, it should not inherit from 'AbstractMaterial' but from 'LayerComponent'. Following that, the 'OpaqueMaterial' object should be renamed as 'SolidMaterial' (with the same parameters, at less for the first release)."
v0.4.3https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/8The codeSpace attribute in code lists is 1.02015-03-02T22:44:22+01:00Moritz Robert LausterThe codeSpace attribute in code lists is 1.0*Created by: 900k*
The codelists still refere to codeSpace 1.0. Please ensure that the current version is injected in the codelists.
*Created by: 900k*
The codelists still refere to codeSpace 1.0. Please ensure that the current version is injected in the codelists.
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/19Glazing should derive from AbstractMaterial and not LayerComponent2015-03-02T22:50:21+01:00Moritz Robert LausterGlazing should derive from AbstractMaterial and not LayerComponent*Created by: oliviertournaire*
*Created by: oliviertournaire*
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/77Redefine the "volume" attribute in _AbstractBuilding and ThermalZone2016-06-29T23:01:00+02:00Moritz Robert LausterRedefine the "volume" attribute in _AbstractBuilding and ThermalZone*Created by: gioagu*
Some thought ideas for the next version 0.7
This is a sort of extension of the floorArea idea (issue #47), but with regards to volume. Some ideas were collected also in Issue #55
Currently, we only have two attrib...*Created by: gioagu*
Some thought ideas for the next version 0.7
This is a sort of extension of the floorArea idea (issue #47), but with regards to volume. Some ideas were collected also in Issue #55
Currently, we only have two attributes: grossVolume, and netVolume (which is only in ThermalZone).
In reality, we may define several types of volume, such as:
netVolume,
grossVolume,
heatedVolume,
cooledVolume,
ventilatedVolume, etc.
We might even go further, especially when we derive volume from heterogeneous models, such as
lod1Volume,
lod2Volume,
lod3Volume.
Finally, we may think that you can cross these two lists and have something like:
lod2NetVolume,
lod2GrossVolume,
lod2VentilatedVolume, etc.
(looks weird, but it's for understanding)
So, my idea is to reshape the volume attribute in a similar way to the floorArea.
The attribute could be like:
volume: Volume_new [0..n]
<<DataType>> Volume_new having
volume: Volume
volumeType: VolumeType
<<CodeList>> VolumeType
lod2NetVolume,
lod2GrossVolume,
lod2VentilatedVolume,
(or something else, it is an example).
In anycase, I would keep the codelist (and no enumeration) so that we can play around at the beginning. What is more, there are here for sure some issues with the names (Volume), but somebody may help to avoid homonimous objects - here I am not the expert.
What is more, there could be some hints from other standards about naming...
What do you think?
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/6Add 'constructionOrientation' name to association between '<<ADEElement>> _Ci...2015-02-02T12:04:00+01:00Moritz Robert LausterAdd 'constructionOrientation' name to association between '<<ADEElement>> _CityObject' and 'ConstructionOrientation'*Created by: oliviertournaire*
From Marcel Bruse:
"I'm not able to create a construction or constructionOrientation underneath a roof surface (I suppose it doesn't work for any BoundarySurface). Please check if it works for buildings an...*Created by: oliviertournaire*
From Marcel Bruse:
"I'm not able to create a construction or constructionOrientation underneath a roof surface (I suppose it doesn't work for any BoundarySurface). Please check if it works for buildings and buildings parts, too."
v0.4.3https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/7Check cardinalities2015-02-05T13:40:34+01:00Moritz Robert LausterCheck cardinalities*Created by: oliviertournaire*
It seems that cardinalities on relationships are not well handled when converting from UML to XSD. They thus need to be checked carefully.
*Created by: oliviertournaire*
It seems that cardinalities on relationships are not well handled when converting from UML to XSD. They thus need to be checked carefully.
v0.4.3https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/10Usage of temporal data types2015-03-02T22:48:47+01:00Moritz Robert LausterUsage of temporal data types*Created by: oliviertournaire*
[Thanks to Joachim Benner for reporting this issue]
The UML model uses a lot of types for time instances (TM_ClockTime, TimePositionType) and time periods (TimePeriod, TimeIntervalLengthType). Some of them...*Created by: oliviertournaire*
[Thanks to Joachim Benner for reporting this issue]
The UML model uses a lot of types for time instances (TM_ClockTime, TimePositionType) and time periods (TimePeriod, TimeIntervalLengthType). Some of them may not be recognized by ShapeChange. We thus have to ensure that in the generated XSD schema, attributes using these types are correctly defined. The while model has to be checked.
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/76Add attribute "EnergyPerformanceCertification" also in class BuildingUnit2016-07-01T10:00:49+02:00Moritz Robert LausterAdd attribute "EnergyPerformanceCertification" also in class BuildingUnit*Created by: gioagu*
Some comments/thought collected so far for release 0.7
Giorgio: The attribute “EnergyPerformanceCertification” should be added to the “Building_Unit” class as well. You can have EPC for the whole building, or for j...*Created by: gioagu*
Some comments/thought collected so far for release 0.7
Giorgio: The attribute “EnergyPerformanceCertification” should be added to the “Building_Unit” class as well. You can have EPC for the whole building, or for just a single unit. I remember we talked briefly about this in Munich, but somehow it got lost (I forgot it too…).
Romain: That’s right. -> 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/49EnergySupply, Energy carrier, Energy source2016-01-14T13:53:20+01:00Moritz Robert LausterEnergySupply, Energy carrier, Energy source*Created by: RomainNouvel*
1- In our EnergyADE version 0.5, the feature "EnergySource" can be a Primary our Secondary Energy Source, renewable or not. It is therefore not systematically an energy carrier ("energy form which has been tra...*Created by: RomainNouvel*
1- In our EnergyADE version 0.5, the feature "EnergySource" can be a Primary our Secondary Energy Source, renewable or not. It is therefore not systematically an energy carrier ("energy form which has been transformed from primary energy sources, such as electricity"), like in the case of Solar Energy.
Beside, some energy carrier (hot water, chilled air etc.) related to EnergySupply does not have related CO2 emission factor, primary energy factor etc...
We should therefore rethink our EnergySupply, EnergySource and EnergyCarrier structures, contents and wordings...
2- Other issue: how do we model the (PV) electrical production feeding the grid? Should we only add an EndUseType "GridFeedIn"?
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/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/100XML example code on guidelines, code lines too wide2016-04-14T12:00:30+02:00Moritz Robert LausterXML example code on guidelines, code lines too wide*Created by: emunozh*
Many code lines on XML example code on guidelines are too wide for the rendered [pdf](https://github.com/emunozh/citygml-energy/blob/master/doc/guidelines/Guidelines_EnergyADE.pdf)
Here is a list of the lines with...*Created by: emunozh*
Many code lines on XML example code on guidelines are too wide for the rendered [pdf](https://github.com/emunozh/citygml-energy/blob/master/doc/guidelines/Guidelines_EnergyADE.pdf)
Here is a list of the lines with problems (cd: code line, pdf: page number on the pdf file):
- [ ] cd: 92:138 - pdf: p.8 gioagu@ea5eaf ; RomainNouvel@18697cd
- [ ] cd: 204:217 - pdf: p.11 JoachimBenner@6471fc5
- [ ] cd: 219:236 - pdf: p.11 JoachimBenner@6471fc5
- [ ] cd: 238:250 - pdf: p.11 JoachimBenner@6471fc5
- [ ] cd: 272:306 - pdf: p.12 gioagu@b123393
- [ ] cd: 337:358 - pdf: p.14 gioagu@3bee121
- [ ] cd: 399:435 - pdf: p.15 gioagu@03aa537; RomainNouvel@ae20fd2
- [ ] cd: 438:471 - pdf: p.16 gioagu@03aa537
- [ ] cd: 521:542 - pdf: p.19 RomainNouvel@d777ed2 ; gioagu@03aa537
- [ ] cd: 544:565 - pdf: p.19 RomainNouvel@d777ed2 ; gioagu@03aa537
- [ ] cd: 624:644 - pdf: p.22 gioagu@1275498 ; gioagu@3bee121 ; gioagu@f873542
- [ ] cd: 646:658 - pdf: p.22 gioagu@1275498 ; gioagu@3bee121 ; gioagu@f873542
- [ ] cd: 660:677 - pdf: p.23 gioagu@1275498 ; gioagu@3bee121 ; gioagu@f873542
- [ ] cd: 730:751 - pdf: p.25 gioagu@3bee121 ; gioagu@74738ef ; gioagu@f873542
- [ ] cd: 753:791 - pdf: p.25 gioagu@3bee121 ; gioagu@74738ef ; gioagu@f873542
- [ ] cd: 797:811 - pdf: p.26 gioagu@3bee121 ; gioagu@74738ef
- [ ] cd: 907:915 - pdf: p.31 gioagu@1275498
- [ ] cd: 938:987 - pdf: p.31 JoachimBenner@6471fc5
- [ ] cd: 1034:1089 - pdf: p.35 gioagu@03aa537; gioagu@3bee121
- [ ] cd: 1140:1176 - pdf: p.38 gioagu@1275498
- [ ] cd: 1206:1230 - pdf: p.39 gioagu@1275498 ; gioagu@64edc87
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/57Contruction and material names2016-01-14T13:52:09+01:00Moritz Robert LausterContruction and material names*Created by: RomainNouvel*
Presently, for the identification and management of the Construction objects, no name / description exist.
- it would be useful to add an attribute name[CharacterString].
for instance: "28cm brick wall".
Co...*Created by: RomainNouvel*
Presently, for the identification and management of the Construction objects, no name / description exist.
- it would be useful to add an attribute name[CharacterString].
for instance: "28cm brick wall".
Concerning the Material, What contains precisely the attribute referenceURI? Can we get the material name through it? or it is just an reference id?
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/111Missing EnergyCarrierTypeValues value for geothermal energy2016-06-29T20:55:10+02:00Moritz Robert LausterMissing EnergyCarrierTypeValues value for geothermal energy*Created by: mlauster*
For heat pumps, it is necessary to have geothermal energy as EnergyCarrierTypeValue. I propose to add `GeothemalEnergy`
*Created by: mlauster*
For heat pumps, it is necessary to have geothermal energy as EnergyCarrierTypeValue. I propose to add `GeothemalEnergy`
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/2Update README.md2015-03-12T13:53:17+01:00Moritz Robert LausterUpdate README.md*Created by: oliviertournaire*
The current README.md file is incomplete
- Add authors
- Add description
*Created by: oliviertournaire*
The current README.md file is incomplete
- Add authors
- Add description
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/4Missing "boundedBy" role in ThermalZoneType2015-02-02T12:05:25+01:00Moritz Robert LausterMissing "boundedBy" role in ThermalZoneType*Created by: oliviertournaire*
From Marcel Bruse:
"I cannot create ThermalBoundarySurfaces underneath ThermalZones. The "boundedBy" role is missing in ThermalZoneType."
*Created by: oliviertournaire*
From Marcel Bruse:
"I cannot create ThermalBoundarySurfaces underneath ThermalZones. The "boundedBy" role is missing in ThermalZoneType."
v0.4.3https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/9Missing attributes type2015-03-02T22:48:26+01:00Moritz Robert LausterMissing attributes type*Created by: oliviertournaire*
[Thanks to Joachim Benner for reporting this issue]
Some attributes have no type. This is due to a bad specification in the UML model. Can be fixed by correcting types in the UML model and / or by setting ...*Created by: oliviertournaire*
[Thanks to Joachim Benner for reporting this issue]
Some attributes have no type. This is due to a bad specification in the UML model. Can be fixed by correcting types in the UML model and / or by setting proper conversion rules in ShapeChange configuration files.
Here is a list (might not be exhaustive) of the types that have to be changed:
- MeasureType --> Measure
- LengthType --> Length
- AreaType --> Area
- VolumeType --> Volume
- boolean --> Boolean
- Int --> Integer
- ScaleType --> Scale
- UomIdentifier --> Measure
- AngleType --> Angle
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/12ADEElement _Opening2015-03-02T22:27:59+01:00Moritz Robert LausterADEElement _Opening*Created by: oliviertournaire*
In the current model, an abstract class `_Opening` with the stereotype `ADEElement` exists. It derives from `Building:AbstractOpening`.
Some clarification are required:
1. If we want to create a class (i....*Created by: oliviertournaire*
In the current model, an abstract class `_Opening` with the stereotype `ADEElement` exists. It derives from `Building:AbstractOpening`.
Some clarification are required:
1. If we want to create a class (i.e. a type) in the ADE which derives from `Building:AbstractOpening`, it should be done in another way (see image below)
2. The name of the derived class, if it has the stereotype `ADEElement` must have the **same name as its base class** (i.e. `AbstractOpening`)
![ade1](https://cloud.githubusercontent.com/assets/1990302/6414473/01d57a3a-be98-11e4-9823-8c4382c6d9b0.png)
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/13Why an ADEElement _CityObject is defined2015-03-02T22:21:09+01:00Moritz Robert LausterWhy an ADEElement _CityObject is defined*Created by: oliviertournaire*
I was wondering why we have defined a `_CityObject ADEElement` in the UML model. Why do not we use directly the `core:AbstractCityObject`? Can you explain?
Note that is issue is related to issues #11 and ...*Created by: oliviertournaire*
I was wondering why we have defined a `_CityObject ADEElement` in the UML model. Why do not we use directly the `core:AbstractCityObject`? Can you explain?
Note that is issue is related to issues #11 and #12
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/14Cardinalities missing for Construction and ConstructionOrientation2015-03-03T00:51:28+01:00Moritz Robert LausterCardinalities missing for Construction and ConstructionOrientation*Created by: oliviertournaire*
*Created by: oliviertournaire*
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/16Use correct CityGML class names2015-03-02T22:46:03+01:00Moritz Robert LausterUse correct CityGML class names*Created by: oliviertournaire*
Some classes do not have a correct name. For instance `AbstractBuilding` should be `_AbstractBuilding`.
The easiest way is to change names of classes used in the model to their correct version.
*Created by: oliviertournaire*
Some classes do not have a correct name. For instance `AbstractBuilding` should be `_AbstractBuilding`.
The easiest way is to change names of classes used in the model to their correct version.
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/17HouseholdType Codelist is not used2015-03-03T00:51:27+01:00Moritz Robert LausterHouseholdType Codelist is not used*Created by: oliviertournaire*
What to do:
- Remove the Codelist
- Use it in `featureType Household`
*Created by: oliviertournaire*
What to do:
- Remove the Codelist
- Use it in `featureType Household`
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/18Fix association from ScheduleLoD2 to DailySchedule2015-03-03T00:52:02+01:00Moritz Robert LausterFix association from ScheduleLoD2 to DailySchedule*Created by: oliviertournaire*
See image below
![attendeeviewerimage000](https://cloud.githubusercontent.com/assets/1990302/6437941/b23538ec-c0c4-11e4-88c7-c3c608ec9afc.png)
*Created by: oliviertournaire*
See image below
![attendeeviewerimage000](https://cloud.githubusercontent.com/assets/1990302/6437941/b23538ec-c0c4-11e4-88c7-c3c608ec9afc.png)
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/20Fix relation between _BoundarySurface and _SolarEnergySystem2015-03-03T12:50:51+01:00Moritz Robert LausterFix relation between _BoundarySurface and _SolarEnergySystem*Created by: oliviertournaire*
`_SolarEnergySystem` should be linked to `Building:_BoundarySurface`
![attendeeviewerimage001](https://cloud.githubusercontent.com/assets/1990302/6438308/2bf2fbbc-c0c8-11e4-95b3-6c1c2e8d1878.png)
*Created by: oliviertournaire*
`_SolarEnergySystem` should be linked to `Building:_BoundarySurface`
![attendeeviewerimage001](https://cloud.githubusercontent.com/assets/1990302/6438308/2bf2fbbc-c0c8-11e4-95b3-6c1c2e8d1878.png)
0.5.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/21Repair Materials ADE2015-03-02T22:23:57+01:00Moritz Robert LausterRepair Materials ADE*Created by: 900k*
Hi Olivier,
could you please change back some modifications of the Materials ADE which Romain introduced lately? Currently, the "Glazing" is a subclass of "LayerComponent", but it should be a subclass of "AbstractMat...*Created by: 900k*
Hi Olivier,
could you please change back some modifications of the Materials ADE which Romain introduced lately? Currently, the "Glazing" is a subclass of "LayerComponent", but it should be a subclass of "AbstractMaterial". Additionally, please change the class name of "SolidMaterial" back to "OpaqueMaterial".
Thank you very much!
0.5.0https://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/109Missing Type of ThermalBoundary2016-06-29T21:11:26+02:00Moritz Robert LausterMissing Type of ThermalBoundary*Created by: gioagu*
As of now (v. 0.6), a there is a "IntermediaryFloor" type.
However, "IntermediaryCeiling" is missing.
The distinction is needed when, for example, modelling each ThermalZone explicitly by means of surfaceGeometry....*Created by: gioagu*
As of now (v. 0.6), a there is a "IntermediaryFloor" type.
However, "IntermediaryCeiling" is missing.
The distinction is needed when, for example, modelling each ThermalZone explicitly by means of surfaceGeometry.
I would add it to the enumeration list for v. 0.7
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/42new Class RefurbishmentMeasures2016-06-29T22:47:25+02:00Moritz Robert Lausternew Class RefurbishmentMeasures*Created by: RomainNouvel*
In the Energy ADE version 0.5, information concerning possible refurbishment measures are integrated inside the _AbstractBuilding Class as two attributes: yearOfRefurbishment[Year] and refurbishmentClass[Chara...*Created by: RomainNouvel*
In the Energy ADE version 0.5, information concerning possible refurbishment measures are integrated inside the _AbstractBuilding Class as two attributes: yearOfRefurbishment[Year] and refurbishmentClass[CharacterString].
The present structure does not allow to have partial RefurbishmentMeasures (e.g. only for a wall, a window or a energy system), nor several RefurbishmentMeasures for one building. Moreover, yearOfRefurbishment might be too precise, and refurbishmentClass as CharacterString is not usable in software/libraries
PROPOSITIONS:
- Create a FeatureType RefurbishmentMeasures containing the attributes DateOfRefurbishment[Date] and LevelOfRefurbishment[CodeList], which could be associate with a Cardinality [1 , 0..*] to _AbstractBuilding, _BoundarySurface, _Opening and EnergyConversionSystem for instance (any CityObject?).
- The attribute LevelOfRefurbishment could be a hierarchical multi-lingual CodeList (use Re3gistry developed by jrc), referring for instance to the Refurbishment variants "Standard" and "Advanced" defined in the European Projekt Tabula, or to any other local refurbishment variant, provided that it is defined somewehere (in a library or a document, whose reference should be indicated with the LevelOfRefurbishment)
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/112Delete relations isConsumedBy and isProcudecBy2016-06-29T22:58:06+02:00Moritz Robert LausterDelete relations isConsumedBy and isProcudecBy*Created by: mlauster*
Purpose is to link from `EnergySource` to `EnergyConversionSystem`, but is there a real use case where somebody uses this way instead of linking from an `EnergyConversionSystem` to an `EnergySource` using `consume...*Created by: mlauster*
Purpose is to link from `EnergySource` to `EnergyConversionSystem`, but is there a real use case where somebody uses this way instead of linking from an `EnergyConversionSystem` to an `EnergySource` using `consumes` and `produces`?
If not, I vote for deleting them.
v0.7.0https://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/75Name/Rename of attribute usageZoneClass2016-07-01T09:59:36+02:00Moritz Robert LausterName/Rename of attribute usageZoneClass*Created by: gioagu*
Some comments/thought collected so far to be considered for version 0.7
Giorgio: I would rename the attribute “usageZoneClass” to “usageZoneType”. We are defining the type of usage zone. We should stay coherent to ...*Created by: gioagu*
Some comments/thought collected so far to be considered for version 0.7
Giorgio: I would rename the attribute “usageZoneClass” to “usageZoneType”. We are defining the type of usage zone. We should stay coherent to BuildingType, OccupantsType, atticType, etc.
Joachim: I am not sure about this. usageZoneClass uses the general CityGML Codelist BuildingClass, and this Codelist is used by the attribute class in the CityGML feature _AbstractBuilding. Thus, the actual naming is consistent with CityGML. However, I am not sure whether BuildingClass is really a good choice for the classification of UsageZones. In CityGML, a building may have an unique “classification of it’s actual usage”, which is expressed by the class attribute. Therefore, different UsageZones formally cannot have different usageZoneClass values.
I propose to leave this problem for ADE version 0.7.
v0.7.0