Traffic data Rad (infrared detectors) Hamburg

General information: The dataset includes traffic data from all locations in Hamburg, where cycling is recorded by means of infrared detectors 24 hours a day and all days of the year. The dataset contains both the traffic strengths of individual counting fields and counting points aggregated from several counting fields in real time. The schematic structure of the data collection and data aggregation is described in a separate document, which can be found in the references. The data of the counting fields are provided in 5-minute intervals. The data of the counting points are available aggregated in 15- and 60-minute intervals as well as in daily and weekly values. The data of the counting points are also visualized in the corresponding geoportals of the FHH, e.g. in Geo-Online and the traffic portal. In addition to real-time data, historical data is also available to the following extent: Counting fields: all data since the beginning of the collection in 5-minute intervals. Counting points: all data for the last two weeks in 15-minute intervals, all data for the last two months in hourly intervals, all data for the current and the last year in daily intervals, and all data since the beginning of the collection in weekly intervals. Information on technology: The infrared detectors are usually installed on lighting poles, but in some cases also on other poles. The detectors record and count the traffic via the heat radiation of the individual traffic participants. Since only infrared images are evaluated, data protection is guaranteed at all times. Notes on data quality: The data is transmitted in real time to the Urban Data Platform of the FHH. This means that they are available to all users and interested parties in a timely manner. Due to the real-time component, however, various framework conditions must be observed: The data is not fully quality-assured. Unusual deviations from the expected data and data gaps are automatically detected by the system, but cannot be corrected in real time. Gaps, which occur e.g. due to a demolition of the data transmission, can still be delivered afterwards. Under certain circumstances and in the case of longer outages, changes in the historical data can therefore still take place after a few days. The data are therefore updated daily for the following periods: The day before: 5-min intervals, 15-min intervals and 60-min intervals Six days ago: 5-min intervals, 15-min intervals, 60-min intervals and daily intervals 28 days ago: 5-min intervals, 60-min intervals, daily intervals Weekly values are updated weekly for the previous week and the week before four weeks. The data published here are not officially verified data of the FHH. As with any traffic count, whether automated or manual, there are certain tolerances in measurement accuracy. The system used here requires accuracies for the counting fields of +/- 10% for the recording of cycle traffic on sidewalks, cycle paths and cycle lanes and +/-20% for the recording of cycle traffic in mixed traffic with motor vehicles. Since counting points are formed from a combination of different counting fields, the deviation can be up to +/-20%. More information about the real-time service: The real-time data service contains the active locations of the counting fields and counting points via which the current bicycle volume at the location is determined by means of infrared detectors. The data is provided in JSON format via the SensorThings API (STA). For each counting field and point in the SensorThings API (STA), there is an object in the entity "Thing". For each temporal (respective time interval) and spatial resolution level (count fields/count points), an object stands in the entity "Datastreams". The real-time data on the number of bicycles per time interval and unit of space is published in the STA in the entity "Observations". The temporal and spatial resolution levels can be found in the data set description. All times are given in Coordinated Universal Time (UTC). In the Datastreams entity, there are additional key-value pairs under the "key" "properties" in the JSON object. Following the service and layer structure in GIS, we have introduced service and layer as additional "key-value pairs" under the JSON property. Here is an example: { "properties":{ "serviceName": "HH_STA_HamburgerRadzaehlnetz", "layerName": "Number_Fahrraeder_Zaehlfeld_5-Min", "key":"value"} } Available layers in the layerName are: * Number of bicycles_Zaehlfeld_5-Min * Number of bicycles_point of destination_15-min * Number of bicycles_point of destination_1 hour * Number of bicycles_point of destination_1 day * Number_riding bikes_point_1-week 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 'HH_STA_HamburgerRadzaehlnetz' and properties/layerName eq 'Number_Fahrraeder_Zaehlfeld_5-Min' The real-time data can also be obtained through 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/Datastream({id})/Observations