------Data set out of date------- ----The data for node 2150 is not currently being updated---- The data set includes LSA process data for four nodes in Hamburg and contains current signal characteristics in real time . In addition, data on detectors such as bicycle, pedestrian, vehicle requirements and bus messages are transmitted. Notes on latency: 4 minutes Listing of nodes: - 413: An der Verbindungsbahn / Bundesstraße - 279: Edmund-Siemers-Allee / Grindelallee - 271: Theodor-Heuß-Platz / Edmund-Siemers-Allee - 2150: Edmund-Siemers-Allee / CCH Further information on the real-time service: The OGC SensorThings API-compliant real-time data service contains data streams and positions of lane relationships at intersections with traffic lights for cyclists, pedestrians and motor vehicles in the Hamburg city area. If provided at the traffic signal system, the following data streams are delivered as JSON objects: primary signals, secondary signals, auxiliary signals, acoustic signals, car signal requests, bicycle signal requests, pedestrian signal requests, acoustic signal requests, public transport pre-registration, public transport registration, public transport de-registration, signal congestion and wave second. In the OGC SensorThings API, the information on the lane relationships is stored in the Thing entity. For the data streams listed above that are available on 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 further "key-value pairs" in the JSON object under the "key" "properties". Based on the service and layer structure in GIS, we introduced service and layer as additional "key-value pairs" under the JSON object properties. Here is an example: { "properties":{ "serviceName": "HH_STA_traffic_lights", "layerName": "primay_signal", "key":"value"} } Possible values for “layerName”: * primay_signal (primary signal), * secondary_signal (secondary signal), * auxiliary_signal (auxiliary signal), * acoustic_signal (acoustic signal), * detector_car (car signal request), * detector_cyclist (cyclist signal request), * detector_pedestrian (pedestrian signal request), * detector_acoustic_traffic_request (acoustic signal request), * bus_pre_request_point (public transport pre-registration), * bus_request_point (public transport registration), * bus_checkout (public transport deregistration), * signal_program (signal program status), * cycle_second (wave second) With the help of these "key-value pairs", filters for the REST request can then be defined, 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 IDs required for this can be obtained via a REST request and then used to subscribe to a data stream: MQTT broker: iot.hamburg.de Topic: v1.0/Datastreams({id})/Observations
