Skip to content
LoginRegister
DEENFRIT
Home
Open-Data-Plattform Mobilität Schweiz
  2. Cookbook
  3. OJPTripRequest

OJPTripRequest

Wichtige Konzepte

  • Haltestellen: Hierfür können auch die Datensätze DiDok beigezogen werden.
  • Fahrten: Eine Fahrt ist die Beförderung von Kunden auf einem bestimmten Weg, einer bestimmten Fahrplan-Verbindung, mit einem bestimmten Verkehrsmittel-Fahrt, zu einer bestimmten Zeit, in eine bestimmte Richtung.
  • Fahrplan: Ein Fahrplan legt im öffentlichen Personennah- und -fernverkehr und im Schienengüterverkehr den Fahrtverlauf eines Verkehrsmittels fest. Dabei notwendige Angaben sind Zugnummer, Verkehrstage, Fahrweg, Ankunfts-, Abfahrts- und Durchfahrtszeiten an den Haltestellen sowie die zulässigen Geschwindigkeiten in den einzelnen Abschnitten des Fahrwegs.
  • Prognose: Die Prognose sind die in der Zukunft liegenden Verkehrszeiten eines Zuges, die ausgehende vom aktuellen Standort des Zuges berechnet werden. Dabei werden Konflikte und deren aktuell intendierten Regelungen in den nächsten x Minuten berücksichtigt. Der weitere Verlauf der Prognose wird nach einer weniger aufwendigen Methode berechnet
  • Verkehrsmittel (VM): Entweder gleichbedeutend mit Fahrzeugen (Zug, Schiff, Tram, Bus) der verschiedenen Verkehrsträger oder im Sinne von «Verkehrssystem» gebraucht (öffentliches Verkehrsmittel usw.).
  • DateTime in Response: Es handelt sich immer um Zulu-Zeit (d.h. UTC).  Es gilt im Sommer zwei Stunden und im Winter eine Stunde dazu zu zählen.

OJP Trip Service

TripRequest ist der zentrale Dienst. Mit Angabe von Origin und Destination wird ein Trip geplant.

Ein Trip hat verschiedene “Legs” (Abschnitte).

API-Explorer

Sie können eigene Requests ausprobieren – direkter Link zum API-Explorer.

Request

Element Kardinalität Beschreibung Beispiel
RequestTimestamp 1:1 Der Timestamp des Requests. Bevorzugt als Zulu-Time.
MessageIdentifier 0:1 Der Identifier der Message. Am liebsten strikt monoton steigend.
ojp:Origin 1:* Der Startpunkt der Suche. OJP bietet relativ viele Möglichkeiten, dies zu modellieren.

Mehr Infos im entsprechenden Abschnitt.

ojp:Destination 1:* Der Zielpunkt der Suche. OJP bietet relativ viele Möglichkeiten, dies zu modellieren.

Mehr Infos im entsprechenden Abschnitt.

ojp:Via 0:1 Ein Via wird unterstützt. Müssen mehrere Vias berücksichtigt werden oder soll ein Rundkurs berechnet werden, so muss das anfragende System den selber aufteilen in einzelne Trips, die separat gesucht werden.

ojp:Params 0:1 Die weiteren Parameter. Siehe entsprechenden Abschnitt

Struktur Origin/Destination

Elemente Kardinalität Beschreibung Beispiel
 ojp:PlaceRef/siri:StopPointRef 0:1 Verweis auf StopPoint.

Achtung: Sowohl Didok wie auch sloid können vorkommen. Mehr Infos.

ojp:PlaceRef/ojp:StopPlaceRef 0:1 Referenz auf eine Haltestelle

ojp:PlaceRef/ojp:GeoPosition 0:1 WGS84 Koordinaten

ojp:PlaceRef/ojp:TopographicPlaceRef 0:1 Verweis auf einen “Ort. Schwierig, da die Werte nicht erraten werden können

 

ojp:PlaceRef/ojp:PointOfInterestRef 0:1 Verweis auf einen Point of Interest. Der Location Name wird ignoriert.

 

ojp:PlaceRef/ojp:AddressRef 0:1 Verweis auf eine Adresse

 

ojp:PlaceRef/ojp:LocationName 1:1 Öffentlicher Name des Orts

Achtung: Der Name wird ignoriert. Es muss zuerst ein LocationRequest durchgeführt werden, der dann eine Ref oder eine Koordinate liefert!

