Services

In this chapter:

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

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
    Line "1" -- "1" DestinationDisplay : references

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

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 as the topological model of interchanges. They model the possibility of a transfer between two ScheduledStopPoints.
• Notices which are then assigned to Journey and Passingtime of the TimetableFrame through NoticeAssignments. They model the association of footnotes and passenger information content such as stop announcements and the network.

Table

Sub	Element	Usage	Card	Type	Description	Note
+	lines	mandatory	1..1	unknown		Only Line is used and not FlexibleLine
++	Line	mandatory	1..1	unknown
+	destinationDisplays	expected	1..1	unknown		We only allow fully formed content of destinationDisplays
++	DestinationDisplay	expected	1..1	unknown		We only allow fully formed content of destinationDisplays
+	scheduledStopPoints	mandatory	1..1	unknown		Swiss ScheduledStopPoint are using the sloid in the id, when possible.
++	SiteConnection	expected	1..1	unknown		SiteConnection are used only in the main file and not in timetable files.
++	DefaultConnection	expected	1..1	unknown		DefaultConnection is only used in the site file
+	stopAssignments	expected	1..1	unknown
++	PassengerStopAssignment	expected	1..1	unknown		are only used in a special PSA file in the export.
+	timingLinks	expected	1..1	unknown		We use TimingLink as the time behaviour between two ScheduledStopPoints
+	journeyPatterns	mandatory	1..1	unknown
++	ServiceJourneyPattern	mandatory	1..1	unknown
+	timeDemandTypes	expected	1..1	unknown
+	notices	expected	1..1	unknown		notices may be present or not
++	Notice	expected	1..1	unknown		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="any">
  <!-- 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>
  <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, when one exists. Otherwisse it contains a gen part. -->
    </ScheduledStopPoint>
  </scheduledStopPoints>
  <connections>
    <SiteConnection id="generated" version="1">
      <!-- SiteConnection are used only in the main file and not in timetable files. -->
    </SiteConnection>
    <DefaultConnection id="generated" version="1">
      <!-- DefaultConnection is only used in the site 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"/>
  </timeDemandTypes>
</ServiceFrame>

→ Template

Frame Relationships

ServiceFrame depends on ResourceFrame for Operator definitions. VehicleScheduleFrame may reference journeys defined here for block and duty scheduling. PassengerStopAssignments build the connection between ScheduledStopPoints and the physical model in SiteFrame. ServiceFrame is typically wrapped in a CompositeFramewithin 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

Sub	Element	Usage	Card	Type	Description	Note
	Line	mandatory	1..1	unknown		We have a duplication with responsibilitySet and OperatorRef. AuthorityRef is not used.
+	ValidBetween	expected	1..1	unknown		Usually set to the whole timetable year
++	FromDate	expected	1..1	unknown
++	ToDate	expected	1..1	unknown
+	keyList	mandatory	1..1	unknown
++	KeyValue	expected	1..1	unknown		The SLNID is mandatory, when it exists
+++	Key	expected	1..1	unknown
+++	Value	expected	1..1	unknown
+	Name	mandatory	1..1	unknown		contains attribute D T from HRDF. Is not translated on purpose.
+	ShortName	expected	1..1	unknown		contains the LinieKurzName (attribut N T in HRDF)
+	TransportMode	mandatory	1..1	unknown
++	RailSubmode	expected	1..1	unknown
+	PublicCode	mandatory	1..1	unknown		Contains LinieLangName (attribute LT from HRDF)
+	OperatorRef	optional	1..1	unknown		The operator is the transport organisation that really will do the operation. If different from AuthorityRef
+	TypeOfProductCategoryRef	mandatory	1..1	unknown		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">
  <!-- We have a duplication with responsibilitySet and OperatorRef. AuthorityRef is not used. -->
  <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>
  <Name>3</Name>
  <!-- contains attribute D T from HRDF. Is not translated on purpose. -->
  <ShortName>3</ShortName>
  <!-- contains the LinieKurzName (attribut N T in HRDF) -->
  <TransportMode>rail</TransportMode>
  <TransportSubmode>
    <RailSubmode>suburbanRailway</RailSubmode>
  </TransportSubmode>
  <PublicCode>3</PublicCode>
  <!-- Contains LinieLangName (attribute LT from HRDF) -->
  <OperatorRef ref="ch:1:Operator:11" version="1">
    <!-- The operator is the transport organisation that really will do the operation. If different from AuthorityRef -->
  </OperatorRef>
  <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 and id might need to be generated.
• We store the slnid whenever possible in id, privateCodes/PrivateCode and KeyList.
• TODO link to migration concept slnid #48
• TODO handling of mixed lines #48
• 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 neighbouring 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 https://www.xn–v-info-vxa.ch/sites/default/files/2023-06/slnid-spezifikation_v1.25_0.pdf
• id-attribute needs to be kept stable between exports.

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.

