citygml-energy issueshttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues2016-06-29T20:56:56+02:00https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/94Rename relations *usageZones* and *thermalZones*2016-06-29T20:56:56+02:00Moritz Robert LausterRename relations *usageZones* and *thermalZones**Created by: JoachimBenner*
In the CityGML standard as well as in the EnergyADE, most relation names are stated in singular. This has a good reason, because in the XML encoding the relation property either points to (via xlink:href) or ...*Created by: JoachimBenner*
In the CityGML standard as well as in the EnergyADE, most relation names are stated in singular. This has a good reason, because in the XML encoding the relation property either points to (via xlink:href) or imbeds exactly one related XML-element. Thus, the new relation _thermalZones_ (_AbstractBuilding --> ThermalZone) must be instanciated once for every ThermalZone of the building, and the plural usage in the relation name is misleading and inconsistant with the rest of the data model. The same situation occurs with the relation _usageZones_ (_AbstractBuilding --> UsageZone).
**Proposal:**
1. Rename _thermalZones_ --> _thermalZone_
2. Rename _usageZones_ --> _usageZone_
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/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/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/91_SolarEnergySystem2016-07-01T09:53:45+02:00Moritz Robert Lauster_SolarEnergySystem*Created by: RomainNouvel*
In the Energy ADE 0.6:
1. the SolarEnergySystem present only the geometrical information "collectorSurface", "panelAzimuth" and "panelInclination", and not a given geometrical surface.
2. Furthermore, it is li...*Created by: RomainNouvel*
In the Energy ADE 0.6:
1. the SolarEnergySystem present only the geometrical information "collectorSurface", "panelAzimuth" and "panelInclination", and not a given geometrical surface.
2. Furthermore, it is linked only to BoundarySurface with an optional double relations:
a) The "installedOn" relation from SolarEnergySystem to BoundarySurface is the mostly used case, where we want to calculate the photovoltaic electricity production of a given PV system, in particular to cover the electrical demand. This relation should be mandatory.
b) The "equippedWith" relation from BoundarySurface to SolarEnergySystem has been originally designed for Photovoltaic Potential study, where the SolarEnergySystem is a floating object not related to an EnergyDemand. This relation could be avoid if the SolarEnergySystem is related in a way with a Building (which is possible with the relation "has" from AbstractBuilding to EnergyConversionSystem.
3. The case of tilted PV panels on flat roof is not considered in our Schema (here, the SolarEnergySystem MUST be laid on a Roof/facade)
4. The attribute _area_ of SolarEnergySystem should be detailed (aperture area, module area, gross area?).
5. The present schema does not allow to integrate Hybrid PVT panels
**Propositions for Energy ADE 0.7:**
- It should be possible to relate SolarEnergySystem with a (outer) BuildingInstallation instead of a _BoundarySurface
- An optional attribute _surfaceGeometry_ , type GM_MultiSurface[0..1], would be required in the case that the solar panels do not correspond 1-to-1 to the BoundarySurface
- the attribute panelAzimuth and panelInclination are not necessary/relevant, from the moment that a relation exist between SolarEnergySystem and BoundarySurface, respectively BuildingInstallation (or if the optional attribute _surfaceGeometry_ is indicated).
- the relation "equippedWith" from BoundarySurface to SolarEnergySystem could be deleted.
- the relation "installedOn" from SolarEnergySystem to BoundarySurface, respectively BuildingInstallation, should have the cardinality 0..1 (if a Solar installation covers really several BoundarySurface, then it should be divided in several SolarEnergySystem).
- The SolarEnergySystem should be distinguished between "PhotovoltaicSystem" (with only attributes _moduleArea_ and _cellMaterialType_, since installedNominalPower (=peak power) and nominalEfficiency (=performance ratio) are already the attributes of EnergyConversionSystem), "SolarThermalSystem" (with attributes _apertureArea_, _eta0_, _a1_, _a2_ and _technologyType_) and "PhotovoltaicThermalSystem" (with all attributes of the two latters).
v0.7.0https://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/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/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/81EnergyCarrierTypeValues - need Fernwaerme2016-02-17T14:09:50+01:00Moritz Robert LausterEnergyCarrierTypeValues - need Fernwaerme*Created by: anetefr*
If in real data there is energy source fernwärme, there is no place where to properly map it in enumeration EnergyCarrierTypeValues.
I image that fernwärma will appear quite often in data. It could be added to enu...*Created by: anetefr*
If in real data there is energy source fernwärme, there is no place where to properly map it in enumeration EnergyCarrierTypeValues.
I image that fernwärma will appear quite often in data. It could be added to enumeration.
However, then mandatory nature of "co2EmssionFactor" and "primaryEnergyFactor" might arise problems then.
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/79Time series for weather / climate data2016-07-01T10:01:56+02:00Moritz Robert LausterTime series for weather / climate data*Created by: JoachimBenner*
Weater or climate data are important input data for energy simulations. In version 0.6.0 we can specify time series of global solar irradiance and daylight illumanance for Boundary Surfaces. But there are man...*Created by: JoachimBenner*
Weater or climate data are important input data for energy simulations. In version 0.6.0 we can specify time series of global solar irradiance and daylight illumanance for Boundary Surfaces. But there are many more relevant meteorological parameters like temperature, wind speed, relative humidity, .... Most of them must be connected to the building as a whole, as this is not possible in the actual version of the Energy ADE.
Thus, I propose to add the property **climateData: _TimeSeries[0..*]** as ADE attribute of _AbstractBuilding
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/78Images not resized in guidelines (PDF file)2016-01-15T16:33:24+01:00Moritz Robert LausterImages not resized in guidelines (PDF file)*Created by: oliviertournaire*
In the guidelines pdf file, images are not resized to fit page width. Thus, UML diagrams are cropped and not fully visible.
@mlauster can you take care of this?
*Created by: oliviertournaire*
In the guidelines pdf file, images are not resized to fit page width. Thus, UML diagrams are cropped and not fully visible.
@mlauster can you take care of this?
v0.6.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/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/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.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/74About attribute "atticType" in building2016-07-01T10:19:39+02:00Moritz Robert LausterAbout attribute "atticType" in building*Created by: gioagu*
Some comments for the next 0.7 version collected so far.
Giorgio: The attribute atticType (and the similar ones) could be renamed “atticConditioning”, as we describe just one property of the attic, not really the “...*Created by: gioagu*
Some comments for the next 0.7 version collected so far.
Giorgio: The attribute atticType (and the similar ones) could be renamed “atticConditioning”, as we describe just one property of the attic, not really the “type”. But it is just a just thought
Romain: Should be discussed. We should look for the official name in the ISO 13790 and similar norms… -> 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/73Name/Rename of "landmarked" attribute in class building2016-07-01T09:55:21+02:00Moritz Robert LausterName/Rename of "landmarked" attribute in class building*Created by: gioagu*
Some comments to consider for the 0.7 version
Giorgio: In class Building_ADE, given that it is boolean, we should rename the attribute to “isLandmark”, for consistence with other attributes (isSunExposed, etc.)
Ro...*Created by: gioagu*
Some comments to consider for the 0.7 version
Giorgio: In class Building_ADE, given that it is boolean, we should rename the attribute to “isLandmark”, for consistence with other attributes (isSunExposed, etc.)
Romain: We’ve decided that heritage and landmark building information would be not mentioned in the Energy ADE (but a proposition will be made to the CityGML 3.0 working group). As a consequence, this attribute should be deleted from the Energy ADE 0.6.
Joachim: I suggest to leave this attribute and follow Giorgio’s proposition to rename it to “isLandmarked”. It is correct that this is a general CityGML issue, but I expect CityGML 3.0 not before late 2017, if any. In IFC, a building also has such an attribute, which shows that it might be relevant for some applications.
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/71move guidelines to doc2016-02-03T12:06:34+01:00Moritz Robert Laustermove guidelines to doc*Created by: mlauster*
Would it make sense to move guidelines to doc?
*Created by: mlauster*
Would it make sense to move guidelines to doc?
v0.7.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/70UML Diagrams in readme2016-01-15T14:07:10+01:00Moritz Robert LausterUML Diagrams in readme*Created by: mlauster*
The UML Diagrams are currently linked in readme.md (source: doc/UML_diagrams/) as well as in Guidelines_EnergyADE.md (source: guidelines/fig/), what in turn is linked in readme.md. I propose to keep them solely in...*Created by: mlauster*
The UML Diagrams are currently linked in readme.md (source: doc/UML_diagrams/) as well as in Guidelines_EnergyADE.md (source: guidelines/fig/), what in turn is linked in readme.md. I propose to keep them solely in Guidelines_EnergyADE.md, this will improve readability and we don't have two different versions of UML's.
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/69TimeSeries - optional/obsolete attributes2016-01-14T13:49:02+01:00Moritz Robert LausterTimeSeries - optional/obsolete attributes*Created by: gioagu*
Hello,
as discussed yesterday in Munich during the workshop, some attributes in the _TimeSeries need to be removed or changed. In detail:
1) the id attribute is obsolete and should be deleted.
2) the temporalExte...*Created by: gioagu*
Hello,
as discussed yesterday in Munich during the workshop, some attributes in the _TimeSeries need to be removed or changed. In detail:
1) the id attribute is obsolete and should be deleted.
2) the temporalExtent (which is not necessary for instance for irregular time series, or regular time series used for a DailySchedule) should be an optional attribute.
3) in TimeValuesProperties, the qualityDescription and the source should be also optional attributes.
4) The variableLabel is obsolete since it is already included in GML, and should be then removed.
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/68Schedule - change type and rename2016-01-14T13:49:33+01:00Moritz Robert LausterSchedule - change type and rename*Created by: gioagu*
Hello,
as discussed in Munich yesterday during the workshop, there are some requests regarding the schedules. The following proposals are from Giorgio, Thomas and Romain, but they were also (briefly) discussed with...*Created by: gioagu*
Hello,
as discussed in Munich yesterday during the workshop, there are some requests regarding the schedules. The following proposals are from Giorgio, Thomas and Romain, but they were also (briefly) discussed with the other participants during the afternoon brainstorming.
1) Rename the exising schedules as follows:
- ScheduleLoD0 --> ConstantValueSchedule
- ScheduleLoD1 --> DualValueSchedule
- ScheduleLoD2 --> DailyPatternSchedule
- ScheduleLoD3 --> TimeSeriesSchedule
The reason is that using the LoDx naming leads to confusion. What is more, a schedule does not correspond to a specific LoD of a building.
2) As a schedule may be reused several times, the type should be changed from "DataType" to "FeatureType"
v0.6.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/67Modelling the time period of a time series2017-11-27T09:06:19+01:00Moritz Robert LausterModelling the time period of a time series*Created by: JoachimBenner*
Actually, we are using the ISO type _TM_Period_ for beginning and end of both, regular and irregular time series, In the irregular time series, each value has an absolute time position (_TP_Position_), which ...*Created by: JoachimBenner*
Actually, we are using the ISO type _TM_Period_ for beginning and end of both, regular and irregular time series, In the irregular time series, each value has an absolute time position (_TP_Position_), which means that the definition of a TemporalExtent in principle is superflous. The only use case could be to enable the validation, whether a certain value falls into the specified temporal extent. Is this really needed?
I propose to shift the the attribute _temporalExtent \* from *_TimeSeries_ to _RegularTimeSeries_.
In GML, TM_Period is encoded as _gml:TimePeriodType_. This type works very well to define **absulute** time periods, e.g.
1. January 2014 - 14. march 2014
2010 - 2012
January 2010 - march 2012
8.00 h - 12:00 h
What is **not possible** with gml:TimePeriodType is to specify a date interval without an explicit year, e.g.
January - October
1. January - 31. January
I think this is a problem, because e.g. statistical climate data do not refer to a specific year, but to specific days, years and months within a year. Actually, I do not know a good way to express this type of information in GML. Has anyone ideas?
I would like to label this issue, but I do not know how to do this!
v0.8.0