ojp:DepArrtime 0:1 Zeit, die verwendet werden soll.

“Z” ist Zulu-Zeit (also zeitzonenunabhängig). Bei Z müssen unbedingt die Sekunden auch angegeben werden. Stimmt das Format nicht oder ist kein Z vorhanden, versucht das System, die Zeit als lokale Zeit zu interpretieren.

ojp:TimeAllowance 0:1 Anstelle von DepArrTime. Zusatzzeit, die für das Erreichen und Verlassen der Location nötig ist.

IndividualTransportOptions 0:* Optionen für den Weg von und zu den Haltestellen

Siehe separate Tabelle

IndividualTransportOptions

Elemente Kardinalität Beschreibung Beispiel
 ojp:Mode 1:1 Modus, mit dem der Origin erreicht werden soll. Im Moment wird nur walk unterstützt.

Werte ansonsten:

  • walk
  • cycle
  • taxi
  • self-drive-car
  • others-drive-car
  • motorcycle
  • truck
ojp:MaxDistance 0:1 Maximale Distanz in Metern. Damit werden die Routen minimiert.
ojp:MaxDuration 0:1 Maximale Dauer. Steuert den Router bezüglich der maximalen Dauer. Das Format ist zu beachten. Es ist eine xs:duration.
ojp:MinDistance 0:1 Minimale Distanz in Metern. Damit werden die Routen minimiert.

Das Feature wird nicht unterstützt.

ojp:MinDuration 0:1 Minimale Dauer. Steuert den Router bezüglich der minimalen Dauer. Das Format ist zu beachten. Es ist eine xs:duration.

Das Feature wird nicht unterstützt.

ojp:Speed 0:1 Relative Geschwindigkeit in Prozent. Normal ist 100%.

Params

Element Kardinalität Beschreibung Beispiel
ojp:PtModeFilter  0:1 Der Filter sagt, welche Modes berücksichtigt werden sollen.

Die Listen der Modes und Submodes entstammen aus SIRI. im XSD sind sie aufgeführt.

ojp:LineFilter  0:1 Linien, die ein- oder ausgeschlossen werden sollen.

 

ojp:OperatorFilter 0:1 Betreiber, die ein- oder ausgeschlossen werden sollen.

 

ojp:PrivateModeFilter 0:1 Sollen private Modi verwendet werden oder nicht.

Das Feature steht nicht zur Verfügung.

 n/a
ojp:NoSingleStep 0:1 Der Benutzer kann keinen Absatz überwinden.

Das Feature steht nicht zur Verfügung.

  n/a
ojp:NoStairs 0:1 Der Benutzer kann keine Treppe benutzen.

Das Feature ist geplant, aber in der aktuellen Version (1.0) noch nicht verfügbar.

 n/a
ojp:NoEscalator 0:1 Der Benutzer kann keine Rolltrippe benutzen.

Das Feature ist geplant, aber in der aktuellen Version (1.0) noch nicht verfügbar.

 n/a
ojp:NoElevator 0:1 Der Benutzer kann keinen Fahrstuhl benützen.

Das Feature ist geplant, aber in der aktuellen Version (1.0) noch nicht verfügbar.

 n/a
ojp:NoRamp 0:1 Der Benutzer kann keine Rampe benützen

Das Feature steht nicht zur Verfügung.

 n/a
ojp:LevelEntrance 0:1 Der Benutzer benötigt ebenerdige Eingänge/Übergänge

Das Feature ist geplant, aber in der aktuellen Version (1.0) noch nicht verfügbar.

 n/a
ojp:BikeTransport 0:1 Der Benutzer möchte ein Fahrrad mitnehmen

Das Feature ist geplant, aber in der aktuellen Version (1.0) noch nicht verfügbar.

 n/a
ojp:WalkSpeed 0: Abweichung vor normalen Laufgeschwindigkeit. 100% normal.

Das Feature ist geplant, aber in der aktuellen Version (1.0) noch nicht verfügbar.

 n/a
ojp:NumberOfResults 0:1 Anzahl Resultate

ojp:NumberOfResultsBefore 0:1 Anzahl Resultate vor einer gegebenen Zeit (am Ziel oder am Start).

Will ein OJP-Client zu den bereits erhaltenen Fahrten noch nächst frühere erhalten, so muss er einen neuen Request mit NumberOfResultsBefore=n und Destination.DepArrTime = früheste gefundene EndTime in der letzten Antwort minus 1 Minute senden.