Table

Sub	Element	Usage	Card	Type	Description	Note
	DestinationDisplay	expected	1..1	unknown		We only allow fully formed content of destinationDisplays
+	Name	mandatory	1..1	unknown		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	1..1	unknown		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</Name>
  <!-- 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. -->
  <DriverDisplayText>Porrentruy</DriverDisplayText>
  <!-- Text to display to DRIVER. -->
  <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 usually set on the ServiceJourney. If it changes during the run, it needs to be changed in the ServiceJourneyPattern. If it changes on that, then the new destination should be used. In our output, we will fill all remaining PointsInJourneyPatternwith the relevant change.
• See also the use case on changes in destination
• id-attribute needs to be kept stable between exports.

TODO the rules for defining need to be clarified. #81

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

Sub	Element	Usage	Card	Type	Description	Note
+	ScheduledStopPoint	mandatory	1..1	unknown		Swiss ScheduledStopPoint are using the sloid in the id, when possible.
++	keyList	mandatory	1..1	unknown
+++	KeyValue	mandatory	1..1	unknown		We expect a DIDOK key and a SLOID, whereever possible.
++++	Key	mandatory	1..1	unknown
++++	Value	mandatory	1..1	unknown
++	privateCodes	mandatory	1..1	unknown
+++	PrivateCode	mandatory	1..1	unknown
++	Name	mandatory	1..1	unknown		The names are the same in all languages.
++	ShortName	mandatory	1..1	unknown		StopPlace : Name of the Place, Quay : ShortName of the Quay

-> General NeTEx definition

Example

<?xml version="1.0" encoding="UTF-8"?>
<scheduledStopPoints >
  <ScheduledStopPoint id="ch:1:sloid:4128:1:1" version="any">
    <!-- Swiss ScheduledStopPoint are using the sloid in the id, when possible. -->
    <keyList>
      <KeyValue>
        <!-- We expect a DIDOK key and a SLOID, whereever possible. -->
        <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</PrivateCode>
    </privateCodes>
    <Name lang="de">Murten/Morat</Name>
    <!-- The names are the same in all languages. -->
    <ShortName lang="de">1</ShortName>
    <!-- StopPlace : Name of the Place, Quay : ShortName of the Quay -->
  </ScheduledStopPoint>
</scheduledStopPoints>

->Template

Usage Notes

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

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.

Table

Sub	Element	Usage	Card	Type	Description	Note
	PassengerStopAssignment	mandatory	1..1	unknown
+	ScheduledStopPointRef	mandatory	1..1	unknown
+	StopPlaceRef	mandatory	1..1	unknown
+	QuayRef	expected	1..1	unknown		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

TODO Suppose a vehicle arrives at quay 2A and departs on quay 2D. In this case we model only the SCHEDULED STOP POINT for QUAY 2 but assign this STOP POINT to both QUAYs by using two different PASSENGER STOP ASSIGNMENTS. #82 https://github.com/openTdataCH/netexRealisationGuideSwitzerland/issues/82

• 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

Sub	Element	Usage	Card	Type	Description	Note
	DefaultConnection	expected	1..1	unknown		Be aware only some combinations areallowed mode - mode, operator/type of product category - operator/type of product category.
+	Extensions	optional	1..1	unknown		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	1..1	unknown		We use WalkTransferDuration. At some point we need a solution for bicyle duration too (TSI telemetics)
++	MobilityRestrictedTravellerDuration	expected	1..1	unknown
+	BothWays	optional	1..1	unknown		We always intend to use only one way, because the behaviour may not be the same.
+	From	mandatory	1..1	unknown
++	TransportMode	optional	1..1	unknown
++	OperatorView	optional	1..1	unknown
+++	OperatorRef	mandatory	1..1	unknown
+	To	mandatory	1..1	unknown
+	StopPlaceRef	optional	1..1	unknown		Is a sloid usually. 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 areallowed  mode - mode, operator/type of product category - operator/type of  product category. -->
  <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</BothWays>
  <!-- We always intend to use only one way, because the behaviour may not be the same. -->
  <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">
    <!-- Is a sloid usually. Not set, means whole network. -->
  </StopPlaceRef>
</DefaultConnection>

->Template

Usage Notes

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

SiteConnection

→ Glossary definition

Purpose

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

Table

Sub	Element	Usage	Card	Type	Description	Note
	SiteConnection	expected	1..1	unknown		SiteConnection are used only in the main file and not in timetable files.
+	WalkTransferDuration	mandatory	1..1	unknown
++	DefaultDuration	mandatory	1..1	unknown
+	BothWays	mandatory	1..1	unknown
+	From	mandatory	1..1	unknown		Could also refer to a Quay or a different SiteElement. Currently we only transfer StopPlaceRefs.
++	StopPlaceRef	mandatory	1..1	unknown
+	To	mandatory	1..1	unknown		Could also refer to a Quay or a different SiteElement. Currently we only transfer StopPlaceRefs.

