Provide traffic accident data in JSON format (Type A2) that causes injury to personnel or death exceeding 24 hours.

This dataset was acquired during Cyber Czech – a hands-on cyber defense exercise (Red Team/Blue Team) held in March 2019 at Masaryk University, Brno, Czech Republic. Network traffic flows and a high variety of event logs were captured in an exercise network deployed in the KYPO Cyber Range Platform.

Contents

The dataset covers two distinct time intervals, which correspond to the official schedule of the exercise. The timestamps provided below are in the ISO 8601 date format.

Day 1, March 19, 2019

Start: 2019-03-19T11:00:00.000000+01:00

End: 2019-03-19T18:00:00.000000+01:00

Day 2, March 20, 2019

Start: 2019-03-20T08:00:00.000000+01:00

End: 2019-03-20T15:30:00.000000+01:00

The captured and collected data were normalized into three distinct event types and they are stored as structured JSON. The data are sorted by a timestamp, which represents the time they were observed. Each event type includes a raw payload ready for further processing and analysis. The description of the respective event types and the corresponding data files follows.

cz.muni.csirt.IpfixEntry.tgz – an archive of IPFIX traffic flows enriched with an additional payload of parsed application protocols in raw JSON.

cz.muni.csirt.SyslogEntry.tgz – an archive of Linux Syslog entries with the payload of corresponding text-based log messages.

cz.muni.csirt.WinlogEntry.tgz – an archive of Windows Event Log entries with the payload of original events in raw XML.

Each archive listed above includes a directory of the same name with the following four files, ready to be processed.

data.json.gz – the actual data entries in a single gzipped JSON file.

dictionary.yml – data dictionary for the entries.

schema.ddl – data schema for Apache Spark analytics engine.

schema.jsch – JSON schema for the entries.

Finally, the exercise network topology is described in a machine-readable NetJSON format and it is a part of a set of auxiliary files archive – auxiliary-material.tgz – which includes the following.

global-gateway-config.json – the network configuration of the global gateway in the NetJSON format.

global-gateway-routing.json – the routing configuration of the global gateway in the NetJSON format.

redteam-attack-schedule.{csv,odt} – the schedule of the Red Team attacks in CSV and ODT format. Source for Table 2.

redteam-reserved-ip-ranges.{csv,odt} – the list of IP segments reserved for the Red Team in CSV and ODT format. Source for Table 1.

topology.{json,pdf,png} – the topology of the complete Cyber Czech exercise network in the NetJSON, PDF and PNG format.

topology-small.{pdf,png} – simplified topology in the PDF and PNG format. Source for Figure 1.

Provide traffic accident data in json format (Type A1) resulting in fatalities on the spot or within 24 hours.

Traffic and road condition information captured in the QLDTraffic system is available for use by external developers via GeoJSON feeds.

These feeds cover Hazards, Crashes, Congestion, Flooding, Roadworks and Special Events and Web Cameras details.

The information provided in these feeds is on an 'as is' basis. Additional details about the available information on the QLDTraffic site can be viewed on our disclaimer page .

Transport and Main Roads (TMR) is constantly striving to ensure that they provide accurate, reliable and timely traffic and road condition information.

Given this, the previously available API has undergone changes in August 2016 with the creation of the QLDTraffic public website.

Details on accessing QLDTraffic’s traffic and road condition information via GeoJSON can be found in the QLDTraffic website application programming interface (API) specification.

This API has been developed to allow improved integration of QLDTraffic traffic and road condition information with external systems.

Please be aware that this specification may be subject to change.

Overview

3DHD CityScenes is the most comprehensive, large-scale high-definition (HD) map dataset to date, annotated in the three spatial dimensions of globally referenced, high-density LiDAR point clouds collected in urban domains. Our HD map covers 127 km of road sections of the inner city of Hamburg, Germany including 467 km of individual lanes. In total, our map comprises 266,762 individual items.

