Traffic Lights Data Hamburg

LSA process data
The dataset currently contains the LSA process data for about half of all nodes connected to the traffic computer network in Hamburg and contains current signal characteristics in real time. In addition, data is transmitted to detectors such as bicycle, pedestrian and vehicle requirements as well as bus messages.

The following points should be taken into account when using the data:

Maintenance work can occasionally lead to short signal transmission failures for several streets.
In a few cases, there are also faulty timestamps from the LSA ECUs (phenomenonTime), which are responsible for implausible latency values.

For a better understanding of the data, a user manual (Usage Guide) is linked in the References and Downloads section.

More information about the real-time service:

The OGC SensorThings API compliant real-time data service contains data streams and positions of lane relationships at intersections with light signalling systems for cyclists, pedestrians and motor vehicles in the Hamburg urban area. When provided to the light signal system, the following data streams are delivered as JSON objects: Primary signals, secondary signals, auxiliary signals, acoustic signals, vehicle signal requirements, cyclist signal requirements, pedestrian signal requirements, acoustic signal requirements, public transport pre-registration, public transport registration, public transport deregistration, signal program and wave second.
In the OGC SensorThings API, the information about the lane relationships is stored in the entity Thing. For the data streams listed above that are available at a specific thing, an entry is created in the Datastreams entity that references the corresponding thing.

All times are given in Coordinated Universal Time (UTC).

In the Datastreams entity, there are additional key-value pairs under the "key" "properties" in the JSON object. Following the service and layer structure in GIS, we have introduced service and layer as additional "key-value pairs" under the JSON property.

Here is an example:

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

All possible values for “layerName”:
* primay_signal (primary signal),
* secondäary_signal (secondary signal),
* auxiliary_signal,
* acoustic_signal,
* detector_car (car signal request),
* detector_cyclist (cyclist signal request),
* detector_pedestrian (pedestrian signal request),
* detector_acoustic_traffic_request,
* bus_pre-request_point (advance public transport booking),
* bus_request_point (public transport registration),
* bus_checkout (public transport deregistration),
* signal_program (signal program number),
* cycle_second

With the help of these "key-value pairs", filters can then be defined for the REST request, e.g.
https://tld.iot.hamburg.de/v1.1/Datastreams?$filter=properties/serviceName eq 'HH_STA_traffic_lights' and properties/layerName eq 'primary_signal'

The real-time data can also be obtained through an MQTT broker. The necessary IDs can be obtained via a REST request and then used for the subscription to a data stream:

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

Furthermore, the MAP files (xml and kml) as well as the OCIT-C files (supply file in xml format) of all already published nodes can be retrieved via the following link:
https://daten-hamburg.de/tlf_public/