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) VOR phenomenonTime (time stamp of the signal from the traffic signal system). For a better understanding of the data, is in the area References and downloads are linked in a user manual. 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 Hamburg urban 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 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, in the JSON object under the "key" "properties" more "key-value-pairs". Based on the service and layer structure in GIS, we have defined 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" } } All possible values for “layerName”: * primaysignal (primary signal), * secondäarysignal (secondary signal), * auxiliarysignal (auxiliary signal), * acoustic signal (acoustic signal), * detectorcar (car signal request), * detectorcyclist (cyclist signal request), * detectorpedestrian (pedestrian signal request), * detectoracoustictrafficrequest (acoustic signal request), * buspre-requestpoint (public transport pre-registration), * busrequestpoint (public transport registration), * bus checkout (public transport checkout), * signalprogram (signal program number), * cycle_second (wave second) Using these "key-value pairs" filters can then be defined for the REST request, e.g. https://tld.iot.hamburg.de/v1.1/Datastreams?$filter=properties/serviceName eq 'HHSTAtrafficlights' and properties/layerName eq 'primarysignal' 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: tld.iot.hamburg.de Topic: v1.1/Datastreams({ id})/Observations Furthermore, the MAP files (.xml and .kml) of all published nodes can be accessed via the following link: https://daten-hamburg.de/tlf_public/
