Relation "correspondsTo" from ThermalBoundary to _BoundarySurface

[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.

[RomainNouvel]

• For exterior thermal boundaries, we've written in the Definition (see also Schema in the Guidelines) that the thermal boundary corresponds to the outside CityGML BoundarySurface, not the interior Surface. However, what happens in the case that several BoundarySurface covers a wall (-> 3D city model of bad quality, but allowed I think)? In such a case, a cardinality 0..* would be even required.
• for interior thermal boundaries, you're right. However, the first purpose (and only role I think) of the relation "correspondsTo" is to retrieve the solar irradiances incident on outside BoundarySurface in order to consider them in the space heating/cooling calculation of the ThermalZone. Then, relating ThermalBoundary to interior BoundarySurface would be... useless.

Do you share this Point of view? Do you see other applications of this correspondsTo relation?

[JoachimBenner]

I have still some problems with your view.

I agree that radiation values are irrelevant for the interior boundary surfaces, but then we perhaps should not extent the base class _BoundarySutface, but only the derived classes like WallSurface, RoofSurface, .... And whats about the "refurbishment measues on boundary surfaces", are they irrelevant for a thermal simulation? If this is the case, what is the use case of these properties?

Furthermore, I have the feeling that we all have some implicit assumptions on the structure of a CityGML model used for simulation purposes which shouild be made explicit. It of course occurs that for instance flat wall surfaces are separated into several WallSurface objects, and which (or all?) of these objects shall be related with the radiation time series? On the other hand, also the opposite situation frequently occurs, the whole outer facade of a building is modelled as one WallSurface, one RoofSurface and one GroundSurface object. This means that the RoofSurface or WallSurface object does not have an unique orientation (normal vector). In some cases (e.g. walls with curved shapes like occuring in a circulat tower), this is unavoidable. I am not sure how for these cases the ThermalBoundaries and the radiation time series shall be generated, but I think we have to check whether the model also covers this situation and give hints (e.g. in the guidelines) how this situation can be handeled.

[JoachimBenner]

Rename "correspondsTo" to "relatesTo" (0..*) Delete relation "correspondsTo" from _BoundrySurface --> ThermalBoundary Add attribute "globalSolarIrradiance" to ThermalBoundary Abjust guidelines and discuss it in Vienna..

[Fouly]

I have checked the xsd file for the relationship between ThermalBoundary and BoundarySurface. I would like to ask if this is the right way to represent it: <element name="correspondsTo" minOccurs="0" type="gml:ReferenceType"> or it should be rather like (according to ISO 19136): <element name="correspondsTo" minOccurs="0" type="bldg:BoundarySurfacePropertyType">

[Fouly]

@JoachimBenner maybe you can help out with this issue?

[JoachimBenner]

Both encoding variants are ISO 19136 conformant. The variant with "gml:ReferenceType", which is the only way to encode relations between featureTypes in all INSPIRE models, enforces the usage of xlinks to specify the relation target. By using ...PropertyType, relations can either be expressed by xlinks or the related object can be embedded into the relating object.

In the Energy ADE, in most cases I used the PropertyType encoding. However, BoundarySurfaces will most likely be embedded in a Building object, and the ThermalBoundary will normally need a xlink to reference its corresponding BoundarySurface. This was the motivation to encode "correspondsTo" as gml:ReferenceType, but it is no problem to change the encoding.

What is the general opinion on this issue?

[gioagu]

My humble opinion is, it makes sense to encode the relation as "gml:ReferenceType". As a matter of fact, the building's boundary surfaces (Wall, Roof, Ground surface etc.) are supposed to be reached by xlinks only, not to be embedded in the ThermalBoundary. This would reduce the (unwanted) degrees of freedom in this specific case.

[yaozhihang]

Yes, It truly makes sence to use "gml:ReferenceType" for realizing the "By-reference only" in XML schema. However, for software applications, it may lead to unexpected behavier when parsing the Energy-XSD file using Low-Level APIs (e.g. XSOM), since the relevant logical relationship between the classes (ThermalBoundary and BoundarySurface) is only encoded in the "Annotation" XML tag.

[oliviertournaire]

@JoachimBenner What about

Add attribute "globalSolarIrradiance" to ThermalBoundary ? I cannot find it in the latest version of the UML model.

Other question: has a choice been made on the encoding of the relation relatesTo as a gml:ReferenceType or ...PropertyType?

[JoachimBenner]

We defined the new type WeatherData, which can be related (via relation weatherData )with all city objects. According to the enumeration WeatherDataTypeValue, the global solar irraciance is a special kind of weather data.

The relation relatesTo is still encoded as gml:ReferenceType. There are good conceptual arguments for this choice, and my personal opinion is that neither the data model nor the XML-encoding should be dependent from deficiencies of selected software tools or implementation methods. This surely is debatable, but the time to debate version 0.7.0 is over.

[oliviertournaire]

OK, agree. Can we thus close the issue @JoachimBenner ?

[JoachimBenner]

Yes from me