GML-independent modelling of the Core model

[TatjanaKutzner]

Currently, the classes AbstractFeature and AbstractGML from the GML specification are included in the Core model of the CityGML 3.0 UML model. Both classes were added to the UML model to illustrate that the CityGML feature types inherit certain standard attributes from these classes. The problem is: Both these classes are GML-specific, whereas the CityGML model is language-independent. GML is only one of several possible encodings. Thus, it is actually not correct, to use language-specific classes in the language-independent CityGML UML model.

[TatjanaKutzner]

The editors suggest to remove both classes from the normative UML model to make the UML model fully language-independent. However, to be able to illustrate clearly which attributes are by default inherited by all CityGML feature types, above figure should be included in the Conceptual Model Specification as part of the informative sections.

[3DXScape]

This seems essential to eliminate a GML dependency that would apply across all encodings.

[3DXScape]

This idea of supplying a private copy of the GML concept with a "note" to the developers of encodings that for the GML encoding, the native GML construct can be used. This is no different than adopting native representations of strings, numbers, truth values, and other basic types in individual encodings.

[TatjanaKutzner]

In the web conference on 17 May 2019 we agreed on removing the classes AbstractFeature and AbstractGML from the UML model. Instead, we will add a comment and describe there which attributes are inherited from these classes.

[TatjanaKutzner]

The class AbstractGML defines the attributes description, descriptionReference, name and identifier that are inherited by all feature types in an GML application schema. We removed the class from the CityGML UML model to become GML-independent.

