LSA process data - beta version The data set includes LSA process data for a large number of nodes in Hamburg and contains current signal characteristics in real time. In addition, data is transmitted to detectors such as bicycle, pedestrian and vehicle requests as well as bus reports. This version is a BETA version. The following points should be considered when using the data: 1. The system is still in test operation and is being evaluated, so it can: a. Unforeseeable failures in data transmission and b. There are dropouts in the data update c. 2. A final quality assurance has not yet taken place. a. Data can be incorrect. This can particularly affect the location. b. The description of the entities is still partially incomplete c. possible inconsistency of the time stamps in the observations, such as resultTime (time stamp of the TLD system) BEFORE phenomenonTime (time stamp of the signal from the traffic signal system). For a better understanding of the data, a user manual 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 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 program 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 concrete 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" } } All possible values for “layerName”: * primay_signal (primary signal), * secondäary_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 de-registration), * signal_program (number of the signal program), * cycle_second (wave second) With the help of these "key-value pairs" you can then filter for the REST request be defined, 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 viewed via an MQTT get brokers. The IDs required for this can be obtained via a REST request and then used to subscribe to a data stream: MQTT broker: tld.iot.hamburg.de Topic: v1.1/Datastreams({id})/Observations The MAP files (.xml and .kml) of all already published nodes can be accessed via the following link: https://daten-hamburg.de/tlf_public/
