Refinement of Transportation module

[TatjanaKutzner]

The UML model of the Transportation module mentions refinements that still need to be added to the UML model.

[TatjanaKutzner]

The attached PDF presents a refined Transportation module for discussion at the next Modelling subgroup meeting:
2019_10_21_Transportation with code lists.pdf

The proposal contains the following refinements:

• The module includes the new concepts Waterway, Intersection, and Marking.
• The TransportationComplex is now modelled as AbstractTransportationSpace, the class TransportationSpace has been removed.
• The classes Track, Road, Waterway, Railway, and Square have now the stereotype <<TopLevelFeatureType>>.
• The relations between AbstractTransportationSpace, TrafficSpace, and GM_Complex no longer differentiate between lod0/1/2/3Network, there is now simply defined as network.
• AuxiliaryTrafficSpace is now a subclass of AbstractUnoccupiedSpace instead of AbstractPhysicalSpace.
• The subclasses Drain, Manhole, and RoadwayDamage have been removed, as they could be defined by a class property in the class Hole as well.

[TatjanaKutzner]

At the web conference on 23 October 2019 we discussed the Transportation module.
Amongst others, we discussed how to represent different types of decomposition of Roads.
Three types of decomposition are common:

1. The road is represented as a single area.
2. The road is split up into the driveway and the footpath.
3. The driveway is even further decomposed into the individual driving lanes.

To be able to specify which type of decomposition is used in a data set, we discussed to introduce an attribute granularity with the possible values area, lane, and way.

The attached PDF shows the changes applied to the UML model:
2019_10_25_Transportation_with_code_lists.pdf

The attribute was added to the classes TrafficSpace and AuxiliaryTrafficSpace.
An additional enumeration GranularityValue lists the possible values.
Only the values lane and way were added to the enumeration, because the granularity is implicitly of type area, when representing the road as a single area using the class AbstractTransportationSpace. Only when the road is decomposed into driveways/driving lanes and footpaths, the classes TrafficSpace and AuxiliaryTrafficSpace are used and we need to differentiate between way and lane explicitly.

In addition, a class HoleSurface was introduced to be able to represent the boundary surface of a hole.

[TatjanaKutzner]

Please find here the latest version of the Transportation UML model that is also included in the latest eap file (commit ae8c197) and encoded in the XML schema files (commit opengeospatial/CityGML-3.0Encodings@bb0c6dc): 2019_11_01_Transportation with code lists.pdf

The following has been changed: The attributes class, function, and usage have been removed from the class AbstractTransportationSpace and have been defined separately for the classes Track, Road, Waterway, Railway, and Square. This modification was necessary to obtain a correct encoding for all subclasses of AbstractTransportationSpace. Without this modification the attribute class was not encoded for the classes Section and Intersection, but treated as inheritance from AbstractTransportationSpace.

[thomashkolbe]

The property trafficFlow is at the wrong place in the data model and also its datatype needs to be changed to an enumeration. The property should be renamed to trafficDirection and should be removed from the class Section and inserted into the two classes AbstractTransportationSpace and TrafficSpace (as optional properties). Hence the property should become:
trafficDirection: TrafficDirectionValue [0..1]

Possible values are: forwards, backwards, both

The property gives the information in which direction(s) traffic is allowed on the general level of a Road, Railway, Track, or Waterway (when given in the respective feature) or on the other granularity levels (way or lane) within TrafficSpaces. The property is always to be interpreted with an associated network property. The edges in the geometric complex have a default direction going from the start point to the end point. trafficDirection=forwards means that traffic is only allowed going in the default direction defined by the edges in the geometric complex. trafficDirection=backwards means that the flow of traffic is only allowed to go in the opposite direction with regard to the default direction defined by the edges. trafficDirection=both means that traffic can go in both directions for the respective transportation feature.

[TatjanaKutzner]

Please find here the UML model with the trafficDirection property:
2019_11_05_Transportation with code lists.pdf

[TatjanaKutzner]

Please find attached some slides with explanations and examples for the revised Transportation module: Explanations on the Transportation Model.pdf

[TatjanaKutzner]

Based on the discussion in the web conference on 8 November 2019 the following was updated in the latest commit:
The GM_Complex geometry as well as the network associations from TrafficSpace and AbstractTransportationSpace to GM_Complex were removed from the Transportation module. Instead, an association lod0MultiCurve between AbstractSpace and GM_MultiCurve was added in the Core module.
As GM_Complex does not allow intersecting edges at crossings, artificial nodes would need to be introduced at intersecting edges. These artificial nodes can be avoided by modelling the network representation using MultiCurve geometries in LoD 0.
Another advantage of this modification is that the Transportation module no longer contains additional geometry classes.

PDF with UML diagram: 2019_11_08_Transportation with code lists.pdf