Timetables

In this chapter:

• TimetableFrame
• ServiceJourney
• TemplateServiceJourney
• OccupancyView
• TrainNumber
• TypeOfService
• TimetabledPassingTime
• ServiceJourneyInterchange
• InterchangeRule

In Service:

• NoticeAssignment
• ServiceFacilitySet

In ServiceCalender:

• AvailabilityCondition
• Timeband

TimetableFrame

→ Glossary definition

Purpose

A TimetableFrame contains the operational journey definitions — the actual trips that run on the network. It groups ServiceJourneys, TemplateServiceJourneys, and ServiceJourneyInterchange that together describe the timetabled service offering.

Contained Elements

• vehicleJourneys– collection of journey types:
  • ServiceJourney- describes an individual timetabled journey
  • TemplateServiceJourney- describes a set of journeys repeating at a certain frequency
  • The Swiss profile only models journeys that are available to the passengers
• TrainNumber- each ServiceJourney and TemplateServiceJourney is mapped one-to-one to exactly one train number
• passingTimes- describe the times of vehicles at points in their journey
• journeyInterchanges – collection of ServiceJourneyInterchanges describing planned connections and through-services between journeys
• NoticeAssignments- link Notices to specific journeys or stop points within journeys
• ServiceFacilitySets- describe the various services and facilities offered by the vehicles of a journey

Table

Sub	Element	Usage	Card	Type	Description	Note
+	vehicleJourneys	expected	1..1	unknown		Contains the ServiceJourneys and TemplateServiceJourneys.
++	ServiceJourney	expected	1..1	unknown		ServiceJourney is used for common Journeys.
++	TemplateServiceJourney	expected	1..1	unknown		TemplateServiceJourney is only to be used if a line is serviced at a certain frequency.
+	trainNumbers	expected	1..1	unknown
++	TrainNumber	mandatory	1..1	unknown
+	serviceFacilitySets	optional	1..1	unknown
++	ServiceFacilitySet	expected	1..1	unknown
+	typesOfService	expected	1..1	unknown
++	TypeOfService	optional	1..1	unknown		This is exactly how the TypeOfService should be defined for Switzerland. Attention: Only once per file.
+	journeyInterchanges	optional	1..1	unknown
++	ServiceJourneyInterchange	expected	1..1	unknown		For modeling many forms of interchanges
+	interchangeRules	expected	1..1	unknown
++	InterchangeRule	expected	1..1	unknown

→ General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<TimetableFrame  id="ch:1:TimetableFrame:j23" version="1">
  <vehicleJourneys>
    <!-- Contains the ServiceJourneys and TemplateServiceJourneys. -->
    <ServiceJourney id="generatedOrsjyid" version="1">
      <!-- ServiceJourney is used for common Journeys. -->
    </ServiceJourney>
    <TemplateServiceJourney id="generatedOrsjyid1" version="1">
      <!-- TemplateServiceJourney is only to be used if a line is serviced at a certain frequency. -->
    </TemplateServiceJourney>
    <TemplateServiceJourney id="generated2" version="1"/>
  </vehicleJourneys>
  <trainNumbers>
    <TrainNumber id="2123" version="1"/>
  </trainNumbers>
  <serviceFacilitySets>
    <ServiceFacilitySet id="86558" version="1"/>
  </serviceFacilitySets>
  <typesOfService>
    <TypeOfService id="ch:1:TypeOfService:1" version="1">
      <!-- This is exactly how the TypeOfService should be defined for Switzerland. Attention: Only once per file. -->
      <Name lang="en">PublicJourney</Name>
      <ShortName lang="en">PJ</ShortName>
      <PrivateCode>1</PrivateCode>
    </TypeOfService>
  </typesOfService>
  <journeyInterchanges>
    <ServiceJourneyInterchange id="ch:1:sji:generated-1" version="1">
      <!-- For modeling many forms of interchanges -->
      <FromJourneyRef ref="sjyid-1" version="1"/>
      <ToJourneyRef ref="sjyid-2" version="1"/>
    </ServiceJourneyInterchange>
  </journeyInterchanges>
  <interchangeRules>
    <InterchangeRule id="ch:1:InterchangeRule:1" version="1"/>
  </interchangeRules>
</TimetableFrame>

→ Template

Frame Relationships

