Service Frame

In this chapter:

• ServiceFrame
• Line
• GroupOfLines
• DestinationDisplay
• ScheduledStopPoint
• PassengerStopAssignment
• LATER PassengerBoardingPositionAssignment
• DefaultConnection
• SiteConnection
• TimingLink
• ServiceJourneyPattern
• TimeDemandType
• Notice
• NoticeAssignment

ServiceFrame

→ Glossary definition

Purpose

Contains the network and line definitions - Lines, ScheduledStopPoints, DestinationDisplays, and PassengerStopAssignments.

See the following class diagram for the most important objects of the ServiceFrame and their relationships to the other frames.

classDiagram
    %% Styles
    classDef frame fill:#FFF8E1,stroke:#FFB300;
    classDef contained fill:#E8F4FF,stroke:#1E90FF;
    classDef external fill:#F6F6F6,stroke:#AAAAAA;

    %% Frame
    class ServiceFrame {
    }

    %% Contained elements
    class Line {

        
    }

    class DestinationDisplay {


    }

    class ScheduledStopPoint {
    }

    class PassengerStopAssignment {
    }

    class PassengerBoardingPositionAssignment {
    }

    class DefaultConnection {
    }

    class SiteConnection {
    }

    class Notice {
    }

class ServiceJourney {

}
    class NoticeAssignment {
    }
    %% Containment relations (only contained elements)
    ServiceFrame "1" o-- "0..*" Line : contains
    ServiceFrame "1" o-- "0..*" DestinationDisplay : contains
    ServiceFrame "1" o-- "0..*" ScheduledStopPoint : contains
    ServiceFrame "1" o-- "0..*" PassengerStopAssignment : contains
    ServiceFrame "1" o-- "0..*" PassengerBoardingPositionAssignment : contains
    ServiceFrame "1" o-- "0..*" DefaultConnection : contains
    ServiceFrame "1" o-- "0..*" SiteConnection : contains
    ServiceFrame "1" o-- "0..*" Notice : contains
    ServiceFrame "1" o-- "0..*" NoticeAssignment : contains

    %% external references
    ServiceJourney "1" -- "1" Line : references
    ServiceJourney "1" -- "0..1" DestinationDisplay : references
    ServiceJourney "1" -- "0..*" NoticeAssignment : contains

    PassengerStopAssignment "1" -- "1" StopPlace : references
    PassengerStopAssignment "1" -- "0..1" Quay : references
    PassengerStopAssignment "1" -- "1" ScheduledStopPoint : references

Figure: Elements in ServiceFrame

Contained Elements

The ServiceFrame model comprises among others:

• Line network model: overall topology of the Line and line sections that make up a transport network.
• Service pattern model: ScheduledStopPoints, ServiceLink, i.e., points and links referenced by schedules.

Other important classes of the ServiceFrame include:

• PassengerStopAssignments and PassengerBoardingPositionAssignment which model the relationship between stops in the timetable and the physical platforms of an actual station or other stop.
• Connections (DefaultConnection, SiteConnection, TimingLink) as the topological model of interchanges. They model the possibility of a transfer between two ScheduledStopPoints.
• Notices which are then assigned to ServiceJourney (in the TimetableFrame) and StopPointInJourneyPattern (in the ServiceFrame) through NoticeAssignments. They model the association of footnotes and passenger information content such as stop announcements and the network.

Table

A minimal ServiceFrame must be present in all timetable files.

Table: ServiceFrame

Sub	Element	Usage	Card	Type	Description	Note
	@id	mandatory	1..1	xsd:string	Attribute id
	@version	mandatory	1..1	xsd:string	Attribute version
	lines	mandatory	0..1	lineRefs_RelStructure	LINEs in frame.	Only Line is used and not FlexibleLine
+	Line	mandatory	0..*	Line_VersionStructure	A group of ROUTEs which is generally known to the public by a similar name or number.
	groupsOfLines	expected	0..1	groupsOfLinesInFrame_RelStructure	GROUPs of LINEs in frame.
+	GroupOfLines	expected	1..*	GroupOfLines_VersionStructure	A grouping of LINEs which will be commonly referenced for a specific purpose.	We use GroupOfLine for the modeling of mixed lines
	destinationDisplays	expected	0..1	destinationDisplayRefs_RelStructure	DESTINATION DISPLAYs in frame.
+	DestinationDisplay	expected	1..*	DestinationDisplay_VersionStructure	An advertised destination of a specific JOURNEY PATTERN, usually displayed on a head sign or at other on-board locations.	We only allow DestinationDisplay based on Name and not on reference to a ScheduledStopPoint
	scheduledStopPoints	expected	0..1	scheduledStopPointsInFrame_RelStructure	SCHEDULED STOP POINTs in frame.	Swiss ScheduledStopPoint are using the SLOID in the id, when possible.
+	ScheduledStopPoint	mandatory	0..*	unknown	A POINT where passengers can board or alight from vehicles. It is open, which hierarchical level such a point has. It can represent a single door (BoardingPosition) or a whole ZONE. The association to the physical model is done with STOP ASSIGNMENTs.	The id of the ScheduledStopPoint is a SLOID if one exists. Otherwisse it contains a gen part.
	connections	expected	0..1	transfersInFrame_RelStructure	CONNECTIONs in frame.	connections is used in SITE_OFFER, but not in NETWORK_OFER
+	SiteConnection	expected	0..*	SiteConnection_VersionStructure	The physical (spatial) possibility to connect from one point to another in a SITE.	SiteConnection are used only in the SITE_OFFER file and not in NETWORK_OFFER files.
+	DefaultConnection	expected	0..*	DefaultConnection_VersionStructure	Specifies the default transfer times to transfer between MODEs and / or OPERATORs within a region.	DefaultConnection is only used in the SITE_OFFER file
	stopAssignments	expected	0..1	stopAssignmentsInFrame_RelStructure	STOP ASSIGNMENTs in frame.
+	PassengerStopAssignment	expected	0..*	PassengerStopAssignment_VersionStructure	The default allocation of a SCHEDULED STOP POINT to a specific STOP PLACE, and also possibly a QUAY and BOARDING POSITION.	Make the link between timetables and site model.
	timingLinks	expected	0..1	timingLinksInFrame_RelStructure	TIMING LINKs in frame.	We use TimingLink as the time behaviour between two ScheduledStopPoints
+	TimingLink	expected	1..*	TimingLink_VersionStructure	An ordered pair of TIMING POINTs for which run times may be recorded. Timing links are directional - there will be separate links for each direction of a route.	every different handling of the link needs a different timing link e.g. bus vs tram
	journeyPatterns	mandatory	0..1	journeyPatternRefs_RelStructure	JOURNEY PATTERNs in frame.
+	ServiceJourneyPattern	mandatory	0..*	ServiceJourneyPattern_VersionStructure	The JOURNEY PATTERN for a (passenger carrying) SERVICE JOURNEY.
	timeDemandTypes	expected	0..1	timeDemandTypeRefs_RelStructure	TIME DEMAND TYPEs in frame.
