Showcase Traffic Light Forecast Hamburg (historical)

—Dataset obsolete— —Currently, the data for the node 2150 will not be updated— The dataset includes LSA process data for four 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. Notes on latency: 4 minutes List of nodes: — 413: At The junction railway/Bundesstraße — 279: Edmund-Siemers-Allee/Grindelallee — 271: Theodor-Heuß-Platz/Edmund-Siemers-Allee — 2150: Edmund-Siemers-Allee/CCH 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”} } 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 (signal program status), * cycle_second (wavesecond) With the help of these “key-value pairs” filters can be defined for the REST request, e.g. https://iot.hamburg.de/v1.0/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: iot.hamburg.de Topic: v1.0/Datastreams({id})/Observations