The CityGML UML model assumes that the attributes are also defined at the conceptual level. However, the attributes seem to be GML-specific. I did not find anything in the ISO standards that they are also available at the conceptual level. The class AnyFeature that we introduced to the UML model (see issue #61) is an empty class. Also the stereotype <<FeatureType>> does not implicitly bring the attributes along.

Thus, it would be useful to add a new class AbstractFeature to the Core module which defines these attributes, as suggested in the figure. Also, when encoding the UML model in non-GML formats, it can be guaranteed in this way that the attributes are included.

[3DXScape]

This sounds like a good idea.

[clausnagel]

I am not sure why this is required. Where does the current UML model assume that these attributes are defined?

If we introduce this class and map the UML to GML, then there would be two AbstractFeature types with identical attributes - one in the GML namespace and one in the CityGML core namespace. I think we should avoid this.

[TatjanaKutzner]

Mapping to GML is not a problem, as the class can be supressed from being encoded. The GML application schemas won't change.

[clausnagel]

For me, the more important question is why we need this class at all?

[TatjanaKutzner]

We discussed the issue in the web conference on 27 February 2020 and decided to ask Clemens on this issue.

According to Clemens no general super class exists that defines the attributes from AbstractGML. Clemens also is not aware of any activity working on such a specification.
He says that we want to make sure that the attributes are generally available in CityGML encodings, we have to provide a class in the UML model that the defines the attributes.

[TatjanaKutzner]

I had a look at the LandInfra model. They also provide their own Feature class that is a specialisation of the ISO 19109 AnyFeature class. Additional feature types defined in LandInfra are defined as specialisations of the LandInfra Feature class. The class defines amongst others the attributes featureID, name, and description:

In the GML application schema, these three class attributes are not encoded, but are represented by the GML attribute gml:id and the GML elements gml:name and gml:description.

[clausnagel]

Thanks, Tatjana, for discussing this issue with Clemens.

If this class is required, then which properties from gml:AbstractGML resp. gml:AbstractFeature do we need to copy into this class? For instance, why do we need both description and descriptionReference and why are properties such as gml:id or gml:boundedBy omitted in the above proposal?

And we need to be aware that we allow ADE-based property injections for all <<FeatureType>>s in the current conceputal model. In order to be consistent, the proposed AbstractFeature class must be mapped onto its own representation in the GML encoding so that we can apply the ADE extension mechanism (it would not be sufficient to just map it onto gml:AbstractFeatureType as this type does not support ADE property injections). So, we have another abstract level of ADE extensions...

[TatjanaKutzner]

In the proposal I simply provided those attributes that are defined as child elements in gml:AbstractGML. We should discuss, which of these attributes make sense for CityGML. Also, if it makes sense to include gml:id and gml:boundedBy as well. I think, the attribute descriptionReference could probably be left out.

I think it will be difficult to map AbstractFeature in the GML encoding. We will then have the properties twice in different namespaces, as you mention above. I rather see the class as a means of being able to provide the properties in different encodings, not as a full representation of a concept from which ADE classes should be derived - and when a specific encoding already provides the properties, then the class should be suppressed from being encoded.
Can we define a constraint in the conceptual model that specifies that the class AbstractFeature is not allowed to be used in ADEs?

[clausnagel]

Hm, that's why originally I thought this is rather a hack than a good idea. And it's not just property injection - someone could want to derive a new class from AbstractFeature by specialization. Should this use case be allowed in an ADE, and just property injection be forbidden? If we look at existing ADEs, then they often contain feature types that are directly derived from gml:AbstractFeature.

Would ShapeChange allow mapping the AbstractFeature class to its own complex type definition in the CityGML namespace but let it inherit all the copied properties from gml:AbstractFeatureType? Then it wouldn't have duplicate attributes and could be used in ADEs like other feature types.

[3DXScape]

I still think adding the class to carry these attributes is useful. Adding the constraint against use in ADEs is a way to make it cleaner. It does seem a bit of a hack - but useful.

[TatjanaKutzner]

That's right, we have to allow AbstractFeature, it's used in several ADEs as super class.
I saw today that the new ShapeChange version offers the possibility to suppress individual attributes from being encoded. In this way, it should be possible to encode AbstractFeature in the CityGML namespace and let it inherit the copied properties.
I will try that out with ShapeChange. I first need to update to the newer version.

[TatjanaKutzner]

I tested the suppression of the attributes with ShapeChange and it works fine.
This means it would be possible to encode AbstractFeature as a complex type definition in the CityGML namespace that extends gml:AbstractFeatureType, suppress the copied attributes and inherit them from gml:AbstractFeatureType.
I also tested some other things with ShapeChange, but think that this is the solution that can best be realised with ShapeChange.

[3DXScape]

Thanks for working this out, Tatjana. This sounds like a resolution of the issue to me.

[clausnagel]

Thanks Tatjana, this is good news. This means that we can be consistent and use AbstractFeature like any other CityGML feature type in ADEs. This would also resolve the issue for me, ...

... but we have also several <<ObjectType>>s in the conceptual model. In the GML schema, they are also derived from gml:AbstractGML and, thus, inherit attributes like gml:id, identifier, description and name. But we do not model these attributes in the conceputal model. So, we need to create another AbstractObject class in our core model, copy the attributes from gml:AbstractGML into this class, let it be a superclass for AbstractFeature, and suppress the copied attributes with ShapeChange. Right?!

[TatjanaKutzner]

I just discussed with Claus on the phone. Yes, it's right, theoretically we also have to define an AbstractObject class to be really consistent. But this would also mean that:

• For all classes with the stereotype <<ObjectType>> and all classes with no stereotype, additional inheritance relationships need to be added to the UML model.
• The new class AbstractFeature inherits from the classes AnyFeature and AbstractObject, which means that we have multiple inheritance again in the UML model.

We do not think that the attributes are required for all the object types defined in the UML model and prefer not to add an AbstractObject class to avoid these additional complexities in the UML model.
In case that one of the attributes seems to be necessary for a specific object type class, we rather think that it would be better to add the attribute directly to that class.

[TatjanaKutzner]

I just saw that the association between ImplicitGeometry and GM_Object has the role name relativeGMLGeometry. I suggest to rename it to relativeGeometry to be also GML-independent here.

[TatjanaKutzner]

The attribute featureMember in the class CityModelMember still has the type AnyFeature. That must also be changed to our new type AbstractFeature, right?

[clausnagel]

Yes, I agree.

[3DXScape]

Yes

[clausnagel]

There are still some <<FeatureType>> classes that are not derived from the new core:AbstractFeature class in UML. In the GML encoding, they are therefore derived from gml:AbstractFeature instead. I think this is inconsistent and needs to be resolved, right?

These are the classes I found: core:AbstractPointCloud, app:AbstractSurfaceData, dyn:AbstractTimeseries, core:Address. Maybe there are more.

[3DXScape]

Yes, I think so also. Thanks for looking for these.

[TatjanaKutzner]

Yes, right, they need to be derived from the new AbstractFeature class. I will add inheritance relationships to the UML model and check if there are more classes that need to be derived.

[TatjanaKutzner]

Issue was solved in March 2020 already.