+	TimeDemandType	expected	1..*	TimeDemandType_VersionStructure	An indicator of traffic conditions or other factors which may affect vehicle run or wait times. It may be entered directly by the scheduler or defined by the use of TIME BANDs.	TimeDemandType is now the core concept to use for the timing behaviour of ServiceJourney.
	notices	expected	0..1	noticesInFrame_RelStructure	NOTICEs in frame.	notices may be present or not
+	Notice	expected	1..*	Notice_VersionStructure	A note or footnote about any aspect of a service, e.g. an announcement, notice, etc. May have different DELIVERY VARIANTs for different media.	if notices are present, one Notice must be.

→ General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<ServiceFrame id="ch:1:ServiceFrame" version="1">
  <!-- A minimal ServiceFrame must be present in all timetable files. -->
  <directions>
    <!-- We don't use directions, but only direction type -->
  </directions>
  <lines>
    <!-- Only Line is used and not FlexibleLine -->
    <Line id="use swiss line id where possible" version="1" responsibilitySetRef="dsa">
      <Name>Name is needed</Name>
    </Line>
    <FlexibleLine id="notUsed" version="none">
      <!-- We work with Line only. -->
    </FlexibleLine>
  </lines>
  <groupsOfLines>
    <GroupOfLines id="generated" version="1">
      <!-- We use GroupOfLine for the modeling of mixed lines -->
      <Name>Group_name</Name>
    </GroupOfLines>
  </groupsOfLines>
  <destinationDisplays>
    <DestinationDisplay id="generated-id" version="1">
      <!-- We only allow DestinationDisplay based on Name and not on reference to a ScheduledStopPoint -->
    </DestinationDisplay>
  </destinationDisplays>
  <scheduledStopPoints>
    <!-- Swiss ScheduledStopPoint are using the SLOID in the id, when possible. -->
    <ScheduledStopPoint id="sloid_where_possible" version="1">
      <!-- The id of the ScheduledStopPoint is a SLOID if one exists. Otherwisse it contains a gen part. -->
    </ScheduledStopPoint>
  </scheduledStopPoints>
  <connections>
    <!-- connections is used in SITE_OFFER, but not in NETWORK_OFER -->
    <SiteConnection id="generated" version="1">
      <!-- SiteConnection are used only in the SITE_OFFER file and not in NETWORK_OFFER files. -->
    </SiteConnection>
    <DefaultConnection id="generated" version="1">
      <!-- DefaultConnection is only used in the SITE_OFFER file -->
    </DefaultConnection>
  </connections>
  <stopAssignments>
    <PassengerStopAssignment id="generated" version="1">
      <!-- Make the link between timetables and site model. -->
    </PassengerStopAssignment>
  </stopAssignments>
  <timingLinks>
    <!-- We use TimingLink as the time behaviour between two ScheduledStopPoints -->
    <TimingLink id="generated" version="1">
      <!-- every different handling of the link needs a different timing link e.g. bus vs tram -->
      <FromPointRef ref="sloid1" version="1"/>
      <ToPointRef ref="sloid 2" version="1"/>
    </TimingLink>
  </timingLinks>
  <journeyPatterns>
    <ServiceJourneyPattern id="generated" version="1"/>
  </journeyPatterns>
  <timeDemandTypes>
    <TimeDemandType id="generated" version="1">
      <!-- TimeDemandType is now the core concept to use for the timing behaviour of ServiceJourney. -->
    </TimeDemandType>
  </timeDemandTypes>
  <timeDemandTypeAssignments>
    <TimeDemandTypeAssignment id="generated" version="1"/>
  </timeDemandTypeAssignments>
  <notices>
    <!-- notices may be present or not -->
    <Notice id="generated" version="1">
      <!-- if notices are present, one Notice must be. -->
    </Notice>
  </notices>
</ServiceFrame>

→ Template

Frame Relationships

ServiceFrame depends on ResourceFrame for Operator definitions. PassengerStopAssignments build the connection between ScheduledStopPoints and the physical model in SiteFrame. ServiceFrame is typically wrapped in a CompositeFrame within a PublicationDelivery.

Direction

We don’t use Direction but only DirectionType. For this we need NeTEx 2.1.

This means that the old two defined dirctions ch:1:Direction:H and ch:1:Direction:R will no longer be supported.

Line

→ Glossary definition

Purpose

A public transport service line with a Name, TransportMode, and Operator. Be aware that the handling of “Konzessionär” and “Betreiber” is a bit complex and is discussed here and here.

Table

For referencing the Operators we redundantly use ResponsibilitySet and OperatorRef. This is to maintain compatibility with different data consumers. See chapter on ResourceFrame and Use Case 17.

Table: Line

Sub	Element	Usage	Card	Type	Description	Note
	@id	mandatory	1..1	xsd:string	Attribute id
	@version	mandatory	1..1	xsd:string	Attribute version
	@responsibilitySetRef	mandatory	1..1	xsd:string	Attribute responsibilitySetRef
	ValidBetween	expected	1..*	unknown		Usually set to the whole timetable year
+	FromDate	expected	0..1	xsd:dateTime	Start date of AVAILABILITY CONDITION.
+	ToDate	expected	0..1	xsd:dateTime	End of AVAILABILITY CONDITION. Date is INCLUSIVE.
	keyList	optional	0..1	KeyListStructure	A list of alternative Key values for an element.
+	KeyValue	optional	1..*	KeyValueStructure	Key value pair for Entity.	We might use KeyValue for some additional information
++	Key	optional	0..1	xsd:normalizedString	User key.
++	Value	optional	0..1	xsd:anyType	Value for alternative key.
	privateCodes	mandatory	0..1	PrivateCodesStructure	A list of private codes that uniquely identifiy the element. May be used for inter-operating with other (legacy) systems. +v2.0	The SLNID is mandatory if it exists
+	PrivateCode	expected	0..*	PrivateCodeStructure	A private code that uniquely identifies the element. May be used for inter-operating with other (legacy) systems.	The SLNID is mandatory if it exists
++	@type	mandatory	1..1	xsd:string	Attribute type
	Name	mandatory	0..1	MultilingualString	Name of VALIDITY CONDITION.	contains attribute D T from HRDF. Is not translated on purpose.
	ShortName	expected	0..1	MultilingualString	Short Name for TYPE OF VALUE.	contains the LinieKurzName (attribut N T in HRDF)
	TransportMode	mandatory	0..1	AllModesEnumeration	An area within a Site. May be connected to Quays by PATH LINKs.
	TransportSubmode	optional	1..1	TransportSubmodeStructure	A submode of a public or private TRANSPORT MODE.	the mapping excel describe how to use the TransportSubmode
