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/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/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/110Integrate Parameters for LCA - phase construction/refurbishment2016-07-01T11:41:03+02:00Moritz Robert LausterIntegrate Parameters for LCA - phase construction/refurbishment*Created by: RomainNouvel*
Up to know, we've only considered the primary energy and CO2 emissions for the operational phase of the building. More and more urban analyses consider also the "grey energy" and the "embodied carbon" to take ...*Created by: RomainNouvel*
Up to know, we've only considered the primary energy and CO2 emissions for the operational phase of the building. More and more urban analyses consider also the "grey energy" and the "embodied carbon" to take some decision.
Here is a proposal discussed with Alessio, to integrate (step by step) the construction/refurbishment phase in our Energy ADE:
In the Construction Module:
- introduction of the new attribute EmbodiedCarbon in the class "SolidMaterial" : optional, measureType (generally kgCO2/m3 or kgCO2/kg), definition : CO2 equivalent emissions caused by the fabrication and transportation on site of the material.
- introduction of the new attribute EmbodiedEnergy in the class "SolidMaterial" : optional, measureType (generally J/m3 or J/kg), definition : Primary energy consumed for the fabrication and transportation on site of the material.
- introduction of the new attribute LifeSpan in the class "Construction" : optional, TimePeriod type (or Time length), definition: Period of service life, including the construction/installation date and the expected end of life.
- introduction of the new attribute LifeSpan in the class "Layer" : optional, TimePeriod type (or Time length), definition: Period of service life, including the construction/installation date and the expected end of life.
In the Energy and System Module:
- introduction of the new attribute LifeSpan in the class "EnergyConversionSystem", "EnergyDistributionSystem" and "_StorageSystem" : optional, TimePeriod type (or Time length), definition: Period of service life, including the construction/installation date and the expected end of life.
v0.7.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/32Internal Gains management2015-11-27T11:41:03+01:00Moritz Robert LausterInternal Gains management*Created by: bahujean*
**-- Label Building occupants --**
**1-** Up to now, internal gains are attributes in the featureTypes:
- as "internGains" within the "occupancy" featureType
- as "heatLosses" within the "electricalAppliances" f...*Created by: bahujean*
**-- Label Building occupants --**
**1-** Up to now, internal gains are attributes in the featureTypes:
- as "internGains" within the "occupancy" featureType
- as "heatLosses" within the "electricalAppliances" featureType
They design the same effect and are at the same level. That's why it could be relevant to **rename both attributes "heatDissipation"**.
**2-** It could be also relevant to **insert an "internalGains" attribute within the "UsageZone" featureType**. User could then choose if he wants to directly use a simplified attribute or provide more detailed calculation for internal Gains.
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/35Labels by creating issues2015-11-10T22:48:51+01:00Moritz Robert LausterLabels by creating issues*Created by: bahujean*
-- label bug --
Be able to insert directly a label by creating an issue would be very useful.
*Created by: bahujean*
-- label bug --
Be able to insert directly a label by creating an issue would be very useful.
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/174Lack of "equippedWith" association for EnergySystems2021-06-17T15:59:51+02:00Giorgio AgugiaroLack of "equippedWith" association for EnergySystemsAlthough the Energy Systems module may need a major overhaul for the next version (or a drastic simplification?), I noticed that as of now an EnergySystem has a "installedIn" association, but we are missing a rather useful "equippedWith"...Although the Energy Systems module may need a major overhaul for the next version (or a drastic simplification?), I noticed that as of now an EnergySystem has a "installedIn" association, but we are missing a rather useful "equippedWith" association of a _CityObject to an EnergySystem. I fear, this has been "lost" in the process of moving from previous versions to v. 1.0... ;-)
As of now, EnergySystems are written as root elements with an Xlink to the _CityObject they are installed in. But it'd be more reasonable to have them as child elements of the _CityObject they are installed in (e.g. of a building).
Any thoughts?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/45Landmarked / Historical Buildings2016-01-14T13:54:24+01:00Moritz Robert LausterLandmarked / Historical Buildings*Created by: RomainNouvel*
Different status of landmarked/historical buildings exist in Europe with different degrees of protection.
Therefore, a simple landmarked[Boolean] as attribute of _AbstractBuilding should be not enough.
PROPOSI...*Created by: RomainNouvel*
Different status of landmarked/historical buildings exist in Europe with different degrees of protection.
Therefore, a simple landmarked[Boolean] as attribute of _AbstractBuilding should be not enough.
PROPOSITION:
- Use the Hierarchical/multi-lingual CodeList Re3gistry as developed by JRC to manage the different certification labels and degrees.
- Rename this attribute (culturalHeritageStatus?)
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/98LevelOfRefurbishment -> codeList2016-06-29T22:22:17+02:00Moritz Robert LausterLevelOfRefurbishment -> codeList*Created by: RomainNouvel*
I think we agreed last meeting in Munich to set the LevelOfRefurbishment as a codeList (extendable) rather than a enumeration, so that anybody may extend this list, depending on the case study and its building...*Created by: RomainNouvel*
I think we agreed last meeting in Munich to set the LevelOfRefurbishment as a codeList (extendable) rather than a enumeration, so that anybody may extend this list, depending on the case study and its building libraries.
Do you confirm?
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/31Lighting in Building2016-01-14T13:55:43+01:00Moritz Robert LausterLighting in Building*Created by: RomainNouvel*
Up to now, the building model do not integrate specific attributes for lighting.
- Luminance Threshold (Lux) could be included in UsageZone for instance...
- LightingFacilities/Systems could be specificied suc...*Created by: RomainNouvel*
Up to now, the building model do not integrate specific attributes for lighting.
- Luminance Threshold (Lux) could be included in UsageZone for instance...
- LightingFacilities/Systems could be specificied such as DHWFacilities...
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/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/85Little BUG in Energy ADE 0.6 due to typo2016-06-29T20:37:01+02:00Moritz Robert LausterLittle BUG in Energy ADE 0.6 due to typo*Created by: gioagu*
In the relation between Occupants and Households, there is a typo (both in the xsd and in the UML diagram) which reads:
consiststOf
Please note the double "st", which is an involuntarily typo - but definitely hard...*Created by: gioagu*
In the relation between Occupants and Households, there is a typo (both in the xsd and in the UML diagram) which reads:
consiststOf
Please note the double "st", which is an involuntarily typo - but definitely hard to spot ;-)
I think this should be corrected in the 0.6 version, too.
v0.7.0https://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/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/118Mandatory relation between ThermalZone and ThermalBoundary?2017-11-27T09:09:22+01:00Moritz Robert LausterMandatory relation between ThermalZone and ThermalBoundary?*Created by: oliviertournaire*
I am wondering if the _boundedBy_ relation between `ThermalZone` and `ThermalBoundary` is really mandatory. The cardinality is set to `1..*`.
However, if one just want to model a building and attached the...*Created by: oliviertournaire*
I am wondering if the _boundedBy_ relation between `ThermalZone` and `ThermalBoundary` is really mandatory. The cardinality is set to `1..*`.
However, if one just want to model a building and attached the properties `isCooled` or `isHeated`, he has to define a `ThermalZone`. Sounds good. However, as long as you define a `ThermalZone`, you are obliged to also model a `ThermalBoundary`. I do not think this is really necessary.
Your opinions?
v0.8.0https://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/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/30Missing association between ThermalZone and UsageZone2015-11-24T11:49:38+01:00Moritz Robert LausterMissing association between ThermalZone and UsageZone*Created by: 900k*
There was once an association from ThermalZone to UsageZone [0..\* -> 0..*]. The role name was "relatesTo". It must have gone lost during the separation of the modules.
*Created by: 900k*
There was once an association from ThermalZone to UsageZone [0..\* -> 0..*]. The role name was "relatesTo". It must have gone lost during the separation of the modules.
v0.6.0https://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.0