ojp:NumberOfResultsAfter 0:1 Anzahl Resultate nach einer gegebenen Zeit (am Ziel oder am Start)

Will ein OJP-Client zu den bereits erhaltenen Fahrten noch nächst spätere erhalten, so muss er einen neuen Request mit NumberOfResultsAfter=n und Origin.DepArrTime = späteste gefundene StartTime in der letzten Antwort plus 1 Minute senden.

ojp:IgnoreRealtimeData 0:1 Sollen Echtzeitdaten mit berücksichtigt werden?

ojp:ImmediateTripStart 0:1 Soll angenommen werden, dass der Benutzer bereits auf dem Weg ist?

Wird nicht unterstützt.

 n/a
ojp:TransferLimit 0:1 Maximale Anzahl Umstiege

ojp:OptimisationMethod 0:1 Welche Optimisierungsmethode soll verwendet werden?

fastest, least walking, etc

Das Feature ist geplant, aber in der aktuellen Version (1.0) noch nicht verfügbar.

 n/a
ojp:ItModesToCover 0:* Für jeden Modus in der Liste soll ein separater monomodaler Trip gefunden werden, zusätzlich zu den intermodalen Trips.

Wird neu seit August 2022 für Sharing-Angebote unterstützt.

 Siehe Kapitel zu Sharing unten.
ojp:IncludeTrackSection 0:1 Soll die Information TrackSection Information beinhalten, der eine geographische Projektion eines Legs erlaubt. Es werden TrackStart, TrackEnd und Duration ausgegeben.

Die Information muss natürlich vorhanden sein (im Moment eher weniger).

ojp:IncludeLegProjection 0:1 Soll das Resultat die geographische Präsentation eines Legs beinhalten. Bei öV-Legs wird dies im Moment unterdrückt, da der Linienverlauf nicht bekannt ist. Für die “walk”-Legs wird dies noch gemacht werden.

 

ojp:IncludeTurnDescription 0:1 eine detaillierte Wegbeschreibung für jedes Leg wird angegeben in den PathGuidance.

ojp:IncludeAccessibility 0:1 Sollen BehiG-Informationen eingefügt werden.

Das Feature ist geplant, aber in der aktuellen Version (1.0) noch nicht verfügbar.

ojp:IncludeIntermediateStops 0:1 Gibt an, ob Haltestellen auch angegeben werden sollen, während der einzelnen Fahrt. d.h. alle Zwischenhalte.

ojp:IncludeFare 0:1 Sollen Preisangaben eingefügt werden.

Das Feature wird im Moment nicht unterstützt.

ojp:Extension 0:1 Wird für gewisse Sharing-Modi verwendet. Siehe Kapitel zu Sharing unten.

 

Response

Ein Beispiel einer ganzen Antwort: tripresponse

Zuerst wird ojp:TripResponseContext geliefert. Dieser enthält Angaben zu allen verwendeten Places (Haltestellen, Ortschaften, Adressen,..) im Element ojp:Places:

In Zukunft kann der Kontext auch die Situations (Störungen) beinhalten.

Danach kommen 0:* TripResult. Nach dem Header

folgen einzelne Trips.

Wenn nicht von und zu einer Haltestelle gerechnet wurde, dann kommen zuerst Legs, die zur Haltestelle führen.

Ansonsten kommt ein TimedLeg.

Bemerkungen:

  • Realtime leider noch nicht verfügbar. Sonst wären die entsprechenden Angaben schon integriert.
  • Die XXXRef werden mit den neuen Swiss Identifers nach und nach angepasst.
  • Die DestinationStopPointRef sind noch nicht ideal.
  • Die Attribute bilden sich aus den bekannten Attributen aus HRDF mit A__ .

Einige Punkte sind in Extensions abgelegt:

 

Beim Umsteigen werden TransferLegs verwendet:

Gerade bei den Transfers werden im Rahmen des BehiG Verbesserungen notwendig sein.

Verwendete geographische Information

Das Fusswegrouting basiert auf OpenStreetMap (OSM). Die folgenden Teile basieren im Moment ausschliesslich auf OSM:

Im ContinuousLeg und TransferLeg (TransferMode=walk):

  • TrackSection (ohne Koordinaten, weil die LegProjection wegen fehlender Fahrtrouten nur für alle LegArten gemeinsam auskonfiguriert werden kann)
  • TurnAction
  • im TimedLeg
  • LegIntermediates