+	RailSubmode	optional	1..1	RailSubmodeEnumeration	TPEG pti02 Rail submodes loc13. See also See ERA B.4.7009 - Name: Item description code.	Here an example for rail. Be aware that other XXXSubmode are used for other mode.
	PublicCode	mandatory	0..1	PublicCodeStructure	Public identifier code of TARIFF ZONE. +v2.0	Contains LinieLangName (attribute LT from HRDF)
	OperatorRef	expected	1..1	OperatorRefStructure	Reference to an OPERATOR.	The operator is the transport organisation that really “owns” the line. Additional operators can be added in additionalOperators. The actual operating organisation can be set in the ServiceJourney. Is redundant to the responsibilitySetRef on purpose.
	additionalOperators	optional	0..1	transportOrganisationRefs_RelStructure	Additional OPERATORs for LINE.	Used for other operating companies. Is redundant to the responsibilitySetRef on purpose. this is especially important, when a co-ownership of the Line was defined.
+	OperatorRef	optional	0..*	OperatorRefStructure	Reference to an OPERATOR.
	LineType	expected	0..1	LineTypeEnumeration	Classification of LINE, including flexible options. +v2.0.	Will be used especially, when not “fixed”. Details in mapping excel.
	TypeOfProductCategoryRef	mandatory	1..1	TypeOfProductCategoryRefStructure	Reference to a TYPE OF PRODUCT CATEGORY. Product of a JOURNEY. e.g. ICS, Thales etc See ERA B.4 7037 Characteristic description code.	Always aligned with BS KI oev-info.ch

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<Line id="use swiss line id where possible" version="1" responsibilitySetRef="dsa">
  <!-- For referencing the `Operator`s we redundantly use `ResponsibilitySet` and `OperatorRef`. This is to maintain compatibility with different data consumers. See chapter on ResourceFrame and Use Case 17. -->
  <ValidBetween>
    <!-- Usually set to the whole timetable year -->
    <FromDate>2022-12-11T00:00:00</FromDate>
    <ToDate>2023-12-09T23:59:59</ToDate>
  </ValidBetween>
  <keyList>
    <KeyValue>
      <!-- We might use KeyValue for some additional information -->
      <Key>OurKey</Key>
      <Value>123123</Value>
    </KeyValue>
  </keyList>
  <privateCodes>
    <!-- The SLNID is mandatory if it exists -->
    <PrivateCode type="slnid">ch:1:slnid:102846
      <!-- The SLNID is mandatory if it exists -->
    </PrivateCode>
  </privateCodes>
  <Name>3
    <!-- contains attribute D T from HRDF. Is not translated on purpose. -->
  </Name>
  <ShortName>3
    <!-- contains the LinieKurzName (attribut N T in HRDF) -->
  </ShortName>
  <TransportMode>rail</TransportMode>
  <TransportSubmode>
    <!-- the mapping excel describe how to use the TransportSubmode -->
    <RailSubmode>suburbanRailway
      <!-- Here an example for rail. Be aware that other XXXSubmode are used for other mode. -->
    </RailSubmode>
  </TransportSubmode>
  <PublicCode>3
    <!-- Contains LinieLangName (attribute LT from HRDF) -->
  </PublicCode>
  <OperatorRef ref="ch:1:sboid:100011" version="1">
    <!-- The operator is the transport organisation that really "owns" the line. Additional operators can be added in additionalOperators. The actual operating organisation can be set in the ServiceJourney.  Is redundant to the responsibilitySetRef on purpose. -->
  </OperatorRef>
  <additionalOperators>
    <!-- Used for other operating companies. Is redundant to the responsibilitySetRef on purpose. this is especially important, when a co-ownership of the Line was defined. -->
    <OperatorRef ref="ch:1:sboid:100033" version="1"/>
  </additionalOperators>
  <LineType>fixed
    <!-- Will be used especially, when not "fixed". Details in mapping excel. -->
  </LineType>
  <TypeOfProductCategoryRef ref="ch:1:TypeOfProductCategory:TER" version="1">
    <!-- Always aligned with BS KI oev-info.ch -->
  </TypeOfProductCategoryRef>
</Line>

->Template

Usage Notes

• slnid will be integrated wherever possible. We currently think that - where it exists - it has the necessary properties to be used in the @id of the element.
• For foreign lines an @d might need to be generated.
• We store the slnid whenever possible in @id, privateCodes/PrivateCode and KeyList.
• Information about the Swiss line id (slnid) can be found here.
• Handling of mixed lines is defined in its own use case (uc017). The relevant factors are described in the Line element as well. We have a full example on it. - Be aware that for mixed lines there might be multiple Lines in NeTEx. Otherwise, the relevant Operator must be set on the ServiceJourney.
• Note that there exist journeys in Switzerland and neighboring countries that are not associated with a Line. In NeTEx, however, the ServiceJourneys corresponding to such journeys must still reference something in LineRef. To ensure this, we introduce a placeholder Line called “NoLine” for each Operator that has journeys without a Line.
• For more information about SwissLineID: see here.
• We have in the slnid concept also “Dispositionslinie” and “Temporäre Linie”. Those are modeled as regular Line. “Betriebliche Linie” is not used and modeled in NeTEx. If at some point we need to know this type. We will model it as a Key/Value pair.
• If there are partial lines, there is also a main line. The patterns and journeys are always attached to the partial lines.
• @id needs to be kept stable between exports.

GroupOfLines

→ Glossary definition

Purpose

A GroupOfLines is used to model mixed lines. For details see uc17.

Table

We use GroupOfLine for the modeling of mixed lines. Only mixed lines have a GroupOfLines.

Table: GroupOfLines

Sub	Element	Usage	Card	Type	Description	Note
	members	mandatory	0..1	singleJourneyRefs_RelStructure	Members of GROUP OF ENTITies.
+	LineRef	mandatory	1..*	LineRefStructure	Reference to a LINE.	one must be the main line
	MainLineRef	mandatory	0..1	LineRefStructure	Primary LINE in GROUP OF LINEs, if relevant.	The main line must exist. It hasn’t any ServiceJourneyPattern or ServiceJourneys. Those are all on the partial lines.
	GroupOfLinesType	mandatory	0..1	GroupOfLinesTypeEnumeration	Classification of GROUP OF LINES. +v1.1

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<GroupOfLines id="ch:1:GroupOfLines:1027553" version="1">
  <!-- We use GroupOfLine for the modeling of mixed lines. Only mixed lines have a GroupOfLines. -->
  <members>
    <LineRef ref="ch:1:slnid:1027553" version="1">
      <!-- one must be the main line -->
    </LineRef>
    <LineRef ref="ch:1:slnid:1027553:3" version="1"/>
    <LineRef ref="ch:1:slnid:1027553:4" version="1"/>
  </members>
  <MainLineRef ref="ch:1:slnid:1027553" version="1">
    <!-- The main line must exist. It hasn't any ServiceJourneyPattern or ServiceJourneys. Those are all on the partial lines. -->
  </MainLineRef>
  <GroupOfLinesType>administrative</GroupOfLinesType>
</GroupOfLines>

->Template

Usage Notes

• Only mixed lines have a GroupOfLines.
• All ServiceJourneyPattern and ServiceJourney are assigned to the partial lines.
• In very rare cases the main line has two legal owners. We discuss the modeling in uc17.
• The @id should be the number of the main line.

DestinationDisplay

→ Glossary definition

