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/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/119How to specify U-values at building scale?2017-11-27T09:10:03+01:00Moritz Robert LausterHow to specify U-values at building scale?*Created by: oliviertournaire*
I am wondering how it is possible to define U values at building scale only. Let's say that a building is modeled in LOD 0 (lod0Footprint + measuredHeight) or in LOD 1, it can be interesting for some simul...*Created by: oliviertournaire*
I am wondering how it is possible to define U values at building scale only. Let's say that a building is modeled in LOD 0 (lod0Footprint + measuredHeight) or in LOD 1, it can be interesting for some simulation tools to define a single U value for the walls and / or the ground and / or the roof.
I can use several `Construction` instances and attach them to the building, but how can I differentiate them (except using a convention that fills the `gml:name` or `gml:description`)?
v0.8.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/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/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/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/113New efficiency related attributes in HeatPump and CombinedHeatAndPower2016-06-29T20:50:42+02:00Moritz Robert LausterNew efficiency related attributes in HeatPump and CombinedHeatAndPower*Created by: RomainNouvel*
Request of Change: (coming from WG conf call discussion):
1- in object HeatPump :
- Delete carnotEfficiency
- Add the optional attributes "copSourceTemperature" (Type: MeasureType, Definition: Source temperat...*Created by: RomainNouvel*
Request of Change: (coming from WG conf call discussion):
1- in object HeatPump :
- Delete carnotEfficiency
- Add the optional attributes "copSourceTemperature" (Type: MeasureType, Definition: Source temperature defining the Coefficient Of Performance of the heat pump) and "copOperationTemperature" (Type: MeasureType, Definition: Operation or supply water temperature defining the Coefficient Of Performance of the heat pump)
2- in object ConbinedHeatPower:
- Add the optional attributes "thermalEfficiency" (Type: ScaleType, Definition : Efficiency of the heat production, corresponding to the quotient of the thermal output over the fuel input) and "electricalEfficiency" (Type: ScaleType, Definition : Efficiency of the power production, corresponding to the quotient of the electrical output over the fuel input)
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/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/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/107Relation "consistsOf" instead of "consiststOf"2016-05-10T17:14:34+02:00Moritz Robert LausterRelation "consistsOf" instead of "consiststOf"*Created by: RomainNouvel*
Small type mistake on the relation between Occupants and Household.
Please correct relation name -> consistsOf. The relation name could be even improved/simplified ("are", "groupedIn", "arrangedIn"...)
*Created by: RomainNouvel*
Small type mistake on the relation between Occupants and Household.
Please correct relation name -> consistsOf. The relation name could be even improved/simplified ("are", "groupedIn", "arrangedIn"...)
https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/104About cardinality of ThermalComponents2016-06-29T20:35:22+02:00Moritz Robert LausterAbout cardinality of ThermalComponents*Created by: gioagu*
So far, each ThermalBounday MUST have at least one ThermalComponents.
If I use a single ThermalComponent, I can define the area and - e.g. by Construction - how it is made.
If I use two ThermalComponents, I may defi...*Created by: gioagu*
So far, each ThermalBounday MUST have at least one ThermalComponents.
If I use a single ThermalComponent, I can define the area and - e.g. by Construction - how it is made.
If I use two ThermalComponents, I may define how many m^2 are wall and how many are glazing.
However, if I do not have this information, but just the ThermalBoundary, I still need to generate at least one ThermalComponent for each ThermalBoudary. This makes sense if I am using the data as input for simulation software, but (sometimes) not if I simply want to transfer data.
Imagine I have a city with 1000000 ThermalBoundaries and no other information. My XML file needs 1000000 ThermalComponents to be valid. But do I really need them?
I will generate the ThermalComponents depending on the type of library I am using (e.g. from where I get the window_to_wall ratio and the construction) in order to feed the simulation tool, but do I really need to store this information in advance?
Maybe the cardinality from ThermalBoundary to ThermalComponent could be relaxed to 0..n.
If so, I would also add an area attribute also to the ThermalBoudary object.
v0.7.0https://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/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/101attribute Emissivity instead of Emittance2016-06-29T21:12:16+02:00Moritz Robert Lausterattribute Emissivity instead of Emittance*Created by: RomainNouvel*
For the last Energy ADE 0.6 release, we agreed to rename the attribute Emittance -> Emissivity. However, only the type has been changed, not the attribute name.
This should be correct in the new release.
*Created by: RomainNouvel*
For the last Energy ADE 0.6 release, we agreed to rename the attribute Emittance -> Emissivity. However, only the type has been changed, not the attribute name.
This should be correct in the new release.
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/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/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.0