TimetableFrame depends on ServiceFramefor JourneyPatterns and Lines referenced by ServiceJourneys. It depends on ResourceFrame for Operator definitions. VehicleScheduleFrame may reference journeys defined here for block and duty scheduling. TimetableFrame is typically wrapped in a CompositeFramewithin a PublicationDelivery.

ServiceJourney

→ Glossary definition

Purpose

A ServiceJourney represents a planned trip in the timetable operating on a recurring schedule. It defines the stop sequence via reference to a JourneyPattern, includes scheduled passing times, and specifies operational details such as operator and days of operation. Unlike DatedServiceJourney, which represents a concrete instance on a specific date, ServiceJourney is the reusable template used across multiple dates via DayType definitions

Table

Sub	Element	Usage	Card	Type	Description	Note
+	validityConditions	mandatory	1..1	unknown		Used to specify a set of temporal conditions that can be associated with the ServiceJourney, for example that the corresponding journey only applies on particular days of a period (indicated by ValidDayBits, “Verkehrstagebitfeld”).
++	AvailabilityCondition	mandatory	1..1	unknown		Only a single occurence is allowed. The following elements are mandatory here, any other elements of AvailabilityCondition are not allowed or will be ignored.
+	keyList	expected	1..1	unknown		KEY LIST with the KEY VALUEs belonjing to the SERVICE JOURNEY. Will contain the SJYID.
++	KeyValue	mandatory	1..1	unknown		A KeyValue pair with the Key SJYID must exist. The Value contains a valid Swiss Journey ID.
+++	Key	mandatory	1..1	unknown
+++	Value	mandatory	1..1	unknown
+	privateCodes	expected	1..1	unknown
++	PrivateCode	expected	1..1	unknown
+	Extensions	optional	1..1	unknown		Used to indicate Facility changes.
++	facilities	optional	1..1	unknown
+++	Facility	optional	1..1	unknown
++++	ServiceFacilitySetRef	mandatory	1..1	unknown
+	TransportMode	optional	1..1	unknown
+	TypeOfProductCategoryRef	mandatory	1..1	unknown
+	TypeOfServiceRef	optional	1..1	unknown
+	noticeAssignments	optional	1..1	unknown		The complete set of all applicable notices. Attention: Notices may be restricted to a given set of stops.
++	NoticeAssignment	optional	1..1	unknown
+	occupancies	optional	1..1	unknown
++	OccupancyView	optional	1..1	unknown
+	ServiceAlteration	mandatory	1..1	unknown		Only the value planned is allowed.
+	DepartureTime	expected	1..1	unknown
+	DepartureDayOffset	optional	1..1	unknown
+	TimeDemandTypeRef	mandatory	1..1	unknown		The timing behaviour is defined here. We allow only one TimeDemandType per ServiceJourney.
+	LineRef	mandatory	1..1	unknown
+	DirectionType	mandatory	1..1	unknown		Allowed are: inbound, outbound
+	trainNumbers	mandatory	1..1	unknown
++	TrainNumberRef	mandatory	1..1	unknown
+	Destination	expected	1..1	unknown
+	parts	optional	1..1	unknown		For some use cases e.g. change of Facilities during ServiceJourney
++	JourneyPartRef	expected	1..1	unknown

