In this chapter:

ServiceFrame

→ Glossary definition

Purpose

Contains the network and route 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:

  • Route model: fixed and flexible Lines and Routes of a transport network.
  • 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 for FLEXIBLE STOP PLACE. Only Line is used and not FlexibleLine
+ Line mandatory 1..1 Line 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 NETWORK.  
+ GroupOfLines expected 1..1 GroupOfLines 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 Destinations associated with this GROUP OF SERVICEs, including via points. We only allow fully formed content of destinationDisplays
+ DestinationDisplay expected 1..1 DestinationDisplay An advertised destination of a specific JOURNEY PATTERN, usually displayed on a head sign or at other on-board locations. We only allow fully formed content of destinationDisplays
  scheduledStopPoints expected 0..1 scheduledStopPointsInFrame_RelStructure SCHEDULED STOP POINTs in frame. Swiss ScheduledStopPoint are using the SLOID in the id, when possible.
+ ScheduledStopPoint mandatory 1..1 ScheduledStopPoint 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.  
+ SiteConnection expected 1..1 SiteConnection 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 1..1 DefaultConnection 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 1..1 PassengerStopAssignment The default allocation of a SCHEDULED STOP POINT to a specific STOP PLACE, and also possibly a QUAY and BOARDING POSITION. are only used in a special PSA file in the export.
  timingLinks expected 0..1 timingLinksInFrame_RelStructure TIMING LINKs in frame. We use TimingLink as the time behaviour between two ScheduledStopPoints
+ TimingLink expected 1..1 TimingLink 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 JourneyPatternsequivalent to the series.  
+ ServiceJourneyPattern mandatory 1..1 ServiceJourneyPattern The JOURNEY PATTERN for a (passenger carrying) SERVICE JOURNEY.  
  timeDemandTypes expected 0..1 timeDemandTypeRefs_RelStructure Other TIME DEMAND TYPEs used in journey.  
+ TimeDemandType expected 1..1 TimeDemandType 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..1 Notice 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>
  <!-- We only allow fully formed content of destinationDisplays -->
  <DestinationDisplay id="generated-id" version="1">
  <!-- We only allow fully formed content of destinationDisplays -->
  </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>
  <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">
  <!-- are only used in a special PSA file in the export. -->
  </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, representing a marketed route with a Name, TransportMode, and Operator.

Table

For referencing the Operators we redundantly use ResponsibilitySet and OperatorRef. This is to maintain compatibility with different data consumers.

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..1 ValidBetween OPTIMISATION. Simple version of a VALIDITY CONDITION. Comprises a simple period. NO UNIQUENESS CONSTRAINT. 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 mandatory 1..1 KeyListStructure A list of alternative Key values for an element.  
+ KeyValue expected 1..* KeyValueStructure Key value pair for Entity. The SLNID is mandatory, when it exists
++ Key expected 1..1 xsd:normalizedString Identifier of value e.g. System.  
++ Value expected 0..1 xsd:anyType Value associated with QUALITY STRUCTURE FACTOR.  
  privateCodes expected 1..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, when it exists
+ PrivateCode expected 0..* PrivateCodeStructure A private code that uniquely identifies the element. May be used for inter-operating with other (legacy) systems.  
++ @type mandatory 1..1 xsd:string Attribute type  
  Name mandatory 0..* MultilingualString Name of Traveller contains attribute D T from HRDF. Is not translated on purpose.
  ShortName expected 0..* MultilingualString Short Name for service contains the LinieKurzName (attribut N T in HRDF)
  TransportMode mandatory 0..1 AllModesEnumeration MODE.  
  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 code for JOURNEY. 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 1..1 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. -->
  <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>
  <!-- The SLNID is mandatory, when it exists -->
  <Key>SLNID</Key>
  <Value>ch:1:slnid:102846</Value>
  </KeyValue>
  </keyList>
  <privateCodes>
  <!-- The SLNID is mandatory, when it exists -->
  <PrivateCode type="slnid">ch:1:slnid:102846</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:Operator:11" 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:Operator:33" 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-attribute.
  • For foreign lines an id 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-attribute 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 Services in GROUP.  
+ LineRef mandatory 1..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-attribute 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..* MultilingualString Name of Traveller Is always language neutral. The data is taken from the Des-tination 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 DESTINATION DISPLAY. 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 Des-tination 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-attribute 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  
  keyList optional 1..1 KeyListStructure A list of alternative Key values for an element.  
+ KeyValue optional 1..* KeyValueStructure Key value pair for Entity. Can contain a DIDOK key and a SLOID. We don’t need it really.
++ Key optional 1..1 xsd:normalizedString Identifier of value e.g. System.  
++ Value optional 0..1 xsd:anyType Value associated with QUALITY STRUCTURE FACTOR.  
  privateCodes optional 1..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 optional 0..* PrivateCodeStructure A private code that uniquely identifies the element. May be used for inter-operating with other (legacy) systems. If the id is not a SLOID then the SLOID must be added here.
  Name optional 0..* MultilingualString Name of Traveller 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 code for JOURNEY. 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. -->
  <keyList>
  <KeyValue>
  <!-- Can contain a DIDOK key and a SLOID. We don't need it really. -->
  <Key>DIDOK</Key>
  <Value>8504128</Value>
  </KeyValue>
  <KeyValue>
  <Key>SLOID</Key>
  <Value>ch:1:sloid:4128:1:1</Value>
  </KeyValue>
  </keyList>
  <privateCodes>
  <PrivateCode type="sloid">ch:1:sloid:4128:1:1
  <!-- If the id is not a SLOID then the SLOID must be added here. -->
  </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. The 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-attribute for ScheduledStopPoints whener they exist. id-attribute 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 Specific SCHEDULED STOP POINT at end of CONNECTION.  
  StopPlaceRef mandatory 0..1 StopPlaceRefStructure System identifier of a STOP PLACE. May be omitted if given by context.  
  QuayRef expected 0..1 QuayRefStructure QUAY to which SCHEDULED STOP POINT is to be assigned. 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

  • id-attributes 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 User defined Extensions to ENTITY in 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 CONNECTION.  
