Data models
Content
This document contains additional information for the Nordic NeTEx profile, including overall data models and conceptual descriptions of how the elements from NeTEx will be used.
Context
Transmodel (European Standard “Public Transport Reference Data Model”, http://www.transmodel-cen.eu) is the reference model and framework, used to define the Norwegian data model for exchanging public transport information, respectively, NeTEx (Network Timetable Exchange, http://netex-cen.eu/) for stop places, timetable data and SIRI (Service Interface for Real-time information, https://www.vdv.de/siri.aspx).
Both data models are implemented as XML and defined in respective XML Schemas (XSD). Further requirements for using the exchange formats are specified in Norwegian profiles for NeTEx and SIRI.
The framework's implementations form the basis of the services offered for national public transport data in the Nordic countries:
Disclaimer
This document presents high-level technical views of various data models models and conceptual models utilised in the Nordic NeTEx profile. The models are intentionally created with viewpoints reflecting generic, and highly simplified, key features of the Nordic NeTEx profile as well as the NeTEx standard in general, and do neither fully comply with the UML modeling language nor take into account all aspects of the NeTEx standard.
For full feature technical models, please see the Model documents and UML Diagrams at the CEN NeTEx website.
Framework
Location
One point (Point) is a node in the network with a specified location (Location). It can be a stop place, Point of Interest (POI) or a ticket control point at a station. The point can be used to specify a larger unit - e.g. an area, using projection (Point Projection). A point can also be used for the definition of a leg, e.g. to describe the actual path between two stop places. A leg can be described by using a link (Link).
To define a larger area, (e.g. Tariff Zone) use the Zone objects, which contain different points, and can also be projected onto a map using ZoneProjection.
NeTEx data model for location objects
Organisation
If you need to describe the organisational structure, you have a selection of several objects:
Organisation may be either the Authority entity (responsible for providing public transport services), or the Operator company fulfilling the physical public transport role. Operators can be further grouped into GroupOfOperators if necessary.
Organisations can be divided into departments (Department) to better reflect their structure.
Each organisation has contact information and postal address.
A unique area of responsibility (Responsibility Set) can be assigned to an organisation to specify the parts of the dataset it represents.
NeTEx data model for organisation
Validity
Every single object in NeTEx can be versioned which allows changes without affecting unchanged data. A version of an object is tied to a validity description (Validity Condition) which specifies when the definition takes effect.
Validity Condition has two specializations:
Trigger (Validity Trigger) which allows long-term changes to be specified (e.g. the stop is moved during a period of flooding, or while there is a sports event). The trigger initiates the change.
AvailabilityCondition used to describe temporary conditions with precisely specified dates.
NeTEx data model for validity
Messages/footnotes
Delivering messages to customers is essential when there are deviations or special circumstances for a service. Messages are created using Notice objects (free text messages) and assigned to different objects using a NoticeAssignment, e.g. for a single journey (VehicleJourney) or a route with a specific JourneyPattern. Notices can be delivered in different variations depending on the media it is meant to be displayed on, e.g. a short message for the information screen at the bus stop, a longer message for mobile devices, and an expanded message for website presentation. This is handled by using DeliveryVariant.
NeTEx data model for messages
Stops
StopPlace
A stop point (StopPlace) is a special type of site (Site) normally located in a Tariff Zone. As a Site, a StopPlace can have multiple- Parkings, Levels (each one with its own Entrance), and accessibility Equipment. In addition, a StopPlace is divided into subordinate Quays (and below the Quay, Boarding Positions). Each StopPlace can also have waiting areas (Access Space) and footpaths (NavigationPath).
The structure of stop places is subject to variation. It can be anything from a simple kerb stop, to the most complex transport hubs. The following structure should be used to describe a stop place:
A StopPlace may have AccessSpaces.
A StopPlace may have a parent StopPlace (maximum 1 level of nesting).
Two or more StopPlaces, including parent StopPlaces, can be grouped into a GroupOfStopPlaces.
A Quay can have BoardingPositions (usually only relevant to trains).
NeTEx data model for stop place
Stop places have three distinct levels of structure:
StopPlace used by one transport type. This is MonomodalStopPlace.
StopPlace used by several transport types, e.g. bus and tram. This is MultimodalStopPlace.
A combination of several StopPlace in direct proximity to each other, e.g. bus and tram next to a metro station. This is GroupOfStopPlaces.
Note that Quays on a StopPlace must be monomodal (only for one transport type). If a StopPlace is multimodal (for multiple transport types), this should always be modelled as a parent StopPlace consisting of one StopPlace (with monomodal Quays) per transport type, even when the transport types use the exact same position for stops. It is possible to link StopPlaces which share a common position (one straddling the other, or exact same positions) using AdjacentSites, which can be useful when presenting multimodal stops on a map.
Please note that it is not a requirement that both stops belonging to a parent stop (Multimodal StopPlace) have different transport types.
Monomodal StopPlace
A MonomodalStopPlace is a simple stop place consisting of one or more Quays. This type of stop place can only be served by one type of transport, for example bus lines.
The following rules apply to MonomodalStopPlace:
A monomodal StopPlace cannot have any subordinate StopPlace.
A monomodal StopPlace must at least have one Quay.
A Quay can belong to only one monomodal stop place.
A monomodal StopPlace can have one parent StopPlace.
Quay
A Quay is an exact location where vehicles stop and travellers board, or alight.
For train platforms, the Quay can be divided into BoardingPositions if applicable. A BoardingPosition specifies exactly where on the platform a passenger should wait for the train, for example, comfort class car.
The following rules apply to Quay:
A transfer is implicit within the same Quay.
Quay inherits the name of its parent StopPlace
Multimodal StopPlace
A MultimodalStopPlace is a StopPlace, which serves more than one transport type. The multimodal StopPlace is the structural parent StopPlace, and it has at least two subordinate monomodal StopPlace.
Please note that it is not a requirement that both stops belonging to a parent stop (Multimodal StopPlace) have different transport types.
The following rules apply to Multimodal StopPlace:
Has no Quays directly tied to it.
Has no parent StopPlaces (only 1 level of nesting allowed).