→ General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<ServiceJourney  id="generated" version="1">
  <validityConditions>
    <!-- Used to specify a set of temporal conditions that can be associated with the ServiceJourney, for example that the corresponding journey only applies on particular days of a period (indicated by ValidDayBits, “Verkehrstagebitfeld”). -->
    <AvailabilityCondition id="generated" version="1">
      <!-- Only a single occurence is allowed. The following elements are mandatory here, any other elements of AvailabilityCondition are not allowed or will be ignored. -->
      <FromDate>2026-05-17T00:00:00Z</FromDate>
      <!-- Is equal to the start date of the timetable year or, more generally, the period in which the ValidDayBits apply. -->
      <ToDate>2026-05-17T00:00:00Z</ToDate>
      <!-- Is equal to the end date of the timetable year or, more generally, the period in which the ValidDayBits apply. -->
      <ValidDayBits>01010111</ValidDayBits>
    </AvailabilityCondition>
  </validityConditions>
  <keyList>
    <!-- KEY LIST with the KEY VALUEs belonjing to the SERVICE JOURNEY. Will contain the SJYID. -->
    <KeyValue>
      <!-- A KeyValue pair with the Key SJYID must exist. The Value contains a valid Swiss Journey ID. -->
      <Key>SJYID</Key>
      <Value>ch:1:sjyid:100001:71707-003</Value>
    </KeyValue>
  </keyList>
  <privateCodes>
    <PrivateCode type="sjyid">ch:1:sjyid:100001:71707-003</PrivateCode>
  </privateCodes>
  <Extensions>
    <!-- Used to indicate Facility changes. -->
    <facilities>
      <Facility id="ch:1:facility:f1" version="1">
        <validityConditions>
          <AvailabilityConditionRef ref="ch:1:AvailabilityCondition:c3" version="1"/>
        </validityConditions>
        <ServiceFacilitySetRef ref="ch:1:ServiceFacilitySet:A___1" version="1"/>
      </Facility>
    </facilities>
  </Extensions>
  <TransportMode>rail</TransportMode>
  <TypeOfProductCategoryRef ref="ch:1:TypeOfProductCategory:IR" version="1"/>
  <TypeOfServiceRef ref="ch:1:TypeOfService:1" version="1"/>
  <noticeAssignments>
    <!-- The complete set of all applicable notices. Attention: Notices may be restricted to a given set of stops. -->
    <NoticeAssignment id="ch:1:NoticeAssignment:ch_1_ServiceJourney_ch_1_sjyid_100001_71707-003_1_0" version="1">
      <validityConditions>
        <AvailabilityConditionRef ref="ch:1:AvailabilityCondition:c3" version="1"/>
      </validityConditions>
      <NoticeRef ref="ch:1:Notice:A___1" version="1"/>
    </NoticeAssignment>
  </noticeAssignments>
  <occupancies>
    <OccupancyView id="generated" version="1"/>
  </occupancies>
  <ServiceAlteration>planned</ServiceAlteration>
  <!-- Only the value planned is allowed. -->
  <DepartureTime>06:21:00</DepartureTime>
  <DepartureDayOffset>0</DepartureDayOffset>
  <TimeDemandTypeRef ref="generated" version="1">
    <!-- The timing behaviour is defined here. We allow only one TimeDemandType per ServiceJourney. -->
  </TimeDemandTypeRef>
  <LineRef ref="ch:2:Line:11.IR.90" version="1"/>
  <DirectionType>outbound</DirectionType>
  <!-- Allowed are: inbound, outbound -->
  <trainNumbers>
    <TrainNumberRef ref="ch:1:TrainNumber:71707" version="1"/>
  </trainNumbers>
  <Destination>
    <ScheduledStopPointRef ref="ch:1:sloid:3412" version="1"/>
  </Destination>
  <parts>
    <!-- For some use cases e.g. change of Facilities during ServiceJourney -->
    <JourneyPartRef ref="generated" version="1"/>
  </parts>
</ServiceJourney>

→ Template

Usage Notes

• Template vs. Instance: ServiceJourney is the template; DatedServiceJourney represents concrete daily instances.
• Consistency: A ServiceJourney must reference exactly one JourneyPattern. The pattern’s stop sequence is authoritative.
• Stop Times: Each stop in the referenced JourneyPattern must have exactly one TimetabledPassingTimes entry with ArrivalTime and/or DepartureTime.
• Day Governance: DayType references control on which days the journey operates; per-date deviations belong to DatedServiceJourney.
• Validation: Ensure JourneyPatternRef, LineRef, and OperatorRef are consistent and reference existing objects.
• We assume that a swiss journey exists for almost every ServiceJourney. In those cases the id is also set to the sjyid. Possible problematic cases: some cableways, when the frequency group is not done right (we try to remove those cases), foreign journeys. In those cases the id will contain a _gen substring.
• A ServiceJourneycan be associated with exactly one ServiceJourneyPattern and TimeDemandType.
• id-attribute needs to be kept stable between exports.

TemplateServiceJourney

→ Glossary definition

Purpose

A TemplateServiceJourney represents a sequence of planned trips. It is similar to the ServiceJourney, but it is used if there is a frequency defined at which the trips are scheduled on an operating day.

A frequency is specified in a HeadwayJourneyGroup (e.g. every 20 minutes). The TemplateServiceJourney may thus represent multiple journeys or it could be used simply as a template for adding extra date journeys after the planning phase.