Wichtig:

  • IncludeAccessibility wird erst ab BehiG unterstützt

OSM-Daten sind verfügbar unter der Open Data Commons Open Database-Lizenz (ODbL). Anwendungen, die OSM nutzen, müssen OSM als Quelle angeben. Auf welche Art dies geschehen kann (je nach Art der Anwendung), kann in den OSM Richtlinien für Namensnennungen nachgelesen werden.

OJP-TripRequest mit Sharing-Anbietern

Neu seit August 2022 können mit dem OJP TripRequest Reiseketten mit Sharing-Fahrzeugen (Fahrrad, eScooter, Leihrad oder Carsharer) am Anfang und/oder Ende (erste und/oder letzte Meile) berechnet werden.

Allgemeine Hinweise

Die Funktionalität hat vorerst experimentellen Charakter. Es können unerwartete oder wenig praxistaugliche Reiseketten resultieren. Das SKI+-Team nimmt gerne Feedback dazu entgegen.

Soweit möglich wurden Elemente des OJP-1.0-Standard verwendet. Einige Erweiterungen mussten jedoch mittels Extensions umgesetzt werden. Im Hinblick auf die geplante neue Major-Version OJP 2.0 sind Anpassungen zu erwarten.

Die Berechnungen basieren auf dieser Datenquelle.

Alternativ zum TripRequest können die Standorte der Sharing-Fahrzeugen neu über den OJPLocationInformationRequest abgerufen werden.

Parameter zur Steuerung des TripRequest

Die Steuerung der Abfrage im TripRequest erfolgt über Parameter (zusätzliche XML-Elemente) an vier möglichen Stellen:

1. Monomodale Reisen mit Fahrrad

Gemäss OJP-1.0-Standard wird dafür <ojp:Params> mit dem Element <ojp:ItModesToCover> ergänzt, mit dem Wert “cycle”:

2. Monomodale Reisen mit eScooter, Leihrad oder Carsharing

<ojp:Params> wird mit einer Extension erweitert:

mit “escooter_rental”, “bicycle_rental” oder “car_sharing”, respektive.

3. Intermodale Reisen mit öV und mit einem Fahrrad am Anfang und/oder Ende

Gemäss OJP-1.0-Standard erhalten <ojp:Origin> und/oder <ojp:Destination> das Element <ojp:IndividualTransportOptions>. Darin werden Mode (cycle), Dauer min./max. in Minuten und Distanz min./max. in Meter definiert, wie im folgenden Beispiel dargestellt.

4. Intermodale Reisen mit öV und mit einem eScooter, Leihrad oder Carsharing am Anfang und/oder Ende

<ojp:Params> wird mit einer Extension erweitert, mit sinngemäss <ojp:Origin> und/oder <ojp:Destination> und mit Mode escooter_rental, bicycle_rental oder car_sharing, respektive, wie im folgenden Beispiel dargestellt:

Überblick der Kombinationsmöglichkeiten

Die folgende Tabelle zeigt, welche Kombinationen für monomodale und multimodale Reisen sinnvoll sind. (Beachte: der öffentliche Verkehr wird hier als ein Modus betrachtet, auch wenn mit verschiedenen Verkehrsmitteln und Umsteigen verbunden):

Kombination
 Monomodale Reise Multimodal —
Modus am Anfang		 Multimodal —
Modus am Ende		 Modus Anfang & Ende
öffentlicher Verkehr default — — —
zu Fuss ItModesToCover=walk  oder
IndividualTransportOptions=walk (Wanderungen, s. oben)		 default default default
mit eigenem Fahrrad ItModesToCover=
cycle		 IndividualTransportOptions
… Mode=cycle		 — —
mit eigenem Auto ItModesToCover=
self-drive-car		 — — —
Fahrrad Sharing Ext./ItModesToCover=
bicycle_rental		 Ext./Origin/Mode=
bicycle_rental		 Ext./Destin./Mode=
bicycle_rental		 möglich, wenn Origin und Destin. Modes gleich
e-Scooter Sharing Ext./ItModesToCover=
escooter_rental		 Ext./Origin/Mode=
escooter_rental		 Ext./Destin./Mode=
escooter_rental		 möglich, wenn Origin und Destin. Modes gleich
Car Sharing Ext./ItModesToCover=
car_sharing		 — Ext./Destin./Mode=
car_sharing		 —