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/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/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/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/108Cardinality of relation "energyDistribution"2016-06-29T21:20:04+02:00Moritz Robert LausterCardinality of relation "energyDistribution"*Created by: RomainNouvel*
In the version 0.6 of the Energy ADE, an EnergyDemand may have several EnergyDistributionSystem, because of the cardinality 0..\* of the relation "energyDistribution". Is that possible? Will that be useful / u...*Created by: RomainNouvel*
In the version 0.6 of the Energy ADE, an EnergyDemand may have several EnergyDistributionSystem, because of the cardinality 0..\* of the relation "energyDistribution". Is that possible? Will that be useful / useable in urban energy modelling?
I will suggest to fix a maximum of 1 EnergyDistributionSystem per EnergyDemand -> Cardinality of relation energyDistribution : 0..1.
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/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/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/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/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/137Classification of Emitter in EnergySystem module2017-11-27T09:26:14+01:00Moritz Robert LausterClassification of Emitter in EnergySystem module*Created by: gioagu*
In a first attempt to reorganise hierarchically most of the entities in the Energy System module, the classification of Emitter is somehow unclear. We have so far three "big families" of classes: Conversion, Storage...*Created by: gioagu*
In a first attempt to reorganise hierarchically most of the entities in the Energy System module, the classification of Emitter is somehow unclear. We have so far three "big families" of classes: Conversion, Storage and Distribution. The emitter is however alone and only connected to a Distribution class.
I was wondering, together with Joachim and Romain, whether there could be a way to characterise it a bit better. On one side, it is delivering energy to satisfy an energy demand, but it is not connected to it. On the other side, is it really a device which distributes energy (e.g. heat?), or just the end node of a distribution system?
The general idea is to define a general abstract class _EnergySystem which generalises all Conversion, Distribution and Storage Systems. An UML diagramme, and a new ticket, will be ready issued soon (thx Joachim!).
Dear members of the Energy System team, could you please help?
Thank you for your help!
ghttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/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/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/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/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/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/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/92Double Relation EnergyConversionSystem <-> _AbstractBuilding2016-06-29T22:43:51+02:00Moritz Robert LausterDouble Relation EnergyConversionSystem <-> _AbstractBuilding*Created by: RomainNouvel*
in the version Energy ADE 0.6: 2 relations exist to link EnergyConversionSystem and _AbstractBuilding:
1- "has" goes from _AbstractBuilding to EnergyConversionSystem.
2- 'installedIn" goes from _EnergyConversi...*Created by: RomainNouvel*
in the version Energy ADE 0.6: 2 relations exist to link EnergyConversionSystem and _AbstractBuilding:
1- "has" goes from _AbstractBuilding to EnergyConversionSystem.
2- 'installedIn" goes from _EnergyConversionSystem
This loop isn't very pretty/practical for modellers
I wonder why the second relation is useful. Couldn't we delete "installedIn"?
"has" is a pretty general term. Couldn't we use "equippedWith" instead?
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/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/129Emitters2017-05-29T14:06:49+02:00Moritz Robert LausterEmitters*Created by: RomainNouvel*
Emitters (also called end use unit or zoning system) have been modelled in an earlier version of the Energy ADE (0.4.3) before to be removed for simplification purpose.
They mainly relate to the end use types...*Created by: RomainNouvel*
Emitters (also called end use unit or zoning system) have been modelled in an earlier version of the Energy ADE (0.4.3) before to be removed for simplification purpose.
They mainly relate to the end use types SpaceHeating, SpaceCooling and Ventilation.
It could be interested to integrate them again in the schema, either directly connected to the EnergyDemand object or as attribute of the DistributionSystem.
Emitters could be an object with as attributes: emitter type (radiators ect.), heatExchangeType, installed power, number etc...https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/81EnergyCarrierTypeValues - need Fernwaerme2016-02-17T14:09:50+01:00Moritz Robert LausterEnergyCarrierTypeValues - need Fernwaerme*Created by: anetefr*
If in real data there is energy source fernwärme, there is no place where to properly map it in enumeration EnergyCarrierTypeValues.
I image that fernwärma will appear quite often in data. It could be added to enu...*Created by: anetefr*
If in real data there is energy source fernwärme, there is no place where to properly map it in enumeration EnergyCarrierTypeValues.
I image that fernwärma will appear quite often in data. It could be added to enumeration.
However, then mandatory nature of "co2EmssionFactor" and "primaryEnergyFactor" might arise problems then.
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/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.