Table

Sub	Element	Usage	Card	Type	Description	Note
+	validityConditions	expected	1..1	unknown		Used to specify a set of temporal conditions that can be associated with the TemplateServiceJourney, for example that the corresponding journey only applies on particular days of a period (indicated by ValidDayBits, “Verkehrstagebitfeld”).
++	AvailabilityCondition	mandatory	1..1	unknown		More spacific requirements than standard AvailabilityCondition. Only a single occurence is allowed. The following elements are mandatory here, any other elements of AvailabilityCondition are not allowed or will be ignored.
+	keyList	mandatory	1..1	unknown		Key list for the repeating journeys. Contains the SJYID.
++	KeyValue	mandatory	1..1	unknown		A KeyValue pair with the key SJYID must exist. The Value contains a valid Swiss Journey ID.
+++	Key	mandatory	1..1	unknown
+++	Value	mandatory	1..1	unknown
+	privateCodes	expected	1..1	unknown		Replaces the single PrivateCode.
++	PrivateCode	expected	1..1	unknown
+	TransportMode	optional	1..1	unknown
+	TypeOfProductCategoryRef	expected	1..1	unknown
+	TypeOfServiceRef	optional	1..1	unknown
+	noticeAssignments	optional	1..1	unknown		The complete set of all applicable notices. Attention: Notices may be restricted to a given set of stops.
++	NoticeAssignment	optional	1..1	unknown
+	occupancies	optional	1..1	unknown
++	OccupancyView	optional	1..1	unknown
+	ServiceAlteration	mandatory	1..1	unknown		Only the value planned is allowed.
+	DepartureTime	optional	1..1	unknown		Departure of the first journey.
+	DepartureDayOffset	optional	1..1	unknown		DayOffset if relevant.
+	LineRef	mandatory	1..1	unknown
+	DirectionType	optional	1..1	unknown		Allowed are: inbound, outbound
+	trainNumbers	mandatory	1..1	unknown
++	TrainNumberRef	mandatory	1..1	unknown
+	Destination	expected	1..1	unknown
+	parts	optional	1..1	unknown		For some use cases e.g. change of Facilities during ServiceJourney
++	JourneyPartRef	expected	1..1	unknown
+	TemplateVehicleJourneyType	expected	1..1	unknown
+	frequencyGroups	mandatory	1..1	unknown		We strictly map one frequency to the TemplateServiceJourney.
++	HeadwayJourneyGroup	mandatory	1..1	unknown
+++	ScheduledHeadwayInterval	mandatory	1..1	unknown
+++	HeadwayDisplay	optional	1..1	unknown		Allowed values: displayPassingTimesOnly displayInsteadOfPassingTimes displayAsWellAsPassingTimes. We only export displayPassingTimesOnly.