Our corresponding paper (published at ITSC 2022) is available here. Further, we have applied 3DHD CityScenes to map deviation detection here.

Moreover, we release code to facilitate the application of our dataset and the reproducibility of our research. Specifically, our 3DHD_DevKit comprises:

Python tools to read, generate, and visualize the dataset,

3DHDNet deep learning pipeline (training, inference, evaluation) for map deviation detection and 3D object detection.

The DevKit is available here:

https://github.com/volkswagen/3DHD_devkit.

The dataset and DevKit have been created by Christopher Plachetka as project lead during his PhD period at Volkswagen Group, Germany.

When using our dataset, you are welcome to cite:

@INPROCEEDINGS{9921866, author={Plachetka, Christopher and Sertolli, Benjamin and Fricke, Jenny and Klingner, Marvin and Fingscheidt, Tim}, booktitle={2022 IEEE 25th International Conference on Intelligent Transportation Systems (ITSC)}, title={3DHD CityScenes: High-Definition Maps in High-Density Point Clouds}, year={2022}, pages={627-634}}

Acknowledgements

We thank the following interns for their exceptional contributions to our work.

Benjamin Sertolli: Major contributions to our DevKit during his master thesis

Niels Maier: Measurement campaign for data collection and data preparation

The European large-scale project Hi-Drive (www.Hi-Drive.eu) supports the publication of 3DHD CityScenes and encourages the general publication of information and databases facilitating the development of automated driving technologies.

The Dataset

After downloading, the 3DHD_CityScenes folder provides five subdirectories, which are explained briefly in the following.

1. Dataset

This directory contains the training, validation, and test set definition (train.json, val.json, test.json) used in our publications. Respective files contain samples that define a geolocation and the orientation of the ego vehicle in global coordinates on the map.

During dataset generation (done by our DevKit), samples are used to take crops from the larger point cloud. Also, map elements in reach of a sample are collected. Both modalities can then be used, e.g., as input to a neural network such as our 3DHDNet.

To read any JSON-encoded data provided by 3DHD CityScenes in Python, you can use the following code snipped as an example.

import json

json_path = r"E:\3DHD_CityScenes\Dataset\train.json" with open(json_path) as jf: data = json.load(jf) print(data)

1. HD_Map

Map items are stored as lists of items in JSON format. In particular, we provide:

traffic signs,

traffic lights,

pole-like objects,

construction site locations,

construction site obstacles (point-like such as cones, and line-like such as fences),

line-shaped markings (solid, dashed, etc.),

polygon-shaped markings (arrows, stop lines, symbols, etc.),

lanes (ordinary and temporary),

relations between elements (only for construction sites, e.g., sign to lane association).

1. HD_Map_MetaData

Our high-density point cloud used as basis for annotating the HD map is split in 648 tiles. This directory contains the geolocation for each tile as polygon on the map. You can view the respective tile definition using QGIS. Alternatively, we also provide respective polygons as lists of UTM coordinates in JSON.

Files with the ending .dbf, .prj, .qpj, .shp, and .shx belong to the tile definition as “shape file” (commonly used in geodesy) that can be viewed using QGIS. The JSON file contains the same information provided in a different format used in our Python API.

1. HD_PointCloud_Tiles

The high-density point cloud tiles are provided in global UTM32N coordinates and are encoded in a proprietary binary format. The first 4 bytes (integer) encode the number of points contained in that file. Subsequently, all point cloud values are provided as arrays. First all x-values, then all y-values, and so on. Specifically, the arrays are encoded as follows.

x-coordinates: 4 byte integer

y-coordinates: 4 byte integer

z-coordinates: 4 byte integer

intensity of reflected beams: 2 byte unsigned integer

ground classification flag: 1 byte unsigned integer

After reading, respective values have to be unnormalized. As an example, you can use the following code snipped to read the point cloud data. For visualization, you can use the pptk package, for instance.

import numpy as np import pptk