Purpose

Showing the destination of a ServiceJourney. The text shown on the front or side of a public transport vehicle to indicate its destination, including via-points and variant labels.

DestinationDisplay is a standalone, reusable object — defined once in the ServiceFrame and referenced from wherever the destination text is needed. This is preferred over an inline Destination/Name on ServiceJourney, for several reasons:

• An inline Name on Destination duplicates the display text (once in Name, once in the referenced DestinationDisplay) and can become inconsistent between the two.
• DestinationDisplay is reusable across arbitrarily many journeys, instead of repeating the text per journey.
• Only DestinationDisplay offers the complete set of display attributes: FrontText, SideText, ShortName, vias, and language variants — Destination only knows a single Name.
• DestinationDisplay can additionally be set directly on StopPointInJourneyPattern, allowing the displayed destination to change at individual stops (e.g. for through-services / Durchbindung). This is not possible with Destination at the journey level.

Table

We only allow fully formed content of destinationDisplays

Table: DestinationDisplay

Sub	Element	Usage	Card	Type	Description	Note
	@id	mandatory	1..1	xsd:string	Attribute id
	@version	mandatory	1..1	xsd:string	Attribute version
	Name	mandatory	0..1	MultilingualString	Name of VALIDITY CONDITION.	Is always language neutral. The data is taken from the Destination or from the reference in *R (HRDF). If DURCHBI is used then the destination display shows the final destination.
+	@lang	mandatory	1..1	xsd:string	Attribute lang
	DriverDisplayText	optional	0..1	MultilingualString	Text to show to Driver or Staff for the Notice.	Text to display to DRIVER.

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<DestinationDisplay id="generated-id" version="1">
  <!-- We only allow fully formed content of destinationDisplays -->
  <Name lang="de">Porrentruy
    <!-- Is always language neutral. The data is taken from the Destination or from the reference in *R (HRDF). If DURCHBI is used then the destination display shows the final destination. -->
  </Name>
  <DriverDisplayText>Porrentruy
    <!-- Text to display to DRIVER. -->
  </DriverDisplayText>
  <Presentation/>
</DestinationDisplay>

->Template

Usage Notes

• In HRDF sometimes the destination is not set (*R). This results in NeTEX in a calculated destination definition.
• The DestinationDisplay is set on the ServiceJourney via Destination/DestinationDisplayRef. If it changes during the run, it needs to be changed on the relevant StopPointInJourneyPattern via DestinationDisplayRef. If it changes there, the new destination applies from that point onward — in our output, we fill all remaining PointsInJourneyPattern with the relevant change.
• Destination must not carry a redundant inline Name alongside DestinationDisplayRef — the display text lives exclusively in the referenced DestinationDisplay object, to avoid inconsistency between the two sources. Only ScheduledStopPointRef and DestinationDisplayRef should be set on Destination.
• See also the use case on changes in destination
• @id needs to be kept stable between exports.

ScheduledStopPoint

→ Glossary definition

Purpose

A logical point used in the timetable to indicate a stop of a service where passengers can board or alight. A ScheduledStopPoint is linked to a physical Quay or StopPlace via a PassengerStopAssignment.

A ScheduledStopPoint can represent two types of stop points:

• In most cases, the ScheduledStopPoint is the station named in the timetable, especially as some organisations don’t have a full physical model of their StopPlaces.
• In some cases, the ScheduledStopPoint may be mapped to the Quay. The more detailed mapping is also done with the PassengerStopAssignment.

Table

Swiss ScheduledStopPoint are using the sloid in the id if possible. We keep the ScheduledStopPoint very minimalistic. The information is stored in the SiteFrame.

Table: ScheduledStopPoint

Sub	Element	Usage	Card	Type	Description	Note
	@id	mandatory	1..1	xsd:string	Attribute id
	@version	mandatory	1..1	xsd:string	Attribute version
	privateCodes	expected	0..1	PrivateCodesStructure	A list of private codes that uniquely identifiy the element. May be used for inter-operating with other (legacy) systems. +v2.0
+	PrivateCode	expected	0..*	PrivateCodeStructure	A private code that uniquely identifies the element. May be used for inter-operating with other (legacy) systems.	SLOID mandatory if it exists.
	Name	optional	0..1	MultilingualString	Name of VALIDITY CONDITION.	The names are the same in all languages. Can be omitted as this is taken from the StopPlace/Quay.
+	@lang	mandatory	1..1	xsd:string	Attribute lang
	PublicCode	optional	0..1	PublicCodeStructure	Public identifier code of TARIFF ZONE. +v2.0	For Quay contains the plattform number/letter.

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<ScheduledStopPoint id="ch:1:sloid:4128:1:1" version="1">
  <!-- Swiss ScheduledStopPoint are using the sloid in the id if possible. We keep the ScheduledStopPoint very minimalistic. The information is stored in the SiteFrame. -->
  <privateCodes>
    <PrivateCode type="sloid">ch:1:sloid:4128:1:1
      <!-- SLOID mandatory if it exists. -->
    </PrivateCode>
  </privateCodes>
  <Name lang="de">Murten/Morat
    <!-- The names are the same in all languages. Can be omitted as this is taken from the StopPlace/Quay. -->
  </Name>
  <PublicCode>1
    <!-- For Quay contains the plattform number/letter. -->
  </PublicCode>
</ScheduledStopPoint>

->Template

Usage Notes

