Abfahrts-/Ankunftsanzeiger

[Datasets]

Originally published at: https://opentransportdata.swiss/de/cookbook/abfahrts-ankunftsanzeiger/
Der Abfahrts- und Ankunftsanzeiger ist als Open Service (API) verfügbar. Der Abfahrts- und Ankunftsanzeiger wird über den VDV431 – Dienst „StopEvent“ abgebildet. (Departure/arrival Display) Fachliche BeschreibungWichtige KonzepteTechnische AspekteAPI ExplorerAuthorisierung und Open ServicesURL für den AufrufBeispiel einer Abfrage Erläuterungen der Elemente des RequestsAusschnitt und Erläuterung einer ResponsePreviousCall / This Call / OnwardCallServiceFehler / ProblemeWeiterführende Angaben Fachliche…

[heuel]

Was ist der HTTP Statuscode, falls die Quota überschritten wird? Gibt es weitere spezifische Statuscodes?

[u200832]

Wir können keine abschliessende Liste aller durch das System erzeugten HTTP-Statuscodes liefern. Im Prinzip kann, in Abhängigkeit der jeweiligen Situation, jeder der offiziellen Statuscodes (https://de.wikipedia.org/wiki/HTTP-Statuscode) durch das System zurückgesendet werden.

[liip]

HTTP Statuscode wenn die Quota überschritten wird: 403
Zusätzlich wird als Antwort ein Fehler im JSON-Format zurückgegeben:
{"error": "Quota exceeded"}

HTTP Statuscode wenn die Rate Limit überschritten wird: 429
JSON-Antwort:
{"error": "Rate limit exceeded"}

[heuel]

Wie wird mit Ausfällen umgegangen? Nach unserer Erfahrung haben Ausfälle eine EstimatedTime der vor der TimetabledTime liegt.

Jedoch gab es bei unseren Tests Ausfälle, bei der gleichzeitig ein Ersatzzug angeboten wird, so dass der "normale" Reisende einen Ausfall gar nicht bemerkt.

[ue71603]

In der Message können auch die VDV 431 - Fehlermitteilungen auftreten: https://www.vdv.de/vdv-431-2-ekap-schnittstellenbeschreibung.pdfx?forced=true (Abschnitt 6.4).

[u200832]

Wird eine im Fahrplan geplante Fahrt nicht durchgeführt, so sprechen wir von einem Ausfall. Ausfälle können geplant sein oder aufgrund aktueller Ereignisse notwendig werden.

Normalerweise wird der Ausgefallene Zug manuell mit dem neuen Zug verknüpft, wenn ein Ersatzzug eingesetzt wird, sodass der Ausfall nicht wie auf dem Printscreen oben erscheint. Dies wurde im oberen Beispiel nicht gemacht, was zu der falschen Anzeige führt.

Bzgl. der Frage nach EstimatedTime vor TimetabledTime melde ich mich baldmöglichst bei Ihnen.

[ue71603]

Teilausfälle werden über den Teil der Fahrt abgebildet, den sie fahren. Ausfälle haben im<Service>-Element ein <Cancelled>true</Cancelled>. Neu angeordnete Züge ein <Unplanned>true</Unplanned>. Der direkte Zusammenhang, wenn ein Ersatzzug angeboten wird, ist in den übermittelten VDV-431-Daten nicht vorhanden.

[romanfrey]

Da ich auch in der Doku nicht fündig wurde erlaube ich mir die Frage wie man an die Gleisnummer/Perronkante des ThisCall rankommt?
Ist ja noch so eine essentielle Information für einen Abfahrtsanzeiger

[u200832]

@romanfrey PlannedBay und EstimatedBay sind aktuell noch nicht abrufbar. Diese Informationen werden ab ca. 2017/Q1 verfügbar sein. Danke für die Geduld!

[romanfrey]

Kein Problem, danke für die rasche Antwort. Dann muss ich nicht weiter suchen...

[stationsapp]

Habt jemand allenfalls einen Tipp, warum ich trotz Statuscode 200 OK immer einen leeren Response (Content-Length: 0) erhalte?

[u200832]

@stationsapp Wie lautet der request?

[stationsapp]

Hatte den Beispiel-Request versucht:

POST /trias HTTP/1.1
Authorization: 57.....
Content-Type: text/xml
Host: api.opentransportdata.swiss
Connection: close
User-Agent: Paw/3.0.14 (Macintosh; OS X/10.12.1) GCDHTTPRequest
Content-Length: 1409

<?xml version="1.0" encoding="UTF-8"?>
<Trias version="1.1" xmlns="http://www.vdv.de/trias" xmlns:siri="http://www.siri.org.uk/siri" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<ServiceRequest>
        <siri:RequestTimestamp>2016-12-13T06:37:00</siri:RequestTimestamp>
        <siri:RequestorRef>EPSa</siri:RequestorRef>
        <RequestPayload>
            <StopEventRequest>
                <Location>
                    <LocationRef>
                        <StopPointRef>8595543</StopPointRef>
                    </LocationRef>
                    <DepArrTime>2016-12-13T06:37:00</DepArrTime>
                </Location>
                <Params>
                    <NumberOfResults>30</NumberOfResults>
                    <StopEventType>departure</StopEventType>
                    <IncludePreviousCalls>false</IncludePreviousCalls>
                    <IncludeOnwardCalls>true</IncludeOnwardCalls>
                    <IncludeRealtimeData>true</IncludeRealtimeData>
                </Params>
            </StopEventRequest>
        </RequestPayload>
    </ServiceRequest>
</Trias>

[u200832]

@stationsapp Kannst du es nochmals versuchen? Ich erhalte keinen leeren Response mit genau diesem Request.

[stationsapp]

Zunächst mal vielen Dank für die rasche Reaktion!
Leider erhalte ich immer noch folgenden Response:

HTTP/1.1 200 OK
Accept-Ranges: none
Connection: close
Content-Length: 0
Content-Type: text/xml
Date: Tue, 13 Dec 2016 12:58:30 GMT
Last-Modified: Tue, 13 Dec 2016 12:58:30 GMT
Server: EFAController/10.2.2.28/WIN-G0NJHFUK71P
X-Ratelimit-Limit: 50001
X-Ratelimit-Remaining: 49987
X-Ratelimit-Reset: 1481631681
Strict-Transport-Security: max-age=21600000

[u200832]

@stationsapp Ich erhalte mit genau Ihrem Request (nutze HTTP Requester) eine Response. Bitte achten Sie unbedingt auf Folgendes:
URL: https://api.opentransportdata.swiss/trias (ohne /)
Headers:
Authorization mit Ihrem Key als Value
POST Abfrage

Bitte lesen Sie unbedingt nochmal die Hinweise unter https://opentransportdata.swiss/de/cookbook/verwendung-der-api/
und die weiterführenden Links. Ihr Request ist richtig, daran kann es nicht liegen.

[stationsapp]

Ich habe das Problem gefunden. Offenbar hat der Request-Parser ein Problem mit Whitespaces im XML. Nachdem ich diese entfernt hatte, funktioniert der Request.

[chregu]

Hier übrigens ein curl Request, der funktioniert. Habe zu viel Zeit damit verbracht, bis das ging (habe vor allem den Content-Type vergessen, was in einem nichtssagenden 400er Error geendet hat), drum teil ich das mal hier, vielleicht hilft's ja jemandem:

curl -H "Content-Type: text/xml" -H "Authorization: $YOURAPIKEY" -X POST https://api.opentransportdata.swiss/trias  --data '<?xml version="1.0" encoding="UTF-8"?><Trias version="1.1" xmlns="http://www.vdv.de/trias" xmlns:siri="http://www.siri.org.uk/siri" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ServiceRequest>
    <siri:RequestTimestamp>2016-12-26T20:47:00</siri:RequestTimestamp>
    <siri:RequestorRef>Anything</siri:RequestorRef>
    <RequestPayload>
        <StopEventRequest>
            <Location>
                <LocationRef>
                    <StopPointRef>8503052</StopPointRef>
                </LocationRef>
            </Location>
            <Params>
                <NumberOfResults>30</NumberOfResults>
                <StopEventType>departure</StopEventType>
                <IncludePreviousCalls>false</IncludePreviousCalls>
                <IncludeOnwardCalls>false</IncludeOnwardCalls>
                <IncludeRealtimeData>true</IncludeRealtimeData>
            </Params>
        </StopEventRequest>
    </RequestPayload>
</ServiceRequest></Trias>'

[chregu]

Kann es sein, dass DestinationStopPointRef zur Zeit die ID def Start-Station statt der Endstation liefert? Bei mir ist die jedenfalls identisch mit OriginStopPointRef. Irgendwo ein Bug?

<OriginStopPointRef>8503057</OriginStopPointRef>
<OriginText>
    <Text>Uetliberg</Text>
    <Language>DE</Language>
</OriginText>
<DestinationStopPointRef>8503057</DestinationStopPointRef>
<DestinationText>
    <Text>Zürich HB SZU</Text>
    <Language>DE</Language>
</DestinationText>