citygml-energy issueshttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues2016-07-01T09:31:39+02:00https://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/114Restrict Construction / ConstructionOrientation to relevant ADE features2018-12-06T10:43:38+01:00Moritz Robert LausterRestrict Construction / ConstructionOrientation to relevant ADE features*Created by: JoachimBenner*
In ADE version 0.6.0, we defined the new classes **Construction** and **ConstructionOrientation**, and simultaneously introduced the extension attribute **construction** of **_CityObject**. This allows that ...*Created by: JoachimBenner*
In ADE version 0.6.0, we defined the new classes **Construction** and **ConstructionOrientation**, and simultaneously introduced the extension attribute **construction** of **_CityObject**. This allows that every CityGML feature of the base standard as well as of the Energy ADE can refer to layered material information.
This is problematic due to two different reasons:
- It is not the task of the Energy ADE to define general extensions of the base standard, especially in cases where a corresponding change request for CityGML 3.0 already exists.
- Concerning the specific features of the EnergyADE, there are many of them where the **construction** relation does not make sense (e.g. **ThermalZone**, **UsageZone**, ..) or where the specification of material information is even forbidden (**ThermalBoundary**).
I therefore propose to delete the _general_ **construction** relation from **_CityObject** to **Construction / ConstructionOrientation**, and to introduce _specific relations_ for those classes of the base standard and the extension where the concept is really needed: **_BoundarySurface** and **ThermalComponent**.
For simplifying the schema, I furthermore propose to introduce a new, abstract super class **AbstractConstruction** of **Construction** and **ConstructionOrientation**, which can be used as relation target.
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/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/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/106Relation "correspondsTo" from ThermalBoundary to _BoundarySurface2018-12-06T10:43:38+01:00Moritz Robert LausterRelation "correspondsTo" from ThermalBoundary to _BoundarySurface*Created by: JoachimBenner*
The ADE class ThermalBoundary has a relation _correspondsTo_ of carnilality 0..1 to the CityGML base class _BoundarySurface. In case on an LOD4 model with Room, InteriorWallSurface, FloorSurface and CeilingSu...*Created by: JoachimBenner*
The ADE class ThermalBoundary has a relation _correspondsTo_ of carnilality 0..1 to the CityGML base class _BoundarySurface. In case on an LOD4 model with Room, InteriorWallSurface, FloorSurface and CeilingSurface objects, this is problematic, because a ThermalBoundry will be related with **two** _BoundarySurface objects:
- For exterior thermal boundaries, it is related with one exterior boundary surface (e.g. a WallSurface) and one interior boundary surface (e.g. a InteriorWallSurface)
- For interior thermal boundaries, it is related with two interior boundary surfaces (e.g. two objects InteriorWallSurface)
Therefore, I propose to change the cardinality of _correspondsTo_ to **0..2**.
v0.7.0https://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/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/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/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/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/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/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/96Additional attribute status in EnergyDemand2018-12-06T10:43:38+01:00Moritz Robert LausterAdditional attribute status in EnergyDemand*Created by: JoachimBenner*
The featureType _EnergyDemand_ can be used either to provide input data for energy demand simulations or to represent the output data of these simulations. At the moment, _EnergyDemand_ has no property to ind...*Created by: JoachimBenner*
The featureType _EnergyDemand_ can be used either to provide input data for energy demand simulations or to represent the output data of these simulations. At the moment, _EnergyDemand_ has no property to indicate whether the property _energyAmount_ carries input data or simulation results.
**Proposal**
1. Introduce a new (mandatory?) property **status** of _EnergyDemand_ with property values defined by an enumeration
2. Introduce a new enumeration **EnergyDamandStatusValue** with items: **Simulated**, **Measured**, **Estimated**, **Unknown** (must be discussed)
v0.7.0https://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.0