→ General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<TemplateServiceJourney  id="generated" version="1">
  <!-- TemplateServiceJourney is used for journeys repeating at a certain frequency. -->
  <validityConditions>
    <!-- Used to specify a set of temporal conditions that can be associated with the TemplateServiceJourney, for example that the corresponding journey only applies on particular days of a period (indicated by ValidDayBits, “Verkehrstagebitfeld”). -->
    <AvailabilityCondition id="generated" version="1">
      <!-- More spacific requirements than standard AvailabilityCondition. Only a single occurence is allowed. The following elements are mandatory here, any other elements of AvailabilityCondition are not allowed or will be ignored. -->
      <FromDate>2026-05-17T00:00:00Z</FromDate>
      <!-- Is equal to the start date of the timetable year or, more generally, the period in which the ValidDayBits apply. -->
      <ToDate>2026-05-17T00:00:00Z</ToDate>
      <!-- Is equal to the end date of the timetable year or, more generally, the period in which the ValidDayBits apply. -->
      <ValidDayBits>01010111</ValidDayBits>
    </AvailabilityCondition>
  </validityConditions>
  <keyList>
    <!-- Key list for the repeating journeys. Contains the SJYID. -->
    <KeyValue>
      <!-- A KeyValue pair with the key SJYID must exist. The Value contains a valid Swiss Journey ID. -->
      <Key>SJYID</Key>
      <Value>ch:1:sjyid:100001:71707-003</Value>
    </KeyValue>
  </keyList>
  <privateCodes>
    <!-- Replaces the single PrivateCode. -->
    <PrivateCode type="sjyid">ch:1:sjyid:100001:71707-003</PrivateCode>
  </privateCodes>
  <TransportMode>rail</TransportMode>
  <TypeOfProductCategoryRef ref="ch:1:TypeOfProductCategory:IR" version="1"/>
  <TypeOfServiceRef ref="ch:1:TypeOfService:1" version="1"/>
  <noticeAssignments>
    <!-- The complete set of all applicable notices. Attention: Notices may be restricted to a given set of stops. -->
    <NoticeAssignment id="ch:1:NoticeAssignment:ch_1_ServiceJourney_ch_1_sjyid_100001_71707-003_1_0" version="1">
      <validityConditions>
        <AvailabilityConditionRef ref="ch:1:AvailabilityCondition:c3" version="1"/>
      </validityConditions>
      <NoticeRef ref="ch:1:Notice:A___1" version="1"/>
    </NoticeAssignment>
  </noticeAssignments>
  <occupancies>
    <OccupancyView id="generated" version="1"/>
  </occupancies>
  <ServiceAlteration>planned</ServiceAlteration>
  <!-- Only the value planned is allowed. -->
  <DepartureTime>06:21:00</DepartureTime>
  <!-- Departure of the first journey. -->
  <DepartureDayOffset>0</DepartureDayOffset>
  <!-- DayOffset if relevant. -->
  <LineRef ref="ch:2:Line:11.IR.90" version="1"/>
  <DirectionType>inbound</DirectionType>
  <!-- Allowed are: inbound, outbound -->
  <trainNumbers>
    <TrainNumberRef ref="ch:1:TrainNumber:71707" version="1"/>
  </trainNumbers>
  <Destination>
    <Name lang="de">Wollishofen</Name>
    <ScheduledStopPointRef ref="ch:1:sloid:3412" version="1"/>
    <DestinationDisplayRef ref="generated" version="1"/>
    <PlaceRef ref="ch:1:sloid:3412" version="1"/>
  </Destination>
  <parts>
    <!-- For some use cases e.g. change of Facilities during ServiceJourney -->
    <JourneyPartRef ref="generated" version="1"/>
  </parts>
  <TemplateVehicleJourneyType>headway</TemplateVehicleJourneyType>
  <frequencyGroups>
    <!-- We strictly map one frequency to the TemplateServiceJourney. -->
    <HeadwayJourneyGroup version="1" id="ch:1:HeadwayJourneyGroup:432">
      <Name>Regular Interval service between 12am and 18:00 pm</Name>
      <Description>About every 20 minutes</Description>
      <FirstDepartureTime>12:00:00</FirstDepartureTime>
      <FirstDayOffset>0</FirstDayOffset>
      <LastDepartureTime>18:00:00</LastDepartureTime>
      <LastDayOffset>0</LastDayOffset>
      <ScheduledHeadwayInterval>PT20M</ScheduledHeadwayInterval>
      <HeadwayDisplay>DisplayInsteadOfPassingTimes</HeadwayDisplay>
      <!-- Allowed values: displayPassingTimesOnly displayInsteadOfPassingTimes displayAsWellAsPassingTimes. We only export displayPassingTimesOnly. -->
    </HeadwayJourneyGroup>
  </frequencyGroups>
</TemplateServiceJourney>

→ Template

Usage Notes

• HeadwayJourneyGroup holds all the frequency-based information of the journey, as for example when the stops of the journey are serviced the first/last time and in what interval (or at which frequency, respectively).
• Note that in addition to HeadwayJourneyGroup, standard NeTEx also features RhythmicalJourneyGroup to specifiy, e.g., departures at 15, 27 and 40 minutes past the hour - this is not used in the Swiss profile.
• For sjyid see information about frequencies.
• id-attribute needs to be kept stable between exports.

OccupancyView

Purpose

OccupancyViewcan be used on the Journey, JourneyPart, and TimetabledPassingTime elements. Used for predicted and planned occupancies of vehicles.

Table

