Restrict Construction / ConstructionOrientation to relevant ADE features

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

[RomainNouvel]

Please to not forget _Opening also. Ok on the principle. Can you send us a representation of the new class diagram please?

[JoachimBenner]

At the momernt, I am working to integrate all change requests which are already "Approved by WG" into the new 0.7.0 version. I will distribute the model as soon as this is finished.

[gioagu]

Ok with the AbstractConstruction. Makes sense to me. If not a CityObject, I suggest the AbstractConstruction to be at least a Feature class (with id, gml name, description etc.). What do you think?

[JoachimBenner]

Yes, AbstractConstruction conceptually is a FeatureType

[RomainNouvel]

Ok, waht about setting ConstructionOrientation as optional (or have a default value "true") ?

[gioagu]

Ok with a standard value "true". As it is a boolean, I would prefer an attribute name which give hints at what it really means. Something like like: "follows_layer_order" or similar. Of course, better naming ideas is welcome! An orientation itself is not true or false, besides: I always need to check what is true and what is false...

;-)

[RomainNouvel]

...or isStandardConstructionOrientation

[gioagu]

The poin ist: what is a "StandardConstructionOrientation"? We want to add info whether we use the layer order as is, or we flip it as we are using the construction in the other way.

Maybe: flip_layer_order:: boolean (false) ?

[JoachimBenner]

The usage of ConstructionOrientation is optional, because either Construction or ConstructionOrientation (referencing a Construction) can be used.To use a ConstructionOrientation with attribute orientation == true in fact does not make sense. Thus, it might be better to rename ConstructionOrientation to "ReverseConstruction" (or something similar). This class does not need any attributes and has the definition: The Layers of the Construction referenced via baseConstruction are used in reverse order.

[gioagu]

OK, fine for me.

[RomainNouvel]

Looks goof @JoachimBenner. @gioagu : the standard (or reverse) order is/will be defined in our guidelines : for outside boundary, I think we agreed that the first layer faces the inside room (1st ThermalZone of relation delimits), and the last one faces outside or the 2nd ThermalZone of relation delimits, isn't it? Anyway, this is just a convention.

[oliviertournaire]

Implemented in latest version of the UML model