Example: DRT "Mosti" in NeTEx

The "Mosti" is a demand traffic that runs between Amstetten (Austria) and some surrounding communities.
It is a non-trivial example with a few special features:
The offer is defined as a relationship between the “AST area” Amstetten and two "zones". Each zone consists of several communities.
The municipalities contain regular stops and assembly points as start and finish points, address-specific operation is possible as the destination of the journey, but not as the start.
There are specific departures that apply to all municipalities in a zone, some travel options only exist in certain municipalities and on certain traffic days.

 

Transport offer:


The transport offer is modeled as a FlexibleLine. Booking contact and booking conditions
are stored here, but can also be overridden per trip.

 

The operating modes are modeled via TypeOfFlexibleService (suggestion from VDV 462):

Area of Service:

 

The service areas are “CITY AST Amstetten” and "Zone 1" and "Zone 2". They are defined as
FlexibleStopPlace

 

The communities served are shown as FlexibleArea for each zone. FlexibleArea is a child object
from FlexibleStop

Stops and rallying points:

There are regular stops and "rallying points" in the municipalities. These are considered a normal
StopPlaceElement and arge assigned to the operating area via ParentZoneRef. Via TypeOfPlaceRef is differentiated between rallying points and stops.

 

On-demand traffic routes

The permitted or possible connections in the service area are similar to a route of a normal (bus)trip and therefore mapped as ServiceJourneyPattern.

 

In order to make this possible, “representative” stoppoints must be in NeTEx for each FlexibleArea -->
defined as ScheduledStopPoint…

…... and they have to be assigned to the FlexibleAreas:

 

Travel Times:

The (estimated) travel times between the service areas can now also be assigend in
ServiceJourneyPattern (Element JourneyRunTime)

 

In order for this to be possible, ServiceLink and TimingLink elements must be assigend between the areas or their representative points:

 

Route Options:

Every specific departure in the service area is modeled as a ServiceJourney with departure time and
Reference to ServiceJourneyPattern (route). The distinction from regular journeys is only made
through FlexibleLineRef and FlexibleServiceProperties. The validity (days of operation) is the same as for regular Trips and is described via AvailabilityConditionRef or via DaytypeRef.

If, instead of specific departures, only a time range for operation is specified, this is indicated via a
"TimeBand" element, which is embedded in AvailabilityCondition.
The following picture shows an example of an offer, which is Friday and Saturday night from 10:00 pm
is available until 1:00 a.m:

 

Days of operation:

The specific days of operation are assigned in AvailabilityCondition as a bit string