Sub	Element	Usage	Card	Type	Description	Note
+	dayTypeRefs	optional	1..1	unknown
++	DayTypeRef	optional	1..1	unknown
+	dayTypes	expected	1..1	unknown
++	DayType	expected	1..1	unknown
+	FareClass	expected	1..1	unknown
+	OccupancyLevel	expected	1..1	unknown		Niedrige Belegung: empty; mittlere Belegung: manySeatsAvailable; hohe Belegung: fewSeatsAvailable
+	GroupReservation	optional	1..1	unknown
++	NameOfGroup	expected	1..1	unknown
++	NumberOfReservedSeats	expected	1..1	unknown

→ General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<OccupancyView  id="generated" version="1">
  <dayTypeRefs>
    <DayTypeRef ref="generated" version="1"/>
  </dayTypeRefs>
  <dayTypes>
    <DayType id="generated" version="1"/>
  </dayTypes>
  <FareClass>firstClass</FareClass>
  <OccupancyLevel>seatsAvailable</OccupancyLevel>
  <!-- Niedrige Belegung: empty; mittlere Belegung: manySeatsAvailable; hohe Belegung: fewSeatsAvailable -->
  <GroupReservation>
    <NameOfGroup lang="fr">Gymnase français de Bienne&gt;</NameOfGroup>
    <NumberOfReservedSeats>21</NumberOfReservedSeats>
  </GroupReservation>
</OccupancyView>

→ Template

Usage Notes

We currently don’t use OccupancyView.

TrainNumber

→ Glossary definition

Purpose

Codes assigned to particular journeys (ServiceJourney, TemplateServiceJourney) when operated by trains. ServiceJourneys can in principle have multiple different TrainNumbers whereas a JourneyPart can only reference a single one.

Table

Sub	Element	Usage	Card	Type	Description	Note
+	Description	optional	1..1	unknown
+	ForAdvertisement	optional	1..1	unknown		TRAIN NUMBER to use for advertisement to public. Use iff different from ID.
+	ForProduction	optional	1..1	unknown		TRAIN NUMBER to use for production purposes, for instance towards technical systems that require an odd or even value according to safety regulations. Use iff different from ID.

→ General NeTEx definition

### Example

<?xml version="1.0" encoding="UTF-8"?>
<TrainNumber  id="71707" version="1">
  <!-- The TRAIN NUMBERs are currently a maximum of 6 digits long. TRAIN NUMBERs for advertisment und production are identical. -->
  <Description>Information about the train</Description>
  <ForAdvertisement>12311A</ForAdvertisement>
  <!-- TRAIN NUMBER to use for advertisement to public. Use iff different from ID. -->
  <ForProduction>12311A</ForProduction>
  <!-- TRAIN NUMBER to use for production purposes, for instance towards technical systems that require an odd or even value according to safety regulations. Use iff different from ID. -->
</TrainNumber>

→ Template

Usage Note

• id-attribute needs to be kept stable between exports.

TypeOfService

Purpose

TypeOfService indicates the purpose of a ServiceJourney, for example, whether if it is a passenger transport or a garage run-in. We only use ch:1:TypeOfService:1

Table

Sub	Element	Usage	Card	Type	Description	Note
	TypeOfService	expected	1..1	unknown
+	Name	mandatory	1..1	unknown
+	ShortName	mandatory	1..1	unknown
+	PrivateCode	mandatory	1..1	unknown

→ General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<TypeOfService  id="ch:1:TypeOfService:1" version="1">
  <Name lang="en">PublicJourney</Name>
  <ShortName lang="en">N</ShortName>
  <PrivateCode>1</PrivateCode>
</TypeOfService>

→ - Template

Usage Notes

• id-attribute needs to be kept stable between exports.

The following types are currently used:

Name	Description
PublicJourney	A public passenger transport
GarageRunOut	A garage run-out
GarageRunIn	A garage run-in
ThroughCoach	A special type of public passenger transport that is used if a ServiceJourney is comprised of JourneyParts of other ServiceJourneys because of coupling.

Actually there is only one allowed value that we use in the Swiss profile: Only the PublicJourney is to be exchanged.

TimetabledPassingTime

→ Glossary definition

We don’t use TimetabledPassingTime. We will remove this. We use TimeDemandType now.

Purpose

Long-term planned time data concerning public transport vehicles passing a particular PointInJourneyPattern on a specified vehicle journey for a certain DayType.

Table

TimetabledPassingTime.md

→ General NeTEx definition

Example

TimetabledPassingTime.xml

→ Template

Usage Notes

