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:

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 always has at least one Quay.

• 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:

1. StopPlace used by one transport type. This is MonomodalStopPlace.

2. StopPlace used by several transport types, e.g. bus and tram. This is MultimodalStopPlace.

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

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:

1. A monomodal StopPlace cannot have any subordinate StopPlace.

2. A monomodal StopPlace must at least have one Quay. 

3. A Quay can belong to only one monomodal stop place.

4. 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:

1. A transfer is implicit within the same Quay.

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

The following rules apply to Multimodal StopPlace:

1. Has no Quays directly tied to it.

2. Has no parent StopPlaces (only 1 level of nesting allowed).

Group Of StopPlaces

GroupOfStopPlaces should be used when there is a need to group several mono- and/or multimodal stop places in order to refer to them simultaneously, usually to describe a larger and more complex StopPlace area, such as a hub or a town centre. 

FlexibleStopPlace

An on-demand service, or flexible line, often deviates from the static bus stops, instead, a flexible stop place can be used:

A FlexibleStopPlace, does not have a specific position, but rather a defined area, within which the flexible transport picks up, or drops off passengers depending on bookings, or other beforehand arrangements. This includes for example address to address journeys, hail and ride concepts, or combinations thereof.

NeTEx data model for a flexible stop place

Equipment

Facility

These are standardized lists describing available facilities which can be grouped into (reusable) FacilitySets. These are then used on relevant entities. 

Equipment

In order to describe the availability and usage of the Facilities, use the categories Equipment and EquipmentTypes (including LocalService) to describe for example the placement of the equipment.

Equipment normally has one or more FacilitySets.

Transport networks

Network

A network consists mainly of Line, Route and RoutePoints. To model them into the network, NeTEx uses the following structure:

• A Network consists of several lines Lines. 

• Each line is operated by an Operator and has one or more Routes associated with it. 

• A Route shows the overall physical route of a Network and consists of several RoutePoints. 
  
  

  • Note that a RoutePoint isn't necessarily a StopPlace.

• In order for it to be possible to reuse the same route points across multiple routes, RoutePoint objects are linked to the Route using the "intermediate object" PointOnRoute (see the diagram below).

NeTEx data model for network

Lines are grouped into a conceptual Network. The Lines are described as a set of Routes with RoutePoints. 

Conceptual NeTEx model for network

Generally speaking, a Route represents the structure of a network, though the RoutePoints do not infer how the network is traversed. This however, is defined by describing a given order of PointOnRoute as a pointsInSequence.

This can be illustrated by the following example: RoutePoint vs. PointOnRoute:

Route

Thus, a Route is defined as a list of RoutePoints, which are placed into the correct sequential order by PointOnRoute. To further describe the specifics of the Route, such as start, stop and turn-around  points, a JourneyPattern, linked to the Route is used.

Journey Pattern