-> 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 is used to describe the run times and wait times of a given ServiceJourney.

Table

• Swiss profile NeTEx definition

-> General NeTEx definition

Example

• Example snippet

->Template

Usage Notes

• It must fit with the sequence defined in ServiceJourneyPattern.
• WaitTimeis only needed when >0..
• It is between ScheduledStopPoints for the time being.
• If there is maneuvering or change of quay, then a a timing link needs to be added for that too.
• Multiple visits in the same ServiceJourneyPattern are currently a problem.
• id-attribute needs to be kept stable between exports.

TODO Adrian/Wilfried

ServiceJourneyPattern

→ Glossary definition

Purpose

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

Table

Sub	Element	Usage	Card	Type	Description	Note
	ServiceJourneyPattern	mandatory	1..1	unknown
+	Name	optional	1..1	unknown
+	RouteView	mandatory	1..1	unknown
++	LineRef	mandatory	1..1	unknown
+	DirectionType	mandatory	1..1	unknown
+	pointsInSequence	mandatory	1..1	unknown
++	StopPointInJourneyPattern	mandatory	1..1	unknown
+++	ScheduledStopPointRef	mandatory	1..1	unknown
+++	ForAlighting	mandatory	1..1	unknown
+++	ForBoarding	mandatory	1..1	unknown
+++	DestinationDisplayRef	optional	1..1	unknown		Indicates that the destination has changed. Superseeds Line or ServiceJourney
+++	RequestStop	optional	1..1	unknown
+++	StopUse	optional	1..1	unknown		All values possible
+++	bookingArrangements	optional	1..1	unknown
++++	BookingArrangementRef	optional	1..1	unknown		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	unknown
+	ServiceJourneyPatternType	expected	1..1	unknown

-> 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</StopUse>
      <!-- All values possible -->
      <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 effictiently and to reduce overall file size, 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 is used to describe the timing pattern (run times and wait times) on a ServiceJourneyPattern. They currently work on ScheduledStopPoints.

Table

• Swiss profile NeTEx definition

-> General NeTEx definition

Example

• Example snippet

->Template

Usage Notes

TODO Wilfried und Adrian

Notice

→ Glossary definition

Purpose

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

Table

Sub	Element	Usage	Card	Type	Description	Note
	Notice	expected	1..1	unknown
+	alternativeTexts	expected	1..1	unknown
++	AlternativeText	expected	1..1	unknown
+	Text	expected	1..1	unknown
+	@lang	mandatory	1..1	xsd:string	Attribute lang
+	PublicCode	mandatory	1..1	unknown		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	1..1	unknown		A duplication, but we want it.
+	PrivateCode	expected	1..1	unknown		A duplication, but we want it.
+	TypeOfNoticeRef	expected	1..1	unknown
+	CanBeAdvertised	expected	1..1	unknown		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">
  <alternativeTexts>
    <AlternativeText attributeName="Text">
      <Text>Catering zone / Vending machine</Text>
    </AlternativeText>
    <AlternativeText attributeName="Text">
      <Text>Zone catering / Distributeur</Text>
    </AlternativeText>
    <AlternativeText attributeName="Text">
      <Text>Zona catering / Distributore</Text>
    </AlternativeText>
  </alternativeTexts>
  <Text lang="de">Cateringzone / Automaten</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</ShortCode>
  <!-- A duplication, but we want it. -->
  <PrivateCode>A__SN</PrivateCode>
  <!-- A duplication, but we want it. -->
  <TypeOfNoticeRef ref="ch:1:TypeOfNotice:10" version="any"/>
  <CanBeAdvertised>true</CanBeAdvertised>
  <!-- Whether the NOTICE is advertised. -->
</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 ServiceFacilities but not as a replacement for them. Ideally, the description of a Notice is translated into common languages of CH (DE, IT, FR).

• id-attribute don’t need to be kept stable between exports.

NoticeAssignment

→ Glossary definition

Purpose

Assign a Notice to an element.

Table

Sub	Element	Usage	Card	Type	Description	Note
+	validityConditions	optional	1..1	unknown
++	AvailabilityConditionRef	optional	1..1	unknown
+	NoticeRef	expected	1..1	unknown

-> 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">
  <!-- Attribute `id` must be unique. -->
  <validityConditions>
    <AvailabilityConditionRef ref="ch:1:AvailabilityCondition:c3" version="1"/>
  </validityConditions>
  <NoticeRef ref="ch:1:Notice:Hin-1229900" version="1"/>
</NoticeAssignment>

->Template

Usage Notes

• id-attribute does not to be kept stable.