• Note that for journeys lasting more than one day, DayOffset is available.
• If DepartureTime is not on the same day as ArrivalTime this information will be provided using WaitingTime.
• We use sjyid whenever possible as the attribute. However, there are different types of ServiceJourneys that don’t have one:
  • foreign ServiceJourneys
  • perhaps some touristic offers
  • frequency-based journeys that are wrongly modeled in HRDF (will be removed)
• We store the sjyid in different places id, privateCodes/PrivateCode, KeyList. This allows different importing systems to find the sjyid.

ServiceJourneyInterchange

→ Glossary definition

Purpose

The standard states: “In some cases, a SERVICE JOURNEY INTERCHANGE expresses an interchange between two SERVICE JOURNEYs specifically planned to be operated by the same physical vehicle. This concept is for instance used for circular lines and coupled journeys. This means that passenger information should be adapted to the fact that the passenger should not change vehicle as the transfer is implicit. In this case it is also important that operation control staff is aware of the consequences to passengers if the operation is altered in such a way that two different vehicles are used for the two involved SERVICE JOURNEYs.”

StaySeated=true should be used for through-services (Durchbindung) and joining (Vereinigung). While splitting (Flügelzug) technically involves different vehicle parts, the passenger does not leave the train — however, they may need to move to the correct coach. For splitting, StaySeated=false combined with ChangeWithinVehicle=true is therefore the correct modelling. See uc02 Joining and splitting.

Table

Sub	Element	Usage	Card	Type	Description	Note
	ServiceJourneyInterchange	mandatory	1..1	unknown
+	validityConditions	expected	1..1	unknown
++	AvailabilityConditionRef	expected	1..1	unknown
+	Description	optional	1..1	unknown
+	StaySeated	mandatory	1..1	unknown
+	CrossBorder	optional	1..1	unknown
+	Planned	optional	1..1	unknown
+	Guaranteed	optional	1..1	unknown
+	MaximumWaitTime	optional	1..1	unknown		If not set or PT0M, it is guaranteed.
+	FromPointRef	mandatory	1..1	unknown
+	FromVisitNumber	optional	1..1	unknown
+	ToPointRef	mandatory	1..1	unknown
+	FromServiceJourneyRef	mandatory	1..1	unknown
+	ToServiceJourneyRef	mandatory	1..1	unknown

→ General NeTEx definition

Example

• Example snippet

→ Template

Usage Notes

• ServiceJourneyInterchange is placed in the TimetableFrame within the journeyInterchanges collection.
• StaySeated=true indicates that the passenger remains in the vehicle — typically used for through-services (Durchbindung), splitting (Flügelzug) and joining (Vereinigung). See uc01 Durchbindung.
• StaySeated=false indicates that the passenger must change vehicles. This covers guaranteed and non-guaranteed connections. See uc03 Transfers.
• Guaranteed=true explicitly marks the connection as guaranteed.
• MaximumWaitTime defines how long the distributor waits — if absent, no explicit wait time is defined.
• CrossBorder=true must be set if the interchange crosses a national border.
• ChangeWithinVehicle=true indicates that in case of train splitting, the passenger may have to move to a different part of the train. Default is false. See uc02 Joining and splitting
• FromPointRef and ToPointRef reference the ScheduledStopPoint at which the interchange takes place. For a line change at the same stop, both refs point to the same ScheduledStopPoint.
• FromServiceJourneyRef references the feeder journey; ToServiceJourneyRef references the distributor journey. Note: the deprecated elements FromJourneyRef / ToJourneyRef from RG 1.0 (JourneyMeeting) must not be used.
• Element order must follow the XSD sequence: StaySeated → CrossBorder → ChangeWithinVehicle → MaximumWaitTime → FromPointRef / ToPointRef → FromServiceJourneyRef / ToServiceJourneyRef.
• Make sure not to generate identical ServiceJourneyInterchanges. Reuse them where possible.
• id-attribute should be kept stable between exports.

InterchangeRule

⚠️ Deprecated — InterchangeRule is replaced by ServiceJourneyInterchange in RG 2.0.
See uc03 Transfers for the current modelling approach.

→ Glossary definition

AvailabilityCondition

→ see ServiceCalenderFrame

Timeband

→ see ServiceCalenderFrame

NoticeAssignment

→ see Common elements

ServiceFacilitySet

→ see Common elements