------Dataset out of date------- ----Currently the data for node 2150 is not 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 bicycles, pedestrians, vehicle requests and bus messages are transmitted. Notes on latency: 4 minutes List of nodes: - 413: On the connecting railway / federal highway - 279: Edmund-Siemers-Allee / Grindelallee - 271: Theodor-Heuß-Platz / Edmund-Siemers-Allee - 2150: Edmund-Siemers-Allee / CCH Further 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 traffic lights for cyclists, pedestrians and motor vehicles in the Hamburg city area. When deployed to the traffic signal system, the following data streams are delivered as JSON objects: primary signals, secondary signals, auxiliary signals, acoustic signals, vehicle signal requests, cyclist signal requests, pedestrian signal requests, acoustic signal request, public transport pre-registration, public transport registration, public transport deregistration, signal congestion and wave second. In the OGC SensorThings API, the information about 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 in Coordinated Universal Time (UTC). In the Datastreams entity there is a JSON object under the "key" "properties" further "key-value pairs". Based on the service and layer structure in GIS, we have service and layer as additional "key-value pairs" introduced under the JSON object properties. Here is an example: { "properties":{ "serviceName": "HHSTAtraffic lights", "layerName": "primaysignal", "key":"value"} } Possible values for “layerName”: * primaysignal (primary signal), * secondarysignal (secondary signal), * auxiliarysignal (auxiliary signal), * acousticsignal (acoustic signal), * detectorcar (vehicle signal request), * detectorcyclist (cyclist signal request), * detectorpedestrian (pedestrian signal request), * detectoracoustictrafficrequest (acoustic signal request), * busprerequestpoint (public transport pre-registration), * busrequestpoint (public transport registration), * buscheckout (public transport checkout), * signalprogram (signal program status ), * cyclesecond (wave second) With the help of these "key-value pairs" Filters can then be defined for the REST request, e.g. https://iot.hamburg.de/v1.0/Datastreams?$filter=properties/serviceName eq 'HHSTAtraffic lights' and properties/layerName eq 'primarysignal' 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 broker: iot.hamburg.de Topic: v1.0/Datastreams({id} )/Observations
