New concepts from CCS/TMS data model

[wsw2016]

Infrastructure Managers typically split their big networks in pieces. In CCS/TMS the concept Area was introduced as a container of railway infrastructure on some part of the network. Having different views on this infrastructure-area allows to split different concerns into different container classes. The objective is, that the use-cases can select only required views to reduce overhead in data provision and consumption, and to reduce the learning-curve. E.g.

• TopoArea containing only the Topology-graph
• GeometryArea containing precise geometry specifications of the LinearElements (TrackEdges)
• SampledGeometryArea containing “safety-relevant” geometry of the LinearElements
• PropertiesArea describing gauge-profiles, energy supply, loading-Gauge-profiles, permittedBraking-distance, and static speed profiles for LinearElements (TrackEdges)
• FunctionalArea containing functional elements (SimplePoints, SlipCrossings, Derailes, Crossings, BaliseGroups, ETCSMarkers (prev. Signals), StopLocations, OperationalPoints, Tunnels, Bridges, Underpasses, TvpSections, TrainDetectors, LevelCrossings, NationalBorder, BufferStop).
• TrackUsageArea defining primary, secondary, shunting tracks, preferred directions for planning purposes.

Using the grouping especially in PropertiesArea allows definition of common attributes for the entire area (which is normally the case) and some exceptions if needed. This covers the use-case for the era:AggregatedObject.

Representation of the infrastructure data on any map (WGS84, ETRS89, Monitor-coordinates etc.) is modelled in a separate package, as the use-case is not generic.

Question: how to integrate these structures into the ERA-vocabulary >= 3.1.0?

[Airy59]

The "Area" as used in CCS TMS is not really a concept but rather an arrangement that very much smells like XML or JSON legacy.

I'd recommend using annotation properties (plain or dedicated) and/or SHACL to ease the filtering out of a particular area for a particular usage.

It would make sense to pre-define a list of "most common usage profiles" in order to help the extraction of complete and consistent subsets of the ERA ontology (T Box) and matching data (A Box).

See also conference paper "SHACL is for LBD what mvdXML is for IFC", Oraskari et al., October 2021, a free download.