• We don’t keep much information in ScheduledStopPoints. They are assigned by PassengerStopAssignnments to the site part (StopPlace, Quay).
• ScheduledStopPoints that are used in TimingLinksand ServiceJourneyPatterns` should be on the quay level.
• We use the sloid as @id for ScheduledStopPoints whener they exist. @id needs to be kept stable between exports.
• TimingLinks use ScheduledStopPoints as well. This means that the timing between two logical stops is the important measure.

PassengerStopAssignment

→ Glossary definition

Purpose

PassengerStopAssignments bring the Site model and the Service model in alignment. We have two general cases:

• A ScheduledStopPoint in a ServiceJourneyPattern is linked to a StopPlace for arrival and departure.
• A ScheduledStopPoint in a ServiceJourneyPattern is linked to a Quay for arrival and departure. In that case, both Quay and StopPlace have to be referenced.

Table

Table: PassengerStopAssignment

Sub	Element	Usage	Card	Type	Description	Note
	@id	mandatory	1..1	xsd:string	Attribute id
	@version	mandatory	1..1	xsd:string	Attribute version
	ScheduledStopPointRef	mandatory	0..1	ScheduledStopPointRefStructure	Reference to a SCHEDULED STOP POINT.
	StopPlaceRef	mandatory	0..1	StopPlaceRefStructure	Reference to a STOP PLACE.
	QuayRef	expected	0..1	QuayRefStructure	Reference to a QUAY.	Not having the track may be problematic, but it can happen

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<PassengerStopAssignment id="generated-85003000-12" version="1">
  <ScheduledStopPointRef ref="ch:1:sloid:3000:503:12" version="1"/>
  <StopPlaceRef ref="ch:1:sloid:3000" version="1"/>
  <QuayRef ref="ch:1:sloid:3000:503:12" version="1">
    <!-- Not having the track may be problematic, but it can happen -->
  </QuayRef>
</PassengerStopAssignment>

->Template

Usage Notes

• @ids don’t need to be stable.

DefaultConnection

→ Glossary definition

Purpose

DefaultConnections are used to transmit the connection times for the following constellations:

• between 2 ProductCategorys
• between 2 Operators
• In a defined StopPlace
• In a defined StopPlace and 2 Operators
• in a defined StopPlace, 2 Operators and 2 ProductCategorys

Table

Be aware only some combinations are allowed: from mode A to mode B without operators taken into account; from operator A and product category A to operator B and product category B.

Table: DefaultConnection

Sub	Element	Usage	Card	Type	Description	Note
	@id	mandatory	1..1	xsd:string	Attribute id
	@version	mandatory	1..1	xsd:string	Attribute version
	Extensions	optional	1..1	ExtensionsStructure	Extensions to schema. (Wrapper tag used to avoid problems with handling of optional ‘any’ by some validators).	When also ProductCategory is relevant, then this extension must be used
+	FromProductCategoryRef	mandatory	1..1	unknown		Extension needed to map “Verkehrsmittel-Gattung”, which is similar to but more detailed than Trans-portSubmode, for transfer times of interchanges.
+	ToProductCategoryRef	mandatory	1..1	unknown		Extension needed to map “Verkehrsmittel-Gattung”, which is similar to but more detailed than Trans-portSubmode, for transfer times of interchanges.
	WalkTransferDuration	mandatory	0..1	TransferDurationStructure	Timings for walking over TRANSFER if different from the JOURNEY PATTERN transfer duration,	We use WalkTransferDuration. At some point we need a solution for bicyle duration too (TSI telemetics)
+	MobilityRestrictedTravellerDuration	expected	0..1	xsd:duration	Time for a Mobility Restricted traveller to make a TRANSFER.
	BothWays	optional	0..1	xsd:boolean	Whether timings and validity applies to both directions (true) or just to the from-to direction of the TRANSFER.	Should be false - we always intend to use only one way because the behaviour may not be the same.
	From	mandatory	0..1	ConnectionEndStructure	Origin end of ACCESS link.
+	TransportMode	optional	0..1	AllModesEnumeration	An area within a Site. May be connected to Quays by PATH LINKs.
+	OperatorView	optional	1..1	Operator_DerivedViewStructure	Simplified view of OPERATOR. All data except the identifier will be derived through the relationship.	Should be a sboid whenever possible.
++	OperatorRef	mandatory	1..1	OperatorRefStructure	Reference to an OPERATOR.
	To	mandatory	0..1	ConnectionEndStructure	Destination end of ACCESS link.
	StopPlaceRef	optional	0..1	StopPlaceRefStructure	Reference to a STOP PLACE.	Usually a SLOID. Not set means whole network.

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<DefaultConnection id="11-11" version="1">
  <!-- Be aware only some combinations are allowed: from mode A to mode B without operators taken into account; from operator A and product category A  to operator B and product category B. -->
  <Extensions>
    <!-- When also ProductCategory is relevant, then this extension must be used -->
    <FromProductCategoryRef ref="ch:1:TypeOfProductCategory:ICE" version="1">
      <!-- Extension needed to map "Verkehrsmittel-Gattung", which is similar to but more detailed than Trans-portSubmode, for transfer times of interchanges. -->
    </FromProductCategoryRef>
    <ToProductCategoryRef ref="ch:1:TypeOfProductCategory:TE2" version="1">
      <!-- Extension needed to map "Verkehrsmittel-Gattung", which is similar to but more detailed than Trans-portSubmode, for transfer times of interchanges. -->
    </ToProductCategoryRef>
  </Extensions>
  <WalkTransferDuration>
    <!-- We use WalkTransferDuration. At some point we need a solution for bicyle duration too (TSI telemetics) -->
    <DefaultDuration>PT2M</DefaultDuration>
    <MobilityRestrictedTravellerDuration>PT4M</MobilityRestrictedTravellerDuration>
  </WalkTransferDuration>
  <BothWays>false
    <!-- Should be false - we always intend to use only one way because the behaviour may not be the same. -->
  </BothWays>
  <From>
    <TransportMode>all</TransportMode>
    <OperatorView>
      <!-- Should be a sboid whenever possible. -->
      <OperatorRef ref="ch:1:sboid:100011" version="1"/>
    </OperatorView>
  </From>
  <To>
    <TransportMode>all</TransportMode>
    <OperatorView>
      <!-- Should be a sboid whenever possible. -->
      <OperatorRef ref="ch:1:sboid:100033" version="1"/>
    </OperatorView>
  </To>
  <StopPlaceRef ref="ch:1:sloid:19231" version="1">
    <!-- Usually a SLOID. Not set means whole network. -->
  </StopPlaceRef>
</DefaultConnection>

->Template

Usage Notes

• For more details see the use case on transfers.
• @id needs to be kept stable between exports.

SiteConnection

→ Glossary definition

Purpose

• The SiteConnection describes the transfer times between two adjacent StopPlaces.
• @id needs to be kept stable between exports.

Table

SiteConnection are used only in the main file and not in timetable files.

Table: SiteConnection

Sub	Element	Usage	Card	Type	Description	Note
	@id	mandatory	1..1	xsd:string	Attribute id
	@version	mandatory	1..1	xsd:string	Attribute version
	WalkTransferDuration	mandatory	0..1	TransferDurationStructure	Timings for walking over TRANSFER if different from the JOURNEY PATTERN transfer duration,
+	DefaultDuration	mandatory	0..1	xsd:duration	Default time needed for a traveller to make a TRANSFER.
	BothWays	mandatory	0..1	xsd:boolean	Whether timings and validity applies to both directions (true) or just to the from-to direction of the TRANSFER.
	From	mandatory	0..1	ConnectionEndStructure	Origin end of ACCESS link.	Could also refer to a Quay or a different SiteElement. Currently, we only transfer StopPlaceRefs.
+	StopPlaceRef	mandatory	0..1	StopPlaceRefStructure	Reference to a STOP PLACE.
	To	mandatory	0..1	ConnectionEndStructure	Destination end of ACCESS link.	Could also refer to a Quay or a different SiteElement. Currently, we only transfer StopPlaceRefs.
+	StopPlaceRef	mandatory	0..1	StopPlaceRefStructure	Reference to a STOP PLACE.

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<SiteConnection id="ch:1:SiteConnection:8506302-8589913" version="1">
  <!-- SiteConnection are used only in the main file and not in timetable files. -->
  <WalkTransferDuration>
    <DefaultDuration>PT13M</DefaultDuration>
  </WalkTransferDuration>
  <BothWays>false</BothWays>
  <From>
    <!-- Could also refer to a Quay or a different SiteElement. Currently, we only transfer StopPlaceRefs. -->
    <StopPlaceRef ref="ch:2:StopPlace:8506302" version="1"/>
  </From>
  <To>
    <!-- Could also refer to a Quay or a different SiteElement. Currently, we only transfer StopPlaceRefs. -->
    <StopPlaceRef ref="ch:2:StopPlace:8589913" version="1"/>
  </To>
</SiteConnection>

->Template

Usage Notes

For more details see the use case on transfers.

TimingLink

→ Glossary definition

Purpose

TimingLink defines the topological link between two TimingPoints (in practice ScheduledStopPoints, referenced via FromPointRef/ToPointRef) used within a ServiceJourneyPattern. TimingLink itself does not carry run or wait time values — these are defined per TimeDemandType via JourneyRunTime (referencing the TimingLink through TimingLinkRef) and JourneyWaitTime (referencing the ScheduledStopPoint directly through TimingPointRef, not via TimingLink). See TimeDemandType.

Table

A timing link is basically defined between two ScheduledStopPoints. However, there may be different timing behaviours and then multiple TimingLinks between the same ScheduledStopPoint might be necessary

Table: TimingLink

Sub	Element	Usage	Card	Type	Description	Note
	@id	mandatory	1..1	xsd:string	Attribute id
	@version	mandatory	1..1	xsd:string	Attribute version
	privateCodes	optional	0..1	PrivateCodesStructure	A list of private codes that uniquely identifiy the element. May be used for inter-operating with other (legacy) systems. +v2.0	only for the “virtual” stops like Bahn2000
+	PrivateCode	optional	0..*	PrivateCodeStructure	A private code that uniquely identifies the element. May be used for inter-operating with other (legacy) systems.	DIDOK code of the virtual stop
++	@type	mandatory	1..1	xsd:string	Attribute type
	Name	optional	0..1	MultilingualString	Name of VALIDITY CONDITION.	Can be used to express “Neubaustrecke”, “Lötschbergbasistunnel” and the like.
	FromPointRef	mandatory	1..1	VehicleMeetingPointRefStructure	Start POINT of LINK.	We use PointRef on purpose in preparation of BorderPoints. the nameOfClassRef helps to define this
+	@nameOfRefClass	mandatory	1..1	xsd:string	Attribute nameOfRefClass
	ToPointRef	mandatory	1..1	VehicleMeetingPointRefStructure	End POINT of LINK.	We use PointRef on purpose in preparation of BorderPoints. the nameOfClassRef helps to define this
+	@nameOfRefClass	mandatory	1..1	xsd:string	Attribute nameOfRefClass
	OperationalContextRef	optional	1..1	OperationalContextRefStructure	Reference to an OPERATIONAL CONTEXT.	This is “Betriebszweig”. Switzerland does not use it currently, but it might become interesting at some point

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<TimingLink id="generated" version="1">
  <!-- A timing link is basically defined between two ScheduledStopPoints. However, there may be different timing behaviours and then multiple TimingLinks between the same ScheduledStopPoint might be necessary -->
  <privateCodes>
    <!-- only for the "virtual" stops like Bahn2000 -->
    <PrivateCode type="virtualStops">00000001
      <!-- DIDOK code of the virtual stop -->
    </PrivateCode>
  </privateCodes>
  <Name>Neubaustrecke
    <!-- Can be used to express "Neubaustrecke", "Lötschbergbasistunnel" and the like. -->
  </Name>
  <FromPointRef ref="sloid1" nameOfRefClass="ScheduledStopPoint" version="1">
    <!-- We use PointRef on purpose in preparation of BorderPoints. the nameOfClassRef helps to define this -->
  </FromPointRef>
  <ToPointRef ref="sloid 2" nameOfRefClass="ScheduledStopPoint" version="1">
    <!-- We use PointRef on purpose in preparation of BorderPoints. the nameOfClassRef helps to define this -->
  </ToPointRef>
  <OperationalContextRef ref="generated" version="1">
    <!-- This is "Betriebszweig". Switzerland does not use it currently, but it might become interesting at some point -->
  </OperationalContextRef>
</TimingLink>

->Template

Usage Notes

• It must fit with the sequence defined in ServiceJourneyPattern.
• FromPointRef/ToPointRef reference ScheduledStopPoints (technically typed as TimingPointRef, substituted by ScheduledStopPointRef).
• If there is maneuvering or a change of quay, then a separate TimingLink needs to be added for that too.
• Multiple visits of the same ScheduledStopPoint within a ServiceJourneyPattern are addressed with a JourneyWaitTime that has a StopPointInServiceJourneyPatternRef instead of a ScheduledStopPointRef like the regular ones.
• @id needs to be kept stable between exports.

ServiceJourneyPattern

→ Glossary definition

Purpose

ServiceJourneyPattern is used to describe the journey pattern (sequence and times of ScheduledStopPoints) of ServiceJourney.

Table

Table: ServiceJourneyPattern

Sub	Element	Usage	Card	Type	Description	Note
	@id	mandatory	1..1	xsd:string	Attribute id
	@version	mandatory	1..1	xsd:string	Attribute version
	Name	optional	0..1	MultilingualString	Name of VALIDITY CONDITION.
	RouteView	mandatory	1..1	Route_DerivedViewStructure	Annotated reference to a ROUTE.
+	LineRef	mandatory	1..*	LineRefStructure	Reference to a LINE.
	DirectionType	mandatory	0..1	RelativeDirectionEnumeration	A Direction of a ROUTE. One of a restricted set of values. Default is “Outbound”
	pointsInSequence	mandatory	0..1	vehicleMeetingPointsInSequence_RelStructure	Ordered List of points used in TIMING PATTERN. specific to TIMING PATTERN.
+	StopPointInJourneyPattern	mandatory	0..*	unknown
++	ScheduledStopPointRef	mandatory	0..1	ScheduledStopPointRefStructure	Reference to a SCHEDULED STOP POINT.
++	ForAlighting	mandatory	0..1	xsd:boolean	Default for whether SCHEDULED STOP POINT may be used for alighting. May be overridden on specific services.
++	ForBoarding	mandatory	0..1	xsd:boolean	Default for whether SCHEDULED STOP POINT may be used for boarding. May be overridden on specific services.
++	DestinationDisplayRef	optional	1..*	DestinationDisplayRefStructure	Reference to a DESTINATION DISPLAY.	Indicates that the destination has changed. Superseeds Line or ServiceJourney
++	RequestStop	optional	0..1	xsd:boolean	Whether stop is by default a request stop in the timetable. May be overridden in specific SERVICE PATTERNs.
++	StopUse	optional	0..1	StopUseEnumeration	Nature of use of stop, e.g. access, interchange only, or pass through. Default is Access.	All values possible. passthrough is used for Durchfahrt, if such data is delivered.
++	checkConstraints	optional	0..1	checkConstraints_RelStructure	CHECK CONSTRAINTs in frame.
+++	CheckConstraint	optional	1..*	CheckConstraint_VersionStructure	Characteristics of a SITE COMPONENT representing a process, such as check-in, security screening, ticket control or immigration, that may potentially incur a time penalty that should be allowed for when journey planning. Used to mark PATH LINKs to determine transit routes through interchanges.
++	bookingArrangements	optional	0..1	bookingArrangements_RelStructure	BOOKING ARRANGEMENTs in frame +v2.0.
+++	BookingArrangementRef	optional	0..*	BookingArrangementRefStructure	Reference to a BOOKING ARRANGEMENT.	Specially we use bookingArrangementRef here to model the information that a stop is flexible. From the HRDF conversion only a BookingNote can be passed at the moment. With native NeTEx handling we can transfer more information.
+++	BookingArrangement	we expect a BookingArrangementRef. We use this here to show how native NeTEx handling could improve transfering information here	1..*	BookingArrangement_VersionStructure	Details of the booking arrangements for a given LINE, STOP, SERVICE etc.
++++	BookingMethods	we expect a BookingArrangementRef. We use this here to show how native NeTEx handling could improve transfering information here	0..1	BookingMethodListOfEnumerations	Allowed Ways of Making a BOOKING.
	ServiceJourneyPatternType	expected	0..1	ServiceJourneyPatternTypeEnumeration	Type of SERVICE JOURNEY PATTERN.

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<ServiceJourneyPattern id="ch:1:ServiceJourneyPattern:1" version="1">
  <Name>Bern-Spiez</Name>
  <RouteView>
    <LineRef ref="ch:1:slnid:1024437" version="1"/>
  </RouteView>
  <DirectionType>outbound</DirectionType>
  <pointsInSequence>
    <StopPointInJourneyPattern id="ch:1:PointInJourneyPattern:1.1" version="1">
      <ScheduledStopPointRef ref="ch:1:sloid:7000:5:9" version="1"/>
      <ForAlighting>false</ForAlighting>
      <ForBoarding>true</ForBoarding>
      <DestinationDisplayRef ref="DestinationDisplay:1" version="1">
        <!-- Indicates that the destination has changed. Superseeds Line or ServiceJourney -->
      </DestinationDisplayRef>
      <RequestStop>false</RequestStop>
      <StopUse>access
        <!-- All values possible. passthrough is used for Durchfahrt, if such data is delivered. -->
      </StopUse>
      <checkConstraints>
        <CheckConstraint id="generated" version="1"/>
      </checkConstraints>
      <bookingArrangements>
        <BookingArrangementRef ref="generated" version="1">
          <!-- Specially we use bookingArrangementRef here to model the information that a stop is flexible. From the HRDF conversion only a BookingNote can be passed at the moment. With native NeTEx handling we can transfer more information. -->
        </BookingArrangementRef>
      </bookingArrangements>
    </StopPointInJourneyPattern>
    <StopPointInJourneyPattern id="ch:1:PointInJourneyPattern:1.2" version="1">
      <ScheduledStopPointRef ref="ch:1:sloid:7100:1:1" version="1"/>
      <ForAlighting>true</ForAlighting>
      <ForBoarding>true</ForBoarding>
    </StopPointInJourneyPattern>
    <StopPointInJourneyPattern id="ch:1:PointInJourneyPattern:1.3" version="1">
      <ScheduledStopPointRef ref="ch:1:sloid:7483:0:954324" version="1"/>
      <ForAlighting>true</ForAlighting>
      <ForBoarding>false</ForBoarding>
    </StopPointInJourneyPattern>
  </pointsInSequence>
  <ServiceJourneyPatternType>passenger</ServiceJourneyPatternType>
</ServiceJourneyPattern>

->Template

Usage Notes

ServiceJourneyPatterns are a common concept in the VDV interface world (“Linienfahrweg”). In order to model ServiceJourneys efficiently and to reduce overall file size, use the concept wisely:

• ServiceJourneys sharing the same stop sequence and the same boarding/alighting options should use the same ServiceJourneyPattern.
• Do not just generate one ServiceJourneyPattern for each ServiceJourney.
• @id should be kept stable between exports.

TimeDemandType

→ Glossary definition

Purpose

TimeDemandType describes the timing pattern of a ServiceJourneyPattern: RunTimes between consecutive ScheduledStopPoints (via JourneyRunTime, referencing the relevant TimingLink through TimingLinkRef) and WaitTimes at a ScheduledStopPoint (via JourneyWaitTime, referencing the ScheduledStopPoint directly through TimingPointRef). Multiple TimeDemandTypes can be defined per ServiceJourneyPattern to represent different traffic or dwell conditions (e.g. peak vs. off-peak).

Table

TimeDemandType assigns a timing behaviour to a ServiceJourney

Table: TimeDemandType

Sub	Element	Usage	Card	Type	Description	Note
	@id	mandatory	1..1	xsd:string	Attribute id
	@version	mandatory	1..1	xsd:string	Attribute version
	Description	optional	0..1	MultilingualString		Can be used if there exists a decription of the pattern.
	runTimes	expected	0..1	vehicleJourneyRunTimes_RelStructure	run times for this TIMING LINK.	The run time on the TimingLinks
+	JourneyRunTime	expected	1..*	JourneyRunTime_VersionedChildStructure	The time taken to traverse a TIMING LINK in a particular JOURNEY PATTERN, for a specified TIME DEMAND TYPE. If it exists, it will override the DEFAULT SERVICE JOURNEY RUN TIME and DEFAULT DEAD RUN RUN TIME.
++	TimingLinkRef	mandatory	1..1	TimingLinkRefStructure	Reference to a TIMING LINK.	The timing link that is ued here and that that does have a given run time
++	RunTime	mandatory	1..1	xsd:duration	RUN TIME as an interval.
	waitTimes	expected	0..1	vehicleJourneyWaitTimes_RelStructure	Wait times for (TIMING) POINT IN JOURNEY PATTERN. There may be different times for different time demands.	We only need wait times if greater than 0.
+	JourneyWaitTime	expected	1..*	JourneyWaitTime_VersionedChildStructure	The time a vehicle has to wait at a specific TIMING POINT IN JOURNEY PATTERN, for a specified TIME DEMAND TYPE. This wait time can be superseded by a VEHICLE JOURNEY WAIT TIME.	Relevant waiting times at the stop
++	ScheduledStopPointRef	expected	0..1	ScheduledStopPointRefStructure	Reference to a SCHEDULED STOP POINT.	Which Quay is referenced. In the case of multiple visits, it should be a StopPointInJourneyPatternRef instead. It also can be a TimingPoint (choice).
++	WaitTime	mandatory	0..1	xsd:duration	Wait time as interval.

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<TimeDemandType id="generated" version="1">
  <!-- TimeDemandType assigns a timing behaviour to a ServiceJourney -->
  <Description>high demand
    <!-- Can be used if there exists a decription of the pattern. -->
  </Description>
  <runTimes>
    <!-- The run time on the TimingLinks -->
    <JourneyRunTime id="generated" version="1">
      <TimingLinkRef ref="generated" version="1">
        <!-- The timing link that is ued here and that that does have a given run time -->
      </TimingLinkRef>
      <RunTime>PT5M</RunTime>
    </JourneyRunTime>
  </runTimes>
  <waitTimes>
    <!-- We only need wait times if greater than 0. -->
    <JourneyWaitTime id="generated" version="1">
      <!-- Relevant waiting times at the stop -->
      <ScheduledStopPointRef ref="sloid" version="1">
        <!-- Which Quay is referenced. In the case of multiple visits, it should be a StopPointInJourneyPatternRef instead. It also can be a TimingPoint (choice). -->
      </ScheduledStopPointRef>
      <WaitTime>PT2M</WaitTime>
    </JourneyWaitTime>
  </waitTimes>
</TimeDemandType>

->Template

Usage Notes

• WaitTime is only needed when greater than 0.
• RunTime references the relevant TimingLink via TimingLinkRef; WaitTime references the relevant ScheduledStopPoint directly via TimingPointRef — not via TimingLink.
• Multiple visits of the same ScheduledStopPoint within a ServiceJourneyPattern are addressed with a JourneyWaitTime that has a StopPointInServiceJourneyPatternRef instead of a ScheduledStopPointRef like the regular ones.

Notice

→ Glossary definition

Purpose

Informational or regulatory text associated with public transport services, displayed to passengers.

Table

Table: Notice

Sub	Element	Usage	Card	Type	Description	Note
	@id	mandatory	1..1	xsd:string	Attribute id
	@version	mandatory	1..1	xsd:string	Attribute version
	Text	expected	0..1	MultilingualString
+	@lang	mandatory	1..1	xsd:string	Attribute lang
+	Text	expected	0..*	MultilingualString	Name of the entity.
++	@lang	mandatory	1..1	xsd:string	Attribute lang
	PublicCode	mandatory	0..1	PublicCodeStructure	Public identifier code of TARIFF ZONE. +v2.0	The public code is transmitted when it is to be published and when it is the type of notice 10. Only 1 and 10 aree allowed.
	ShortCode	expected	0..1	CleardownCodeType	Alternative short code associated with Notice.	A duplication, but we want it. “A__” indicates an offer based on BS KI
	PrivateCode	expected	1..1	PrivateCodeStructure	A private code that uniquely identifies the element. May be used for inter-operating with other (legacy) systems.	A duplication, but we want it.
	TypeOfNoticeRef	expected	1..1	TypeOfNoticeRefStructure	Reference to a TYPE OF NOTICE.	allowed are ch:1:TypeOfNotice:1 for general notice, ch:1:TypeOfNotice:10 for offer, ch:1:TypeOfNotice:11 for region code (only PAG)
	CanBeAdvertised	expected	0..1	xsd:boolean	Whether NOTICE is advertised to public. This may be overridden on an assignment.	Whether the NOTICE is advertised.

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<Notice id="ch:1:Notice:generated-1229900" version="1">
  <Text lang="de">Cateringzone / Automaten
    <Text lang="en">Catering zone / Vending machine</Text>
    <Text lang="fr">Zone catering / Distributeur</Text>
    <Text lang="it">Zona catering / Distributore</Text>
  </Text>
  <PublicCode>
    <!-- The public code is transmitted when it is to be published and when it is the type of notice 10. Only 1 and 10 aree allowed. -->
  </PublicCode>
  <ShortCode>A__SN
    <!-- A duplication, but we want it. "A__" indicates an offer based on BS KI -->
  </ShortCode>
  <PrivateCode>A__SN
    <!-- A duplication, but we want it. -->
  </PrivateCode>
  <TypeOfNoticeRef ref="ch:1:TypeOfNotice:10" version="1">
    <!-- allowed are ch:1:TypeOfNotice:1 for general notice, ch:1:TypeOfNotice:10 for offer, ch:1:TypeOfNotice:11 for region code (only PAG) -->
  </TypeOfNoticeRef>
  <CanBeAdvertised>true
    <!-- Whether the NOTICE is advertised. -->
  </CanBeAdvertised>
</Notice>

->Template

Usage Notes

• Notice elements should only be used to convey information which cannot be transported using specific model elements. Do not use Notice when the information could be expressed by specific elements, e.g., FacilitySet, DayType, ForAlighting, ForBoarding. Notices can be used to provide further information on ServiceFacilitys but not as a replacement for them. Ideally, the description of a Notice is translated to the three official languages (DE, IT, FR), and possibly E.
• @id doesn’t need to be kept stable between exports.

NoticeAssignment

→ Glossary definition

Purpose

Assign a Notice to an element.

Table

NoticeAssignment connects a Notice to an element. The attribute id must be unique.

Table: NoticeAssignment

Sub	Element	Usage	Card	Type	Description	Note
	@id	mandatory	1..1	xsd:string	Attribute id
	@version	mandatory	1..1	xsd:string	Attribute version
	validityConditions	optional	1..1	validityConditions_RelStructure	VALIDITY CONDITIONs conditioning entity.
+	AvailabilityConditionRef	optional	0..*	AvailabilityConditionRefStructure	Reference to an AVAILABILITY CONDITION. A VALIDITY CONDITION defined in terms of temporal attributes.
	NoticeRef	expected	1..1	NoticeRefStructure	Reference to a NOTICE i.e. footnote, note, announcement or other informational text element.
	NoticedObjectRef	optional	0..1	VersionOfObjectRefStructure	Object with which NOTICE is associated. If given by context can be omitted.	We currently have not plan of using it this way. We do it through embeddingt the NoticeAssignment within the relevant element.
+	@nameOfRefClass	mandatory	1..1	xsd:string	Attribute nameOfRefClass
	StartPointInPatternRef	optional	0..1	PointInSequenceRefStructure	POINT at which applicability of NOTICE starts.	If the notice is valid only on a part of a ServiceJourney then this can be marked with StartPointInPatternRef and EndPointInPatternRef.
	EndPointInPatternRef	optional	0..1	PointInSequenceRefStructure	POINT at which applicabiity of NOTICE endsIf absent same as Start Point.

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<NoticeAssignment id="ch:1:NoticeAssignment:ch_1_ServiceJourney_ch_1_sjyid_100001_71707-003_1_0" version="1">
  <!-- NoticeAssignment connects a Notice to an element. The attribute `id` must be unique. -->
  <validityConditions>
    <AvailabilityConditionRef ref="ch:1:AvailabilityCondition:c3" version="1"/>
  </validityConditions>
  <NoticeRef ref="ch:1:Notice:Hin-1229900" version="1"/>
  <NoticedObjectRef ref="generated" nameOfRefClass="ScheduledStopPoint" version="1">
    <!-- We currently have not plan of using it this way. We do it through embeddingt the NoticeAssignment within the relevant element. -->
  </NoticedObjectRef>
  <StartPointInPatternRef ref="generated" version="1">
    <!-- If the notice is valid only on a part of a ServiceJourney then this can be marked with StartPointInPatternRef and EndPointInPatternRef. -->
  </StartPointInPatternRef>
  <EndPointInPatternRef ref="generated-1" version="1"/>
</NoticeAssignment>

->Template

Usage Notes

• @id doesn’t need to be kept stable between exports.