LSA-Prozessdaten
Der Datensatz umfasst momentan die LSA-Prozessdaten für rund die Hälfte aller am Verkehrsrechnernetz angeschlossenen Knoten in Hamburg und enthält aktuelle Signalausprägungen in Echtzeit. Zusätzlich werden Daten zu Detektoren wie Fahrrad-, Fußgänger- und Kfz- Anforderungen sowie Busmeldungen übertragen.

Folgende Punkte sollten bei der Nutzung der Daten berücksichtigt werden:

Durch Wartungsarbeiten kann es vereinzelt zu kurzen Ausfällen bei der Signalübertragung für mehrere Straßenzüge kommen.
In wenigen Fällen gib es außerdem fehlerhafte Zeitstempel aus den LSA-Steuergeräten (phenomenonTime), die für unplausible Werte bei der Latenz verantwortlich sind.



Für ein besseres Verständnis der Daten, ist im Bereich Verweise und Downloads ein Benutzerhandbuch (Usage Guide) verlinkt.

Weitere Informationen zum Echtzeitdienst:

Der OGC SensorThings API konforme Echtzeitdatendienst enthält Datenströme und Positionen von Fahrspurbeziehungen an Kreuzungen mit Lichtsignalanlagen für Fahrradfahrer, Fußgänger sowie Kraftfahrzeuge im Hamburger Stadtgebiet. Wenn an der Lichtsignalanlage bereitgestellt, werden folgende Datenströme als JSON-Objekte ausgeliefert: Primärsignale, Sekundärsignale, Hilfssignale, Akustiksignale, KFZ-Signalanforderungen, Fahrradfahrersignalanforderungen, Fußgängersignalanforderungen, Akustiksignalanforderung, ÖPNV-Voranmeldung, ÖPNV-Anmeldung, ÖPNV-Abmeldung, Signalprogramm und Wellensekunde.
In der OGC SensorThings API sind die Informationen zu den Fahrspurbeziehungen in der Entität Thing hinterlegt. Für die oben aufgelisteten Datenströme, die an einem konkreten Thing verfügbar sind, wird ein Eintrag in der Entität Datastreams erstellt, der das entsprechende Thing referenziert.

Alle Zeitangaben sind in der koordinierten Weltzeit (UTC) angegeben.

In der Entität Datastreams gibt es im JSON-Objekt unter dem "key" "properties" weitere "key-value-Paare". In Anlehnung an die Service- und Layerstruktur im GIS haben wir Service und Layer als zusätzliche "key-value-Paare" unter dem JSON-Objekt properties eingeführt.

Hier ein Beispiel:

{
"properties": {
"serviceName": "HH_STA_traffic_lights",
"layerName": "primay_signal",
"key":"value"
}
}

Alle möglichen values für “layerName”:
* primay_signal (Primärsignal),
* secondäary_signal (Sekundärsignal),
* auxiliary_signal (Hilfssignal),
* acoustic_signal (Akustiksignal),
* detector_car (KFZ-Signalanforderung),
* detector_cyclist (Fahrradfahrersignalanforderung),
* detector_pedestrian (Fußgängersignalanforderung),
* detector_acoustic_traffic_request (Akustiksignalanforderung),
* bus_pre-request_point (ÖPNV-Voranmeldung),
* bus_request_point (ÖPNV-Anmeldung),
* bus_checkout (ÖPNV-Abmeldung),
* signal_program (Nummer des Signalprogramms),
* cycle_second (Wellensekunde)

Mit Hilfe dieser "key-value-Paare" können dann Filter für die REST-Anfrage definiert werden, bspw.
https://tld.iot.hamburg.de/v1.1/Datastreams?$filter=properties/serviceName eq 'HH_STA_traffic_lights' and properties/layerName eq 'primary_signal'

Die Echtzeitdaten kann man auch über einen MQTT-Broker erhalten. Die dafür notwendigen IDs können über eine REST-Anfrage bezogen werden und dann für das Abonnement auf einen Datastream verwendet werden:

MQTT-Broker: tld.iot.hamburg.de
Topic: v1.1/Datastreams({id})/Observations


Ferner können über folgenden Link die MAP-Dateien (xml und kml) sowie die OCIT-C-Dateien (Versorgungsdatei im Format xml) aller bereits veröffentlichter Knoten abgerufen werden:
https://daten-hamburg.de/tlf_public/