The JourneyPattern is a general term which defines the "pattern of stops" (with- or without passengers). It consists of a sorted list of ScheduledStopPoint (stopping point for boarding or alighting) and/or "check points" (so called TimingPoint, used for measuring vehicle progress along the pattern. The pattern references stop points (StopPlace objects) using stopAssignments.

In addition, various time-related values can be defined if needed:

• Headway - interval between two departures.

• RunTime - time between two neighbouring points. 

• WaitTime - TimingPoint wait time.

NeTEx data model for JourneyPattern

The pattern itself is described as a set of points in a given order, pointsInSequence. This is usually the StopPointInJourneyPattern, but can also be the TimingPointInJourneyPattern.

NeTEx overall conceptual model for JourneyPattern

The journey pattern is further enriched by references to scheduled stops, ScheduledStopPoint, which again links to physical stops (Quay) through a StopAssignment:

NeTEx detailed conceptual model for JourneyPattern

Connection between Route and JourneyPattern
As shown in earlier example RoutePoint vs PointOnRoute a Route is defined as a set of RoutePoints in a given order, here illustrated by two routes (red and pink respectively):

How this route is operated is further defined by the JourneyPattern which consists of a set of ScheduledStopPoints in a given order, and these again refer to each respective Route. 

Each JourneyPattern  follows the same overall pattern as the referenced Route, but with considerably more detail. Thus, JourneyPattern 1 shows in detail what Route 1 describes generally, Journey Pattern 2 shows Route 2 in detail, and so on.

This forms the basis for describing the respective departures, explained in more detail in the chapter timetable data.

Flexible transportation

To model a flexible on demand transport, NeTEx offers "flexible" variants of Line and Route - FlexibleLine and FlexibleRoute. They have the same features as regular Line and Route, but with additional fields to describe contact- and booking information. PointOnRoute can also be expanded with FlexiblePointProperties which for example describes whether the point represents an area or a point.

NeTEx data model for flexible transport

Transfers and Interchanges

Interchanges has two aspects - physical and planned. The physical action of alighting one vehicle and boarding another is represented by Connection, which also refers to ConnectionEnd in order to describe that the interchanges can occur between two nearby stops (actually quays). Transfer objects are then used to describe physical transfer between the arrival- and departure quays.

The planned transfer is represented by Interchange objects which can be linked to Notice in order to provide customers relevant transfer information.

NeTEx data model for interchange

NeTEx timetable data representation

A timetable consists of one or more VehicleJourneys, usually modelled as ServiceJourney (which describes a specific departure at a specific time) assuming the departure is a passenger carrying service. At least two stops (PassingTime) are required in a ServiceJourney. The date of the ServiceJourney is specified as a DayType, which defines a period or a date. All journeys and other relevant elements are grouped into a TIMETABLE FRAME, while dates/periods are defined in a SERVICE CALENDAR FRAME.

A central part of the structure is the relationship between VehicleJourney and JourneyPattern which defines StopPoints (and perhaps TimingPoints) for a Route.

Once the pattern of the route has been defined, OperatingDay is used to describe when, and for how long, it operates. For this a ServiceCalendar is created to define the calendar days when the Line operates within an OperatingPeriod. It is possible to define day by day, but it is usually sensible to use DayType to define day patterns, such as "Monday-Friday". Even more detailed information, such as specific public holidays, can be defined in PropertyOfDay.

ServiceCalendar allows the linking of OperatingDay to DayType through DayTypeAssignment.

NeTEx data model for calendar

Timetable

When describing a timetable (schedule), TIMETABLE FRAME is used with VehicleJourneys which specifies the  ServiceJourneys (with passengers) for each journey. A VehicleJourney can, if necessary be divided into several parts (JourneyPart), when for example using compund trains.

It is also possible to describe rhytm based departures (for example repeating departures every 10 minutes over whole hours), or interval based departures (for example departures every 15 minutes), for a defined period of the day using JourneyFrequencyGroup which TemplateServiceJourney can refer to. Alternatively a list of stop places for a ServiceJourney can be created by using PassingTime objects refering to stops through a ScheduledStopPoint.

NeTEx data model for Vehicle Journey

This means each departure is defined as a ServiceJourney (usually connected to a Line), used by a JourneyPattern with one or more DayType (describing dates or periods). The ServiceJourney describes the times of arrival and departure along the journey by use of StopPointInJourneyPattern for stop, with a PassingTime defining the exact times.

NeTEx conceptual model for ServiceJourney

When the nature of the service requires a permanent ID per service, e.g. with tickets associated to a specific departure on a specific day, rather than having a loose coupling to a ServiceJourney with multiple associated DayTypes these should be defined as individual DatedServiceJourneys with an associate ServiceJourney specifying the nature of the service and an  OperatingDay defining on which date it is serviced. Should such a DatedServiceJourney be replanned or replaced, (a) new DatedServiceJourney(s) referencing the originally planned DatedServiceJourney should be specified.

NeTEx conceptual model for DatedServiceJourney

Deviations

When describing a deviation from the common departure pattern, the OperatingDay, can be described in inverse by define the particular day(s) as unavailable.

Data enrichment

As mentioned above, a trip can be specified on several levels in NeTEx, ranging from the parent Route via detailed JourneyPattern down to the individual ServiceJourney.

The goal of the Norwegian NeTEx profile is to place all elements as high up in the structure as possible, in order to avoid redundancies.

Conceptual model for enrichment of data in NeTEx