Traffic Lights Data Hamburg (beta)

LSA Process Data — Beta Version The dataset includes LSA process data for a variety of nodes in Hamburg and contains current signal expressions in real time. In addition, data on detectors such as bicycles, pedestrians, vehicle requirements and bus messages are transmitted. This version is a BETA. The following points should be taken into account when using the data: 1. The system is still in test mode and is evaluated, so it can be: a. Unforeseeable failures in data transmission and b. Failures in the data update come c. Decreases in performance in data transmission come 2. Final quality assurance has not yet been carried out. a. Data may be incorrect. This can affect the location in particular. b. The description of the entities is partially incomplete c. possible inconsistency of the timestamps in the observations, such as ResultTime (timestamp of the TLD— Systems) BEFORE phenomenonTime (timestamp of the signal from the light signal system). For a better understanding of the data, a mapping table with further descriptions will soon be linked here. For 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 city of Hamburg. When provided to the light signal system, the following data streams are delivered as JSON objects: Primary signals, secondary signals, auxiliary signals, acoustic signals, automotive signal requirements, cyclist signal requirements, pedestrian signal requirements, acoustic signal requirement, public transport pre-registration, public transport notification, public transport alarm, signal jam and wave second. In the OGC SensorThings API, the information on the lane relationships is stored in the entity Thing. For the data streams listed above, which are available at a specific thing, an entry is created in the entity Datastreams that references the corresponding thing. All times are given in the Coordinated World Time (UTC). In the entity Datastreams, there are other “key-value pairs” in the JSON object under the “key” “properties”. Based on the service and layer structure in the GIS, we introduced service and layer as additional “key-value pairs” under the JSON object properties. Here is an example: { “properties”: { “service name”: “HH_STA_traffic_lights”, “layername”: “primay_signal”, “key”:“value” } } All possible values for “layerName”: * primay_signal (primary signal), * secondary_signal (secondary signal), * auxiliary_signal (help signal), * acoustic_signal (acoustic signal), * detector_car (car signal requirement), * detector_cyclist (bicycle driver signal requirement), * detector_pedestrian (pedestrian signal requirement), * detector_acoustic_traffic_request (acoustic signal requirement), * bus_pre_request_point (public transport pre-registration), * bus_request_point (public transport registration), * bus_checkout (unregistering public transport), * signal_program (number of the signal program), * cycle_second (wavesecond) With the help of these “key-value pairs” filters can 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 via an MQTT broker. The necessary IDs can be obtained via a REST request and then used for the subscription to a data stream: MQTT brokers: tld.iot.hamburg.de Topic: v1.1/Datastreams({id})/Observations