citygml-energy issueshttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues2017-05-29T14:06:49+02:00https://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/131EnergySystem Module: no _CityObjects?2017-05-29T14:01:36+02:00Moritz Robert LausterEnergySystem Module: no _CityObjects?*Created by: gioagu*
Hello,
I have noticed that none of the EnergySystem classes is derived from a _CityObject, but is "just" a Feature.
I my opinion, many of them (EnergyDistributionSystem, EnergyStorageSystem, Emitter, EnergyCon...*Created by: gioagu*
Hello,
I have noticed that none of the EnergySystem classes is derived from a _CityObject, but is "just" a Feature.
I my opinion, many of them (EnergyDistributionSystem, EnergyStorageSystem, Emitter, EnergyConversionSystem) should actually be derived from a _CityObject.
If so, I believe this change should be backported directly to the 0.8 version.
What do you think?
Greetings,
g
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/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/23Expand BuildingType Codelist2016-07-01T10:21:30+02:00Moritz Robert LausterExpand BuildingType Codelist*Created by: oliviertournaire*
[Reported by Piergiorgio Cipriano]
In general, an alignment with INSPIRE codelists is suggested.
BuildingType: at the moment the codelist (BuildingType.xml) is only containing 3 possible values:
- Singl...*Created by: oliviertournaire*
[Reported by Piergiorgio Cipriano]
In general, an alignment with INSPIRE codelists is suggested.
BuildingType: at the moment the codelist (BuildingType.xml) is only containing 3 possible values:
- SingleFamilyHouse
- MultiFamilyHouse
- ApartmentBlock
We suggest to expand the codelist with the following:
- SFH (Single Family House)
- MFH (Multi Family House)
- TH (Terraced House)
- AB (Apartment Block)
- HLB (Historical large building)
- HSB (Historical small building)
The latter are crucial to estimate energy needs in historical centres (e.g. Ferrara, in Sunshine project).
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/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/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/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/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/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/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/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/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/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/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/97Order of object attributes in XSD file2016-06-29T22:23:17+02:00Moritz Robert LausterOrder of object attributes in XSD file*Created by: RomainNouvel*
Hi,
I wonder how have been ordered the attributes of the different objects, and if there is a way to list them alphabetically, in order to find out quickly the different attributes and possible XML errors
*Created by: RomainNouvel*
Hi,
I wonder how have been ordered the attributes of the different objects, and if there is a way to list them alphabetically, in order to find out quickly the different attributes and possible XML errors
v0.7.0https://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/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.0