file_path = r"E:\3DHD_CityScenes\HD_PointCloud_Tiles\HH_001.bin" pc_dict = {} key_list = ['x', 'y', 'z', 'intensity', 'is_ground'] type_list = ['

The HERE Traffic API v7 is a REST API that provides real-time traffic flow and incident information. This document introduces the Traffic API v7 and explains key concepts, while providing examples and information on resources, query parameters, response structures, and data types. The HERE Traffic API v7 supports the following use cases: -Provides access to real-time traffic flow data in JSON, including information on speed and jam factor for the region(s) defined in each request. The Traffic API v7 can also deliver additional data such as the geometry of the road segments in relation to the flow.- Provides aggregated information about traffic incidents in JSON, including the type and location of each traffic incident, status, start and end time, and other relevant data. This data is useful to dynamically optimize route calculations. For the terms and conditions covering this documentation, see the HERE Documentation License. For information on how to quickly get started using the Traffic API v7, see Get started.

XLS camaras-trafico.xls 다운로드 Traffic Cameras (XLS) KML camaras-trafico.kml 다운로드 Traffic Cameras (KML) JSON camaras-trafico.json 다운로드 Traffic Cameras (JSON) JSON camaras-trafico.geojson

Swedish Traffic Signs Information with English Translations

  Dataset Description

This dataset provides structured information about Swedish traffic signs in JSON Lines (.jsonl) format, ideal for traffic sign recognition, multimodal language model training, computer vision tasks, or educational purposes. Each entry includes a sign’s code, category, title, and description in Swedish (_sv) and English (_en). Swedish information is fetched from the Swedish Transport Agency… See the full description on the dataset page: https://huggingface.co/datasets/rzgar/swedish-traffic-signs-en.

Please refer to the original data article for further data description: Jan Luxemburk et al. CESNET-QUIC22: A large one-month QUIC network traffic dataset from backbone lines, Data in Brief, 2023, 108888, ISSN 2352-3409, https://doi.org/10.1016/j.dib.2023.108888. We recommend using the CESNET DataZoo python library, which facilitates the work with large network traffic datasets. More information about the DataZoo project can be found in the GitHub repository https://github.com/CESNET/cesnet-datazoo. The QUIC (Quick UDP Internet Connection) protocol has the potential to replace TLS over TCP, which is the standard choice for reliable and secure Internet communication. Due to its design that makes the inspection of QUIC handshakes challenging and its usage in HTTP/3, there is an increasing demand for research in QUIC traffic analysis. This dataset contains one month of QUIC traffic collected in an ISP backbone network, which connects 500 large institutions and serves around half a million people. The data are delivered as enriched flows that can be useful for various network monitoring tasks. The provided server names and packet-level information allow research in the encrypted traffic classification area. Moreover, included QUIC versions and user agents (smartphone, web browser, and operating system identifiers) provide information for large-scale QUIC deployment studies. Data capture The data was captured in the flow monitoring infrastructure of the CESNET2 network. The capturing was done for four weeks between 31.10.2022 and 27.11.2022. The following list provides per-week flow count, capture period, and uncompressed size:

W-2022-44

Uncompressed Size: 19 GB Capture Period: 31.10.2022 - 6.11.2022 Number of flows: 32.6M W-2022-45

Uncompressed Size: 25 GB Capture Period: 7.11.2022 - 13.11.2022 Number of flows: 42.6M W-2022-46

Uncompressed Size: 20 GB Capture Period: 14.11.2022 - 20.11.2022 Number of flows: 33.7M W-2022-47

Uncompressed Size: 25 GB Capture Period: 21.11.2022 - 27.11.2022 Number of flows: 44.1M CESNET-QUIC22

Uncompressed Size: 89 GB Capture Period: 31.10.2022 - 27.11.2022 Number of flows: 153M

Data description The dataset consists of network flows describing encrypted QUIC communications. Flows were created using ipfixprobe flow exporter and are extended with packet metadata sequences, packet histograms, and with fields extracted from the QUIC Initial Packet, which is the first packet of the QUIC connection handshake. The extracted handshake fields are the Server Name Indication (SNI) domain, the used version of the QUIC protocol, and the user agent string that is available in a subset of QUIC communications. Packet Sequences Flows in the dataset are extended with sequences of packet sizes, directions, and inter-packet times. For the packet sizes, we consider payload size after transport headers (UDP headers for the QUIC case). Packet directions are encoded as ±1, +1 meaning a packet sent from client to server, and -1 a packet from server to client. Inter-packet times depend on the location of communicating hosts, their distance, and on the network conditions on the path. However, it is still possible to extract relevant information that correlates with user interactions and, for example, with the time required for an API/server/database to process the received data and generate the response to be sent in the next packet. Packet metadata sequences have a length of 30, which is the default setting of the used flow exporter. We also derive three fields from each packet sequence: its length, time duration, and the number of roundtrips. The roundtrips are counted as the number of changes in the communication direction (from packet directions data); in other words, each client request and server response pair counts as one roundtrip. Flow statistics Flows also include standard flow statistics, which represent aggregated information about the entire bidirectional flow. The fields are: the number of transmitted bytes and packets in both directions, the duration of flow, and packet histograms. Packet histograms include binned counts of packet sizes and inter-packet times of the entire flow in both directions (more information in the PHISTS plugin documentation There are eight bins with a logarithmic scale; the intervals are 0-15, 16-31, 32-63, 64-127, 128-255, 256-511, 512-1024, >1024 [ms or B]. The units are milliseconds for inter-packet times and bytes for packet sizes. Moreover, each flow has its end reason - either it was idle, reached the active timeout, or ended due to other reasons. This corresponds with the official IANA IPFIX-specified values. The FLOW_ENDREASON_OTHER field represents the forced end and lack of resources reasons. The end of flow detected reason is not considered because it is not relevant for UDP connections. Dataset structure The dataset flows are delivered in compressed CSV files. CSV files contain one flow per row; data columns are summarized in the provided list below. For each flow data file, there is a JSON file with the number of saved and seen (before sampling) flows per service and total counts of all received (observed on the CESNET2 network), service (belonging to one of the dataset's services), and saved (provided in the dataset) flows. There is also the stats-week.json file aggregating flow counts of a whole week and the stats-dataset.json file aggregating flow counts for the entire dataset. Flow counts before sampling can be used to compute sampling ratios of individual services and to resample the dataset back to the original service distribution. Moreover, various dataset statistics, such as feature distributions and value counts of QUIC versions and user agents, are provided in the dataset-statistics folder. The mapping between services and service providers is provided in the servicemap.csv file, which also includes SNI domains used for ground truth labeling. The following list describes flow data fields in CSV files:

ID: Unique identifier SRC_IP: Source IP address DST_IP: Destination IP address DST_ASN: Destination Autonomous System number SRC_PORT: Source port DST_PORT: Destination port PROTOCOL: Transport protocol QUIC_VERSION QUIC: protocol version QUIC_SNI: Server Name Indication domain QUIC_USER_AGENT: User agent string, if available in the QUIC Initial Packet TIME_FIRST: Timestamp of the first packet in format YYYY-MM-DDTHH-MM-SS.ffffff TIME_LAST: Timestamp of the last packet in format YYYY-MM-DDTHH-MM-SS.ffffff DURATION: Duration of the flow in seconds BYTES: Number of transmitted bytes from client to server BYTES_REV: Number of transmitted bytes from server to client PACKETS: Number of packets transmitted from client to server PACKETS_REV: Number of packets transmitted from server to client PPI: Packet metadata sequence in the format: [[inter-packet times], [packet directions], [packet sizes]] PPI_LEN: Number of packets in the PPI sequence PPI_DURATION: Duration of the PPI sequence in seconds PPI_ROUNDTRIPS: Number of roundtrips in the PPI sequence PHIST_SRC_SIZES: Histogram of packet sizes from client to server PHIST_DST_SIZES: Histogram of packet sizes from server to client PHIST_SRC_IPT: Histogram of inter-packet times from client to server PHIST_DST_IPT: Histogram of inter-packet times from server to client APP: Web service label CATEGORY: Service category FLOW_ENDREASON_IDLE: Flow was terminated because it was idle FLOW_ENDREASON_ACTIVE: Flow was terminated because it reached the active timeout FLOW_ENDREASON_OTHER: Flow was terminated for other reasons

Link to other CESNET datasets

https://www.liberouter.org/technology-v2/tools-services-datasets/datasets/ https://github.com/CESNET/cesnet-datazoo Please cite the original data article:

@article{CESNETQUIC22, author = {Jan Luxemburk and Karel Hynek and Tomáš Čejka and Andrej Lukačovič and Pavel Šiška}, title = {CESNET-QUIC22: a large one-month QUIC network traffic dataset from backbone lines}, journal = {Data in Brief}, pages = {108888}, year = {2023}, issn = {2352-3409}, doi = {https://doi.org/10.1016/j.dib.2023.108888}, url = {https://www.sciencedirect.com/science/article/pii/S2352340923000069} }

The Traffic Camera dataset contains the location and number for every Traffic camera in the City of Toronto. These datasets will be updated within 2 minutes when cameras are added, changed, or removed. The camera list files can be found at: https://opendata.toronto.ca/transportation/tmc/rescucameraimages/Data/ tmcearthcameras.csv - CSV, camera list in CSV tmcearthcameras.json - json formatted list. tmcearthcamerassn.json - json formatted file containing the timestamp of the list files. tmcearthcameras.xml - xml formatted list. TMCEarthCameras.xsd - xml schema document. The dataset includes the number, name, WGS84 information (latitude, longitude), comparison directions (1- Looking North, 2-Looking East, 3-Looking South and 4-Looking West), and camera group. The camera images associated with the dataset can be found at: https://opendata.toronto.ca/transportation/tmc/rescucameraimages/CameraImages. And the comparison images can be found at: https://opendata.toronto.ca/transportation/tmc/rescucameraimages/ComparisonImages. The camera image file name is created as follows: loc####.jpg - where #### is the camera number. (i.e. loc1234.jpg) The camera comparison image file names are created as follows: loc####D.jpg - where #### is the camera number and D is the direction. (i.e. loc1234e.jpg and loc1234w.jpg) The camera images are displayed on the City's website at http://www.toronto.ca/rescu/index.htmor http://www.toronto.ca/rescu/list.htm

Monthly extracts of historic Traffic Data at Signalised derived by SCATS.

SCATS (Sydney Coordinated Adaptive Traffic System) is an intelligent transportation system that manages the dynamic timing of signal phases at traffic signals in real time. The system estimates the number of vehicles passing through the intersection and other information related to traffic signal timing. There is no guarantee this data is accurate or was used to make internal decisions in SCATS.

The data is provided by controller site. Each site has its own parquet file for the month, which contains SCATS data produced by that site. The files use the LM site number format (e.g. – Site 1 is LM00001).

Note that you are accessing the data provided by the links below pursuant to a Creative Commons (Attribution) Licence which has a disclaimer of warranties and limitation of liability. You accept that the data provided pursuant to the Licence is subject to changes and may have errors.

Pursuant to section 3 of the Licence you are provided with the following notice to be included when you Share the Licenced Material:- “The Commissioner of Main Roads is the creator and owner of the data and Licenced Material, which is accessed pursuant to a Creative Commons (Attribution) Licence, which has a disclaimer of warranties and limitation of liability.”

A data dictionary is provided at the document link.

Monthly data extracts are in parquet format.

The locations of the traffic signals are found at the link below.

https://portal-mainroads.opendata.arcgis.com/datasets/traffic-signal-sitesAvailable in JSON format below.gisservices.mainroads.wa.gov.au/arcgis/rest/services/Connect/MapServer/0/query?where=1%3D1&outFields=*&returnGeometry=true&f=pjson

The mapping of the detectors to the strategic approaches at an intersection is given at the link below.

https://mainroadsopendata.mainroads.wa.gov.au/swagger/ui/index#/LmSaDetector

Further information, including SCATS graphics, is available via the Traffic Signal information on Main Roads TrafficMap

trafficmap - Main Roads WA

Points at intersections with traffic signal data.

This layer is a component of traffic signals.

We recommend using the CESNET DataZoo python library, which facilitates the work with large network traffic datasets. More information about the DataZoo project can be found in the GitHub repository https://github.com/CESNET/cesnet-datazoo.

The modern approach for network traffic classification (TC), which is an important part of operating and securing networks, is to use machine learning (ML) models that are able to learn intricate relationships between traffic characteristics and communicating applications. A crucial prerequisite is having representative datasets. However, datasets collected from real production networks are not being published in sufficient numbers. Thus, this paper presents a novel dataset, CESNET-TLS-Year22, that captures the evolution of TLS traffic in an ISP network over a year. The dataset contains 180 web service labels and standard TC features, such as packet sequences. The unique year-long time span enables comprehensive evaluation of TC models and assessment of their robustness in the face of the ever-changing environment of production networks.

Data description The dataset consists of network flows describing encrypted TLS communications. Flows are extended with packet sequences, histograms, and fields extracted from the TLS ClientHello message, which is transmitted in the first packet of the TLS connection handshake. The most important extracted handshake field is the SNI domain, which is used for ground-truth labeling.

Packet Sequences Sequences of packet sizes, directions, and inter-packet times are standard data input for traffic analysis. For packet sizes, we consider the payload size after transport headers (TCP headers for the TLS case). We omit packets with no TCP payload, for example ACKs, because zero-payload packets are related to the transport layer internals rather than services’ behavior. Packet directions are encoded as ±1, where +1 means a packet sent from client to server, and -1 is a packet from server to client. Inter-packet times depend on the location of communicating hosts, their distance, and on the network conditions on the path. However, it is still possible to extract relevant information that correlates with user interactions and, for example, with the time required for an API/server/database to process the received data and generate a response. Packet sequences have a maximum length of 30, which is the default setting of the used flow exporter. We also derive three fields from each packet sequence: its length, time duration, and the number of roundtrips. The roundtrips are counted as the number of changes in the communication direction; in other words, each client request and server response pair counts as one roundtrip.

Flow statistics Each data record also includes standard flow statistics, representing aggregated information about the entire bidirectional connection. The fields are the number of transmitted bytes and packets in both directions, the duration of the flow, and packet histograms. The packet histograms include binned counts (not limited to the first 30 packets) of packet sizes and inter-packet times in both directions. There are eight bins with a logarithmic scale; the intervals are 0-15, 16-31, 32-63, 64-127, 128-255, 256-511, 512-1024, >1024 [ms or B]. The units are milliseconds for inter-packet times and bytes for packet sizes (More information in the PHISTS plugin documentation). Moreover, each flow has its end reason---either it ended with the TCP connection termination (FIN packets), was idle, reached the active timeout, or ended due to other reasons. This corresponds with the official IANA IPFIX-specified values. The FLOW_ENDREASON_OTHER field represents the forced end and lack of resources reasons.

Dataset structure The dataset is organized per weeks and individual days. The flows are delivered in compressed CSV files. CSV files contain one flow per row; data columns are summarized in the provided list below. For each flow data file, there is a JSON file with the total number of saved flows and the number of flows per service. There are also files aggregating flow counts for each week (stats-week.json) and for the entire dataset (stats-dataset.json). The following list describes flow data fields in CSV files:

ID: Unique identifier

SRC_IP: Source IP address

DST_IP: Destination IP address

DST_ASN: Destination Autonomous System number

SRC_PORT: Source port

DST_PORT: Destination port

PROTOCOL: Transport protocol

FLAG_CWR: Presence of the CWR flag

FLAG_CWR_REV: Presence of the CWR flag in the reverse direction

FLAG_ECE: Presence of the ECE flag

FLAG_ECE_REV: Presence of the ECE flag in the reverse direction

FLAG_URG: Presence of the URG flag

FLAG_URG_REV: Presence of the URG flag in the reverse direction

FLAG_ACK: Presence of the ACK flag

FLAG_ACK_REV: Presence of the ACK flag in the reverse direction

FLAG_PSH: Presence of the PSH flag

FLAG_PSH_REV: Presence of the PSH flag in the reverse direction

FLAG_RST: Presence of the RST flag

FLAG_RST_REV: Presence of the RST flag in the reverse direction

FLAG_SYN: Presence of the SYN flag

FLAG_SYN_REV: Presence of the SYN flag in the reverse direction

FLAG_FIN: Presence of the FIN flag

FLAG_FIN_REV: Presence of the FIN flag in the reverse direction

TLS_SNI: Server Name Indication domain

TLS_JA3: JA3 fingerprint of TLS client

TIME_FIRST: Timestamp of the first packet in format YYYY-MM-DDTHH-MM-SS.ffffff

TIME_LAST: Timestamp of the last packet in format YYYY-MM-DDTHH-MM-SS.ffffff

DURATION: Duration of the flow in seconds

BYTES: Number of transmitted bytes from client to server

BYTES_REV: Number of transmitted bytes from server to client

PACKETS: Number of packets transmitted from client to server

PACKETS_REV: Number of packets transmitted from server to client

PPI: Packet sequence in the format: [[inter-packet times], [packet directions], [packet sizes], [push flags]]

PPI_LEN: Number of packets in the PPI sequence

PPI_DURATION: Duration of the PPI sequence in seconds

PPI_ROUNDTRIPS: Number of roundtrips in the PPI sequence

PHIST_SRC_SIZES: Histogram of packet sizes from client to server

PHIST_DST_SIZES: Histogram of packet sizes from server to client

PHIST_SRC_IPT: Histogram of inter-packet times from client to server

PHIST_DST_IPT: Histogram of inter-packet times from server to client

APP: Web service label

CATEGORY: Service category

FLOW_ENDREASON_IDLE: Flow was terminated because it was idle

FLOW_ENDREASON_ACTIVE: Flow was terminated because it reached the active timeout

FLOW_ENDREASON_END: Flow ended with the TCP connection termination

FLOW_ENDREASON_OTHER: Flow was terminated for other reasons

The data is therefore updated daily for the following periods: The day before: 15-minute intervals Six days ago: 15-minute intervals and daily intervals 28 days ago: 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. If such data is required, e.g. the data set "traffic strengths Hamburg" can be used. are used, which contains the "average (working) daily traffic" in the development of recent years. As with any traffic count, whether automated or manual, there are certain tolerances in measurement accuracy. The system used here requires accuracies of +/- 5% for the recording of vehicle traffic strengths. Further information about the real-time service: The real-time data service contains the locations of the counting points for vehicle traffic, which is recorded with infrared detectors. The data is provided in JSON format via the SensorThings API (STA). For each counting point in the SensorThings API (STA), an object was created in the entity "Thing" created. For each temporal resolution level at the counting points or each traffic reference, there is an object in the entity "Datastreams". The real-time data on the number of vehicles per counting point and time interval is stored in the STA in the entity Observations. published. The following spatial and temporal levels are differentiated: -Counting point 15-min, 1-hour, 1-day, 1-week: Number of cars All times are given in Coordinated Universal Time (UTC). In the entity Datastreams there are in the JSON object under the "key" "properties" Other key-value pairs. Based on the service and layer structure in the GIS, we have service and layer as additional "key-value pairs" Introduced under the JSON property object. Here is an example: { "properties":{ "serviceName": "HHSTAAutomated Traffic Quantity Capture", "layerName": "NumberKfzCounter_15-Min", "key":"value"} } Available layers in layerName are: * NumberCarDescription15-min * NumberCarDescription1 hour * NumberCarDescription1 tag * NumberCarDescription1-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.1/Datastreams?$filter=properties/serviceName eq 'HHSTAAutomated Traffic Quantity Capture' and properties/layerName eq 'NumberKfzCounter_15-Min'

Current status of the Live Traffic NSW website in JSON format

General information: The data set includes traffic data from all locations in Hamburg where motor vehicle traffic (vehicle traffic) is recorded using infrared detectors 24 hours a day and every day of the year. The data contain real-time traffic volumes and are made available at counting points summarized for the road cross-section at 15-minute, 60-minute, daily and weekly intervals. The data from the counting points is also visualized in the corresponding geoportals of the FHH, e.g. Geo-Online and Verkehrsportal. In addition to real-time data, historical data is also available to the following extent: all data for the last two weeks in 15-minute intervals, all data for the last two months for 60-minute intervals, all data for the current and last year in daily intervals , all data since the start of collection in weekly intervals. Information on the technology: The infrared detectors are usually installed on traffic lights, but to a lesser extent also on other masts. The detectors record and count the traffic via the heat radiation of the individual road users. 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 FHH Urban Data Platform. In this way, they are available promptly to all users and interested parties. Due to the real-time component, however, various framework conditions must be observed: The data is not comprehensively quality-assured. Unusual deviations from the expected data and data gaps are automatically recognized by the system, but cannot be corrected in real time. Gaps that occur, e.g. due to a break in data transmission, can be supplied later. Under certain circumstances and in the case of longer failures, changes in the historical data can still occur after a few days. The data is therefore updated daily for the following periods: The day before: 15-minute intervals The day before six days: 15-minute intervals and daily intervals The day before 28 days: daily intervals The weekly values ​​are updated weekly for the values the previous week and the week four weeks ago. The data published here is not officially verified data from the FHH. If such data is required, the "Hamburg traffic volumes" dataset, for example, can be used, which contains the "average (work)day traffic" over the past few years. As with any traffic count, whether automated or manual, there are certain tolerances in the measurement accuracy. The requirements for the system used here are accuracies of +/- 5% when recording vehicle traffic volumes. More information about the real-time service: The real-time data service contains the locations of the counters for the number of vehicles recorded with infrared detectors. The data is provided in JSON format via the SensorThings API (STA). An object was created in the "Thing" entity for each counting point in the SensorThings API (STA). There is an object in the "Datastreams" entity for each temporal resolution level at the counting points or each traffic reference value. The real-time data on the number of vehicles per counting point and time interval is published in the STA in the "Observations" entity. The following spatial and temporal levels are differentiated: -Counting point 15 minutes, 1 hour, 1 day, 1 week: Number of vehicles 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_AutomatisiertTrafficQuantity", "layerName": "Number_Kfz_Zaehlstelle_15-Min", "key":"value"} } Available layers in the layerName are: * number_Kfz_Zaehlstelle_15-Min * number_Kfz_Zaehlstelle_1- Hour * number_car_counterpoint_1-day * number_car_counterpoint_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.1/Datastreams?$filter =properties/serviceName eq 'HH_STA_automated traffic volume recording' and properties/layerName eq 'Anzahl_Kfz_Zaehlstelle_15-Min' 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.1/Datastream({id})/Observations

Information about Brisbane City Council Traffic Intersections, including location, lanes and detectors (in JSON).

This dataset is primarily supplied to be used with another dataset Traffic Management — Intersection volume.

Not all signalised traffic intersections within Brisbane are operated by Brisbane City Council.

The Data and resources section of this dataset contains further information for this dataset.

Access API

The dataset displays the location of the traffic cameras whose images appear on Live Traffic web site. The data has been extracted from a GEOJSON file from TfNSW Open Data website and processed using FME script.

------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