+ TransportMode optional 0..1 AllModesEnumeration MODE.  
+ OperatorView optional 1..1 OperatorView Simplified view of OPERATOR. All data except the identifier will be derived through the relationship.  
++ OperatorRef mandatory 1..1 OperatorRefStructure Reference to an OPERATOR.  
  To mandatory 0..1 ConnectionEndStructure Destination end of CONNECTION.  
  StopPlaceRef optional 0..1 StopPlaceRefStructure System identifier of a STOP PLACE. May be omitted if given by context. 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>
  <OperatorRef ref="ch:1:Operator:11" version="1"/>
  </OperatorView>
  </From>
  <To>
  <TransportMode>all</TransportMode>
  <OperatorView>
  <OperatorRef ref="ch:1:Operator:11" 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

SiteConnection

→ Glossary definition

Purpose

  • The SiteConnection describes the transfer times between two adjacent StopPlaces.
  • id-attribute 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 CONNECTION. Could also refer to a Quay or a different SiteElement. Currently, we only transfer StopPlaceRefs.
+ StopPlaceRef mandatory 0..1 StopPlaceRefStructure System identifier of a STOP PLACE. May be omitted if given by context.  
  To mandatory 0..1 ConnectionEndStructure Destination end of CONNECTION. Could also refer to a Quay or a different SiteElement. Currently, we only transfer StopPlaceRefs.
+ StopPlaceRef mandatory 0..1 StopPlaceRefStructure System identifier of a STOP PLACE. May be omitted if given by context.  

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

→ 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 1..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..* MultilingualString Name of Traveller Can be used to express “Neubaustrecke”, “Lötschbergbasistunnel” and the like.
  FromPointRef mandatory 1..1 VehicleMeetingPointRefStructure Identifier of VEHICLE MEETING POINT from which Link starts. 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 0..1 VehicleMeetingPointRefStructure Identifier of VEHICLE MEETING POINT at which Link ends. 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-attribute 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..* MultilingualString Name of Traveller  
  RouteView mandatory 1..1 RouteView Annotated reference to a ROUTE.  
+ LineRef mandatory 1..1 LineRefStructure Reference to a LINE.  
  DirectionType mandatory 0..1 RelativeDirectionEnumeration For fares for DISTANCE MATRIXE LEMENTs, DIRECTION in which price applies.  
  pointsInSequence mandatory 0..1 vehicleMeetingPointsInSequence_RelStructure Ordered set of points making up a ROUTE.  
+ StopPointInJourneyPattern mandatory 1..1 StopPointInJourneyPattern The use of a SCHEDULED STOP POINT in a specified order. within a JOURNEY PATTERN or SERVICE PATTERN.  
++ ScheduledStopPointRef mandatory 0..1 ScheduledStopPointRefStructure Specific SCHEDULED STOP POINT at end of CONNECTION.  
++ ForAlighting mandatory 0..1 xsd:boolean Whether alighting is allowed at the stop Default is true.  
++ ForBoarding mandatory 0..1 xsd:boolean Whether boarding is allowed at the stop. Default is true.  
++ DestinationDisplayRef optional 1..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 a request stop for this journey. Default is false.  
++ 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 which apply to SERVICE JOURNEY, e.g. check in time, security time. These are advisory only and not for use in journey planning.  
+++ CheckConstraint optional 1..1 CheckConstraint 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 Set of possible Booking Arrangements for Cancellations. +v2.0  
+++ BookingArrangementRef optional 1..1 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..1 BookingArrangement 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 Booking methods allowed. +v1.2.2  
  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-attribute 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..* MultilingualString Description of contents. Can be used if there exists a decription of the pattern.
  runTimes expected 0..1 vehicleJourneyRunTimes_RelStructure Run times for VEHICLE JOURNEY over different TIMING LINKs. The run time on the TimingLinks
+ JourneyRunTime expected 1..1 JourneyRunTime 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 0..1 xsd:duration Run time as interval.  
  waitTimes expected 0..1 vehicleJourneyWaitTimes_RelStructure WAIT TIMEs for VEHICLE JOURNEY at different TIMING POINTs. We only need wait times if greater than 0.
+ JourneyWaitTime expected 1..1 JourneyWaitTime 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 Specific SCHEDULED STOP POINT at end of CONNECTION. 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 Timetabled waiting 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..* MultilingualString Text content of NOTICe.  
+ @lang mandatory 1..1 xsd:string Attribute lang  
+ Text expected 0..* MultilingualString Text content of NOTICe.  
++ @lang mandatory 1..1 xsd:string Attribute lang  
  PublicCode mandatory 0..1 PublicCodeStructure Public code for JOURNEY. 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 A 20 bit number used for wireless cleardown of stop displays by some AVL systems. 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-attribute 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 1..1 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-attribute doesn’t need to be kept stable between exports.