citygml-energy issueshttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues2017-12-11T09:46:26+01:00https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/139Automatic schema validation on Github2017-12-11T09:46:26+01:00Moritz Robert LausterAutomatic schema validation on Github*Created by: pascal-schetelat*
I've merged the automatic validation process into the master and realease branche v0.8 and v0.9.0
## What it does:
If any of you add a sample file in the v0.8 release branch, github will automaticall...*Created by: pascal-schetelat*
I've merged the automatic validation process into the master and realease branche v0.8 and v0.9.0
## What it does:
If any of you add a sample file in the v0.8 release branch, github will automatically test wether this sample file validate against the most recent version of the v0.8 energy.xsd
## How it does it :
- For every commit done on the master or release branches (since v0.8), github launches a test procedure with travi-ci
- The test try to validate all the *.gml files that it founds in citygml-energy/samples/ against the energy.xsd schema
- If any file fails to validate, the test will be reported as failing
- If all the files validate, the test will be reported as passing
- It will update the build status badge displayed in the main page of the repository. If you switch to a specific branch on the main page, the badge will actually reflect the status of that branch.
Here are the current status of the different branches :
- master : [![Build Status](https://travis-ci.org/cstb/citygml-energy.svg?branch=master)](https://travis-ci.org/cstb/citygml-energy)
- v0.8 : [![Build Status](https://travis-ci.org/cstb/citygml-energy.svg?branch=v0.8)](https://travis-ci.org/cstb/citygml-energy)
- v0.9.0 : [![Build Status](https://travis-ci.org/cstb/citygml-energy.svg?branch=v0.9.0)](https://travis-ci.org/cstb/citygml-energy)
As of today (17/05/2017, v0.9.0 is just a copy of v0.8)
To see which files fail to validate, click on the badge, click on the branches tab and select the build at fault. Skip to the bottom of the test log and look at **"KO"**
For instance, as of today, there is an issue the a sample file in the master :
```python
../samples/Rotterdam_Bospolder_bldgAttr.gml
KO
/home/travis/build/cstb/citygml-energy/samples/Rotterdam_Bospolder_bldgAttr.gml:2:0:ERROR:SCHEMASV:SCHEMAV_CVC_ELT_1: Element '{http://www.opengis.net/citygml/1.0}CityModel': No matching global declaration available for the validation root.
```
Meaning this sample file does not validate because it is compliant with citygml 1.0
# what next ?
That kind of procedure could be extended to test any kind of tools that rely on the ADE, for instance if the 3DCityDB Extension for Energy-ADEdatabase is working as expected.
Let me know if any of you have any remarks/ questions regarding this new feature and if you wish to extend it, I'll briefly talk about it next week on the workshop
https://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.0https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/137Classification of Emitter in EnergySystem module2017-11-27T09:26:14+01:00Moritz Robert LausterClassification of Emitter in EnergySystem module*Created by: gioagu*
In a first attempt to reorganise hierarchically most of the entities in the Energy System module, the classification of Emitter is somehow unclear. We have so far three "big families" of classes: Conversion, Storage...*Created by: gioagu*
In a first attempt to reorganise hierarchically most of the entities in the Energy System module, the classification of Emitter is somehow unclear. We have so far three "big families" of classes: Conversion, Storage and Distribution. The emitter is however alone and only connected to a Distribution class.
I was wondering, together with Joachim and Romain, whether there could be a way to characterise it a bit better. On one side, it is delivering energy to satisfy an energy demand, but it is not connected to it. On the other side, is it really a device which distributes energy (e.g. heat?), or just the end node of a distribution system?
The general idea is to define a general abstract class _EnergySystem which generalises all Conversion, Distribution and Storage Systems. An UML diagramme, and a new ticket, will be ready issued soon (thx Joachim!).
Dear members of the Energy System team, could you please help?
Thank you for your help!
ghttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/134Solar thermal parameters2017-11-27T09:25:01+01:00Moritz Robert LausterSolar thermal parameters*Created by: RomainNouvel*
To be more comprehensible, we could replace the attribute names of SolarThermalSystem and PhotovoltaicThermalSystem:
eta0 -> zero heat loss efficiency (scaletype[0.1]), also called optical efficiency
a1 -> l...*Created by: RomainNouvel*
To be more comprehensible, we could replace the attribute names of SolarThermalSystem and PhotovoltaicThermalSystem:
eta0 -> zero heat loss efficiency (scaletype[0.1]), also called optical efficiency
a1 -> linear heat loss coefficient (numerical)
a2 -> quadratic heat loss coefficient (numerical)https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/133Change cardinality of relation ThermalOpening-->_Opening2017-11-27T09:24:37+01:00Moritz Robert LausterChange cardinality of relation ThermalOpening-->_Opening*Created by: gioagu*
The current relation "relatesTo" has cardinality 0..1.
We should extend it to 0..* in order to be able to also define _ThermalOpenings (e.g. just in terms of global area in m^2) that actually correspond to (the s...*Created by: gioagu*
The current relation "relatesTo" has cardinality 0..1.
We should extend it to 0..* in order to be able to also define _ThermalOpenings (e.g. just in terms of global area in m^2) that actually correspond to (the sum of) multiple _Openings.
Agree?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/132Occupancy Module: about class type of Facilities2017-11-27T09:23:25+01:00Moritz Robert LausterOccupancy Module: about class type of Facilities*Created by: gioagu*
Hello!
This is, as a matter of fact, a direct continuation of the previous issue regarding the EnergySystem.
Piergiorgio and I were wondering whether it coule make sense to derive the class Facilities directly f...*Created by: gioagu*
Hello!
This is, as a matter of fact, a direct continuation of the previous issue regarding the EnergySystem.
Piergiorgio and I were wondering whether it coule make sense to derive the class Facilities directly from _CityObject, similarly to the UsageZone and the BuildingUnit.
Or, on the other hand, why where they defined as Features (as they are now) and not as CityObjects?
What do you think?
g & pg
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/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.0