Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
374
datasets available to search
ShareScore release 0.9.0
Dataset results
374 results for “traffic”
Citizen science for traffic counts: WeCount project dataset for inner-city streets of Ljubljana
<p>The Horizon 2020 project WeCount is a citizen science project that involves citizens in all steps from problem definition to data collection and analysis. This is currently one of the most common methods of citizen participation. The ethical criteria that such a project must meet in order to be classified as citizen science, and the form of transparency or informed consent that should be a necessary part of the ethical conduct of citizen science projects, were on Telraam platform for examination at the international and national level during the collection of data on traffic flows for WeCount Ljubljana. Engaged citizens were given low-cost sensors which they placed on the inside of the windowpane in their home or office facing the street at different distances (from 3 to 15 meters). </p>
Intersection Vehicular Traffic Flow Scheduling Datasets
<p><strong>Background</strong></p> <p>Vehicular traffic congestion remains a major problem in most modern cities of the world. Therefore, efforts to minimize these congestions and their accompanying effects continuously receive much attention from researchers, traffic engineers, policymakers, etc.</p> <p>One important element required in the efforts of traffic engineering for the minimization of traffic congestion is data. Data influence the modeling and deployment of traffic scheduling systems. Most importantly, the objectives of modeling and deploying the traffic scheduling system influence the nature of the data to be used.</p> <p><strong>Aim</strong></p> <p>The aim of this study was to generate and provide a dataset that may be used in the training of computationally intelligent systems having basic objects of minimizing waiting time, travel time, etc. at various intersections (isolated intersections or roundabouts).</p> <p><strong>Methodology</strong></p> <p>The dataset (<strong><em>.csv</em></strong>) consisted of waiting time (W), queue length (Q), and phase duration (P). The waiting time is the time duration vehicles have waited at an intersection/roundabout before being scheduled to utilize the intersection/roundabout. The queue length refers to the number of vehicles (vehicular count) waiting at an intersection/roundabout. Phase duration is the time period a given vehicular flow (lane) is assigned the green wave to utilize the intersection/roundabout. The dataset was obtained through repeated training, testing, and modification of phase duration and the Adaptive Neuro-Fuzzy Inference System (ANFIS) model.</p> <p>The dataset considered bounded conditions on the three parameters (W, Q, P). The W and Q were bounded between zero and ninety – [0, 90] and the P is [13, 50]. That is, when W and Q are greater than or equal to the upper bound, the upper bound is used. Every flow may be assigned a minimum P of 13s and a maximum of 50s. The P-bounds assumed that the lower bound is large enough for vehicles on the assigned traffic flow to move to the safe region of the intersection before the scheduling system switches assignment to another traffic flow. </p> <p><strong>Conclusion</strong></p> <p>The dataset may be used as a benchmark dataset for the improvement of traffic flow controllers as well as other datasets.</p>
A consolidated database of police-reported motor vehicle traffic accidents in the United States for actuarial applications
<p>The parameter estimates along with their 90% confidence intervals obtained for the 20 multinomial logistic regressions are shown here in two presentations. In 'Covariate trends' we show the annual trends for the 20 years of data by type of covariate. In 'Covariates magnitude for each year', we show for each year the magnitude that each covariate has in contrast with the other 23 covariates (the intercept is not included due to scaling issues).</p> <p>All parameter estimates and their confidence intervals can be found in a table format in 'allparameters.csv'.</p>
Measurement Data: Latencies and Traffic Traces in Global Mobile Roaming with Regional Breakouts
<h1>A Shortcut through the IPX: Measuring Latencies in Global Mobile Roaming with Regional Breakouts</h1> <p>This repository contains a description and sample data for the Paper<em> A Shortcut through the IPX: Measuring Latencies in Global Mobile Roaming with Regional Breakouts</em> published at the Network Traffic Measurement and Analysis (TMA) Conference 2024.<br>In the provided README.md file, we present example snippets of the datasets, including an explanation of all contained fields.</p> <p>We cover the three main datasets covered in the related paper:<br>- DT1: User plane traces captured at multiple GGSN/PGW instances of a globaly operating MVNO<br>- DT2: GTP echo round trip times between visited network SGSN/SGWs and home network GGSN/PGWs<br>- DT3: IPX routing information, as extracted from BGP routing tables</p> <p>For legal reasons, we are not able to publish the secondary datasets (DT4, DT5) covered in the manuscript.</p> <p>Finally, for privacy, security, and political reasons, certain fields in each of the datasets have been anonymized. These are indicated by the `_anonymized` prefix.<br>In case of IP addresses, the anonymization ist consistent across datasets, meaning that similar IPs have been anonymized such that their values are still identical after anonymization.</p> <h3>Contact</h3> <p>For questions regarding the dataset, contact Viktoria Vomhoff (viktoria.vomhoff@uni-wuerzburg.de)</p> <p> </p>
Impacts of centralized control on mixed traffic network performance: A strategic games analysis
<p>This dataset contains the data that were used to assess the proposed framework within the context of the case study in the paper entitled "Impacts of centralized control on mdaixed traffic network per-formance: A strategic games analysis".</p>
Dataset for "On a Collision Course: Unveiling Wireless Attacks to the Aircraft Traffic Collision Avoidance System (TCAS)"
<p>The dataset associated with "On a Collision Course: Unveiling Wireless Attacks to the Aircraft Traffic Collision Avoidance System (TCAS)"</p>
ISP topology and traffic dataset
<div>This dataset contains the topology and some interface-level traffic information for two European National Research and Education Networks:</div> <div> <ul> <li>Switch LAN (CH)</li> <li>SURF (NL)</li> </ul> <p>The data has been provided by the operators of these networks and published with their consent. Please refer to the README for more details.</p> <p>We would love to see this dataset extended by and for the community. If you have similar data to contribute, please do not hesitate to <a href="mailto:jacobr@ethz.ch" target="_blank" rel="noopener">reach out to Romain</a>.</p> </div>
Urban Traffic Speed Dataset of Guangzhou, China
<p>This is an urban traffic speed dataset which consists of 214 anonymous road segments (mainly consist of urban expressways and arterials) within two months (i.e., 61 days from August 1, 2016 to September 30, 2016) at 10-minute interval, and the speed observations were collected in Guangzhou, China. In practice, it can be used to conduct missing data imputation, short-term traffic prediction, and traffic pattern discovery experiments.</p> <p>According to the spatial and temporal attributes, we can easily derive a third-order tensor as <span class="math-tex">\(\mathcal{X}\in\mathbb{R}^{214\times 61\times 144}\)</span> and its dimensions include road segment, day and time window (see the file <strong>tensor.mat</strong>). The total number of speed observations (or non-zero entries of the tensor <span class="math-tex">\(\mathcal{X}\)</span>) is <span class="math-tex">\(1,855,589\)</span>. If the dataset is complete, then we have <span class="math-tex">\(214\times 61\times 144=1,879,776\)</span> observations, therefore, the original missing rate of this dataset is <span class="math-tex">\(1.29\%\)</span>.</p> <p>Note that the file <strong>traffic_speed_data.csv</strong> is the original traffic speed data with four columns including road segment attribute, day attribute, time window attribute, and traffic speed value. The file <strong>day_information_table.csv</strong> is a table referring to the specific date, and the file <strong>time_information_table.csv</strong> is a table expressing time window with start time and end time information.</p> <p>Feel free to email me with any questions: <a href="#">chenxy346@mail2.sysu.edu.cn</a> (author: Xinyu Chen).</p> <p><strong>Acknowledgement</strong>: Mr. Weiwei Sun (affiliated with Sun Yat-Sen University) also provided insightful suggestion and help for publishing this data set. Thank you!</p>
Traffic forecasting with Virtual Induction Loops - SUMO simulation dataset
<p>This repository is associated with my doctoral dissertation titled, "<strong>Smartphone based applications for Road Traffic Telematics</strong>". In particular this repository serves as the basis of Chapter 7 titled, "<strong>Traffic forecasting with Virtual Induction Loops (VIL)</strong>". The basic idea is to validate a traffic forecasting system which uses machine learning techniques on the simulation of real traffic flows on a real intersection in the City of Turin. This dataset contains simulation output from SUMO software for 56 real days between the months of October-2017 to April-2018. Details about these days are available in my thesis. For each day, 3 output files are available. Here is the description and naming convention:</p> <ol> <li>M1_100seed_100pr_dump.csv (This is the data dump file from SUMO. It contains flows of every single vehicle that was simulated. Naming convention is day_seed_vilPenetrationRate_dump.csv)</li> <li>M1_100seed_ilNorth_100pr.xml (This is the output from a simulated induction loop for Northbound traffic. Naming convention is day_seed_ilNorth_vilPenetrationRate.xml)</li> <li>M1_100seed_ilSouth_100pr.xml (This is the output from a simulated induction loop for Southbound traffic. Naming convention is day_seed_ilSouth_vilPenetrationRate.xml)</li> </ol> <p>For further details, please refer to my thesis.</p>
Freeway Inductive Loop Detector Dataset for Network-wide Traffic Speed Prediction
<p>The data is collected by the inductive loop detectors deployed on freeways in Seattle area. The freeways contain I-5, I-405, I-90, and SR-520. This data set contains spatiotemporal speed information of the freeway system. At each milepost, the speed information collected from main lane loop detectors in the same direction are averaged and integrated into 5 minutes interval speed data. The raw data is provided by Washington Start Department of Transportation (WSDOT) and processed by the <a href="http://www.uwstarlab.org/">STAR Lab</a> in the University of Washington according to data quality control and data imputation procedures [1][2]. </p> <p>The data file is a pickle file that can be easily read using the read_pickle() function in the Pandas package. The data forms as a matrix and each cell of the matrix is speed value for the specific milepost and time period. The horizontal header of the data set denotes the milepost and the vertical header indicates the timestamps. For more information on the definition of milepost, please refer to this <a href="http://data.wsdot.wa.gov/traffic/">website</a>.</p> <p>This data set been used for traffic prediction tasks in several research studies [3][4]. For more detailed information about the data set, you can also refer to this <a href="https://github.com/zhiyongc/Seattle-Loop-Data">link</a>.</p> <p><strong>References</strong>:</p> <p>[1]. Henrickson, K., Zou, Y., & Wang, Y. (2015). Flexible and robust method for missing loop detector data imputation. <em>Transportation Research Record</em>, <em>2527</em>(1), 29-36.</p> <p>[2]. Wang, Y., Zhang, W., Henrickson, K., Ke, R., & Cui, Z. (2016). <em>Digital roadway interactive visualization and evaluation network applications to WSDOT operational data usage</em> (No. WA-RD 854.1). Washington (State). Dept. of Transportation.</p> <p>[3]. Cui, Z., Ke, R., & Wang, Y. (2018). Deep bidirectional and unidirectional LSTM recurrent neural network for network-wide traffic speed prediction. <em>arXiv preprint arXiv:1801.02143</em>.</p> <p>[4]. Cui, Z., Henrickson, K., Ke, R., & Wang, Y. (2018). Traffic Graph Convolutional Recurrent Neural Network: A Deep Learning Framework for Network-Scale Traffic Learning and Forecasting. <em>arXiv preprint arXiv:1802.07007</em>.</p>
Data: Oxfordshire traffic and models
<p>These are the datasets and code used in two papers:</p> <p><em>1 - Diagnosing the performance of human mobility models at small spatial scales using volunteered geographic information (</em>https://arxiv.org/abs/1905.07964)</p> <p><em>2 - Estimating Traffic Disruption Patterns with Volunteered Geographic Information (</em>https://arxiv.org/abs/1907.05162).</p> <p>The files contain demographic and geographic data for electoral wards in the county of Oxfordshire, UK, as well as code to run the models described in the first paper.</p> <p>Tij matrices will also be public subject to approval by the data controller.</p>
GTSRB - German Traffic Sign Recognition Benchmark by Real-Time Computer Vision at Ruhr-Universität Bochum
<div> <div>The German Traffic Sign Benchmark is a multi-class, single-image classification challenge held at the International Joint Conference on Neural Networks (IJCNN) 2011. <br>Our benchmark has the following properties: <br>- Single-image, multi-class classification problem <br>- More than 40 classes<br>- More than 50,000 images in total <br>- Large, lifelike database<br><br>Acknowledgements: [INI Benchmark Website][1]<br>[1]: http://benchmark.ini.rub.de/</div> </div>
Tweasel traffic collection for TrackHAR adapter work on websites (September 2024)
<p>To start creating TrackHAR adapters for trackers active on the web, we ran a traffic collection on the top 10,000 websites in Germany as per the Chrome User Experience Report (CrUX) for August 2024.</p> <p>The websites were accessed in a headless Chromium browser using Playwright from a French IP address between 2024-09-20 and 2024-09-26. All websites were accessed twice for 60 seconds each: The first time without any user interaction, the second time random user input was provided, meaning that it is possible/likely that consent was given when requested.</p> <p>Source code for the collection: <a href="https://github.com/tweaselORG/experiments/tree/4d00eba66a3b797805a0c5ee32bcdd1e04577217/web-monkey-september-2024">https://github.com/tweaselORG/experiments/tree/4d00eba66a3b797805a0c5ee32bcdd1e04577217/web-monkey-september-2024</a><br>Notes on the collection: <a href="https://github.com/tweaselORG/experiments/issues/3">https://github.com/tweaselORG/experiments/issues/3</a></p>
Identification of HTTP/3 traffic
<p>Datasets that have been generated based on 1.000 most popular domains, selected by Tranco with tools CICFlowmeter and Appscanner. </p>
Dataset of traffic dynamics during the 2020 Glass Wildfire Evacuation
<p>This dataset contains the </p> <p>This dataset has been sourced from the Performance Measurement System of the California Department of Transportation. The data has been processed, analysed, presented and summarized in the paper: <em>Rohaert et al., ‘T</em>he analysis of traffic data of wildfire evacuation: the case study of the 2020 Glass Fire<em>’, [Submitted for peer-review to an international journal.], 2023.</em></p> <p><strong>Acknowledgements</strong></p> <p>This work has been funded under award 60NANB21D118 from the National Institute of Standards and Technology (NIST), U.S. Department of Commerce.</p>
IDMT-Traffic Dataset
<p>The IDMT-TRAFFIC dataset includes 17,506 2-second long stereo audio excerpts of recorded vehicle passings as well as different background sounds alongside streets. The dataset includes recordings from 4 different recording locations, 4 different vehicle types (bus, car, motorcycle, and truck), three different tempo limit areas, as well as dry and wet weather/road conditions. The direction of movement is annotated as well. Recordings with both high-quality sE8 microphones as well as medium-quality MEMS microphones are included.</p>
Swiss Dwellings: A large dataset of apartment models including aggregated geolocation-based simulation results covering viewshed, natural light, traffic noise, centrality and geometric analysis
<p><strong>Introduction</strong></p> <p>This dataset contains detailed data on over 45,000 apartments (370,000 rooms) in ~3,100 buildings including their geometries, room typology as well as their visual, acoustical, topological, and daylight characteristics. Additionally, we have included location-specific characteristics for the buildings, including climatic data and points of interest within walking distance.</p> <p><strong>Changelog</strong></p> <ul> <li><strong>v3.0.0 (2023-03-31):</strong> <ul> <li>Updated the dataset increasing the total number of apartments to 45176 and incorporating fixes to some of the sites. The update includes re-digitized apartments and thus alters some ID values.</li> </ul> </li> <li><strong>v2.2.1 (2023-03-10):</strong> <ul> <li>A file, <code>location_ratings.csv</code>, has been included to provide ratings of the locations in which the buildings are situated. The ratings, provided by <a href="https://en.fpre.ch/">Fahrländer Partner AG</a>, give insights into the living situation at the buildings' addresses. Details for the different dimensions are provided below.</li> <li>The file <code>location.csv</code> has been updated to include the minimum and maximum temperatures for the locations in which the buildings are situated.</li> </ul> </li> <li><strong>v2.1.0 (2022-12-23)</strong>: <ul> <li>A file, <code>locations.csv</code>, has been included to provide information on the climatic and infrastructural characteristics of the locations in which each building is situated</li> </ul> </li> <li><strong>v2.0.0 (2022-10-17):</strong> <ul> <li>Additional to the residential units, we also include the commercial and public parts (such as staircases) of the models. The field <code>unit_usage</code> describes whether an area belongs to a commercial, residential, janitor or public part of the building</li> <li>Added the fields <code>elevation</code> and <code>height</code> to <em>geometries.csv</em> to describe the elevation above the terrain surface and the height of objects.</li> <li>Added the field <code>plan_id</code> which allows identifying which floors are based on the same floor plan (in some cases multiple floors of a building share the same floor plan</li> <li>Improved the ordering of fields in the CSV files (instead of alphabetic order)</li> <li>Minor changes to individual sites</li> </ul> </li> </ul> <p><strong>Procurement</strong></p> <p>The data is sourced from commercial clients of <a href="https://www.archilyse.com/">Archilyse AG</a> specializing on the digitization and analysis of buildings. The existing building plans of clients are converted into a geo-referenced, semantically annotated representation and undergo a manual Q/A process to ensure the accuracy of the data and to ensure a maximum 5%-deviation in the apartments' areas (validated with a median deviation of 1.2%).</p> <p><strong>Geometries</strong></p> <p>The dataset contains a file <code>geometries.csv</code> which contains the geometries of all areas, walls, railings, columns, windows, doors and features (sinks, bathtubs, etc.) of an apartment.</p> <p>In total, the datasets contain the 2D geometry of ~1.7 million separators (walls, railings), ~715,000 openings (windows, doors), ca. 520,000 areas (rooms, bathrooms, kitchens, etc.), and ~315,000 features (sinks, toilets, bathtubs, etc.).</p> <p>Each row contains:</p> <ul> <li><code>apartment_id</code>: The ID of the apartment (for features, areas), <em>note</em>: an apartment id is only unique per site</li> <li><code>site_id</code>: The ID of the site</li> <li><code>building_id</code>: The ID of the building</li> <li><code>floor_id</code>: The ID of the floor</li> <li><code>plan_id</code>: The ID of the plan on which the floor is based, multiple floors of a building might be based on the same plan</li> <li><code>unit_id</code>: The ID of the unit in which the element is spatially contained (for features, areas)</li> <li><code>area_id</code>: The ID of the area in which the element is spatially contained (for features)</li> <li><code>unit_usage</code>: The usage of the unit, possible values are: RESIDENTIAL, COMMERCIAL, PUBLIC, JANITOR</li> <li><code>entity_type</code>: The entity type (<em>area, separator, opening, feature</em>)</li> <li><code>entity_subtype</code>: The entity’s sub-type (e.g. <em>WALL</em>)</li> <li><code>geometry</code>: The element’s geometry as a <a href="https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometry">WKT</a> geometry in meters. The geometry is given in the site’s local coordinate system. I.e. the position between elements of the same site are correct in respect to each other. The +y direction points northwards, the +x direction points eastwards.</li> <li><code>elevation</code>: The object's elevation above the terrain surface in meters. We assume one terrain baseline per building, thus all walls in a given floor share the same elevation value. However, windows in particular might start at different elevations and have differing heights.</li> <li><code>height</code>: The height of the entity in meters, <em>note</em>: In many cases, a default height is assumed</li> </ul> <p>An example:</p> <table> <thead> <tr> <th scope="col">column</th> <th scope="col"> </th> </tr> </thead> <tbody> <tr> <td>apartment_id</td> <td> <p>d4438f2129b30290845ce7eef98a5ba7</p> </td> </tr> <tr> <td>site_id</td> <td>127</td> </tr> <tr> <td>building_id</td> <td>164</td> </tr> <tr> <td>plan_id</td> <td>492</td> </tr> <tr> <td>floor_id</td> <td>861</td> </tr> <tr> <td>unit_id</td> <td>63777</td> </tr> <tr> <td>area_id</td> <td>767676</td> </tr> <tr> <td>unit_usage</td> <td>RESIDENTIAL</td> </tr> <tr> <td>entity_type</td> <td>area</td> </tr> <tr> <td>entity_subtype</td> <td>LIVING_ROOM</td> </tr> <tr> <td>geometry</td> <td> <p>POLYGON ((-6.1501158933490139 -4.8490786654693...</p> </td> </tr> <tr> <td>elevation</td> <td>0</td> </tr> <tr> <td>height</td> <td>2.6</td> </tr> </tbody> </table> <p><strong>Simulations</strong></p> <p>Besides the geometrical model, we also provide simulation data on the visual, acoustic, solar, layout, and connectivity-related characteristics of the apartments. The file <code>simulations.csv</code> contains the simulation data aggregated on a per-area basis. Each row contains the identifier columns <code>area_id</code>, <code>unit_id</code>, <code>apartment_id</code>, <code>floor_id</code>, <code>building_id</code>, <code>site_id</code> as defined above as well as 367 simulation columns. Each simulation column is formatted as:</p> <pre><code><simulation_category>_<simulation_dimensions>_<aggregation_function></code></pre> <p>For instance. the column <code>view_buildings_median</code> describes the amount of building surface that can be seen from any point in a given room. The aggregation methods vary per simulation category and are described in detail below.</p> <p><strong>Layout</strong></p> <p>The <em>layout</em> features represent simple features based on the geometry and composition of a room, the dataset provides the following information in an unaggregated form.</p> <p>Area Basics / Geometry</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>layout_area_type</td> <td>The area’s area type</td> </tr> <tr> <td>layout_net_area</td> <td>The area’s share of the apartment’s net area (e.g. 0 for a balcony)</td> </tr> <tr> <td>layout_area</td> <td>The area’s actual area</td> </tr> <tr> <td>layout_perimeter</td> <td>The area’s perimeter</td> </tr> <tr> <td>layout_compactness</td> <td>The area’s compactness (the Polsby–Popper score)</td> </tr> <tr> <td>layout_room_count</td> <td>The area’s share to the apartment’s room count</td> </tr> <tr> <td>layout_is_navigable</td> <td>True if the area is navigable by a wheelchair</td> </tr> </tbody> </table> <p>Area Features</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>layout_has_sink</td> <td>True if the area has a sink</td> </tr> <tr> <td>layout_has_shower</td> <td>True if the area has a shower</td> </tr> <tr> <td>layout_has_bathtub</td> <td>True if the area has a bathtub</td> </tr> <tr> <td>layout_has_toilet</td> <td>True if the area has a toilet</td> </tr> <tr> <td>layout_has_stairs</td> <td>True if the area has stairs</td> </tr> <tr> <td>layout_has_entrance_door</td> <td>True if the area is directly leading to an exit of the apartment</td> </tr> </tbody> </table> <p>Area Windows / Doors</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>layout_number_of_doors</td> <td>The number of doors directly leading to the area</td> </tr> <tr> <td>layout_number_of_windows</td> <td>The number of windows of the area</td> </tr> <tr> <td>layout_door_perimeter</td> <td>The sum of all door lengths directly leading to the area</td> </tr> <tr> <td>layout_window_perimeter</td> <td>The sum of all window lengths of the area</td> </tr> </tbody> </table> <p>Area Walls / Railings</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>layout_open_perimeter</td> <td>The sum of all of the boundaries of the area that are neither walls nor railings</td> </tr> <tr> <td>layout_railing_perimeter</td> <td>The sum of all of the boundaries of the area that are railings</td> </tr> <tr> <td>layout_mean_walllengths</td> <td>The mean length of the area’s sides</td> </tr> <tr> <td>layout_std_walllengths</td> <td>The standard deviation of the lengths of the area’s sides</td> </tr> </tbody> </table> <p>Area Adjacency</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>layout_connects_to_bathroom</td> <td>True if the area connects to a bathroom</td> </tr> <tr> <td>layout_connects_to_private_outdoor</td> <td>True if the area connects to an outside area that is private to the apartment</td> </tr> </tbody> </table> <p><strong>View</strong></p> <p>The views from an object help to understand the impact of the surroundings on the object. The view simulation calculates the visible amount of buildings, greenery, water, etc. on each individual hexagon from the analyzed object. The values are expressed in steradians (sr) and represent the amount a particular object category occupies in the spherical field of view.</p> <p>Each of the following dimensions is provided using the room-wise aggregations' <em>min</em>, <em>max</em>, <em>mean</em>, <em>std</em>, <em>median</em>, <em>p20,</em> and <em>p80</em>. For instance, the column <code>view_greenery_p20</code> describes the amount of greenery that can be seen from at least 20% of the positions in the area.</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>view_buildings</td> <td>The amount of visible buildings</td> </tr> <tr> <td>view_greenery</td> <td>The amount of visible greenery</td> </tr> <tr> <td>view_ground</td> <td>The amount of visible ground</td> </tr> <tr> <td>view_isovist</td> <td>The amount of visible isovist</td> </tr> <tr> <td>view_mountains_class_2</td> <td>The amount of visible mountains of UN mountain class 2</td> </tr> <tr> <td>view_mountains_class_3</td> <td>The amount of visible mountains of UN mountain class 3</td> </tr> <tr> <td>view_mountains_class_4</td> <td>The amount of visible mountains of UN mountain class 4</td> </tr> <tr> <td>view_mountains_class_5</td> <td>The amount of visible mountains of UN mountain class 5</td> </tr> <tr> <td>view_mountains_class_6</td> <td>The amount of visible mountains of UN mountain class 6</td> </tr> <tr> <td>view_railway_tracks</td> <td>The amount of visible railway_tracks</td> </tr> <tr> <td>view_site</td> <td>The amount of visible site</td> </tr> <tr> <td>view_sky</td> <td>The amount of visible sky</td> </tr> <tr> <td>view_tertiary_streets</td> <td>The amount of visible tertiary_streets</td> </tr> <tr> <td>view_secondary_streets</td> <td>The amount of visible secondary_streets</td> </tr> <tr> <td>view_primary_streets</td> <td>The amount of visible primary_streets</td> </tr> <tr> <td>view_pedestrians</td> <td>The amount of visible pedestrians</td> </tr> <tr> <td>view_highways</td> <td>The amount of visible highways</td> </tr> <tr> <td>view_water</td> <td>The amount of visible water</td> </tr> </tbody> </table> <p><strong>Sun</strong></p> <p>Sun simulations help to understand the impact of solar radiation on the object. The outcome of the sun simulations helps to identify surfaces that have great solar potential. Sun simulations are defined by the amount of solar radiation on each individual hexagon from the analyzed object. The sun simulation not only includes direct sun but also considers scattered light. The sun simulation values are given in Kilolux (klx). Simulations are performed for the days of the summer solstice, winter solstice, and the vernal equinox.</p> <p>Each of the following dimensions is provided using the room-wise aggregations' <em>min</em>, <em>max</em>, <em>mean</em>, <em>std</em>, <em>median</em>, <em>p20,</em> and <em>p80</em>. For instance, column <code>sun_201806211200_median</code> describes the median amount of direct daylight received on the positions in the area.</p> <p>Vernal Equinox</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>sun_201803210800</td> <td>Daylight at 08:00 on 21st of March</td> </tr> <tr> <td>sun_201803211000</td> <td>Daylight at 10:00 on 21st of March</td> </tr> <tr> <td>sun_201803211200</td> <td>Daylight at 12:00 on 21st of March</td> </tr> <tr> <td>sun_201803211400</td> <td>Daylight at 14:00 on 21st of March</td> </tr> <tr> <td>sun_201803211600</td> <td>Daylight at 16:00 on 21st of March</td> </tr> <tr> <td>sun_201803211800</td> <td>Daylight at 18:00 on 21st of March</td> </tr> </tbody> </table> <p>Summer Solstice</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>sun_201806210600</td> <td>Daylight at 06:00 on 21st of June</td> </tr> <tr> <td>sun_201806210800</td> <td>Daylight at 08:00 on 21st of June</td> </tr> <tr> <td>sun_201806211000</td> <td>Daylight at 10:00 on 21st of June</td> </tr> <tr> <td>sun_201806211200</td> <td>Daylight at 12:00 on 21st of June</td> </tr> <tr> <td>sun_201806211400</td> <td>Daylight at 14:00 on 21st of June</td> </tr> <tr> <td>sun_201806211600</td> <td>Daylight at 16:00 on 21st of June</td> </tr> <tr> <td>sun_201806211800</td> <td>Daylight at 18:00 on 21st of June</td> </tr> <tr> <td>sun_201806212000</td> <td>Daylight at 20:00 on 21st of June</td> </tr> </tbody> </table> <p>Winter Solstice</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>sun_201812211000</td> <td>Daylight at 10:00 on 21st of December</td> </tr> <tr> <td>sun_201812211200</td> <td>Daylight at 12:00 on 21st of December</td> </tr> <tr> <td>sun_201812211400</td> <td>Daylight at 14:00 on 21st of December</td> </tr> <tr> <td>sun_201812211600</td> <td>Daylight at 16:00 on 21st of December</td> </tr> </tbody> </table> <p><strong>Noise / Window Noise</strong></p> <p>Noise level and the distribution of elements from an area help to understand how an object is exposed to the acoustics of this area. The acoustic simulation calculates the noise intensity on each individual hexagon from the analyzed object considering traffic and train noise datasets. Adjacent buildings are considered noise-blocking elements. The values are expressed in dBA (decibels).</p> <p>Window Noise</p> <p>The noise per window of a given area is aggregated via <code>min</code> and <code>max</code>. For instance, <code>window_noise_train_day_max</code> represents the maximum amount of noise received on any window of the area.</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>window_noise_traffic_day</td> <td>The amount of noise received on the area’s windows from daytime car traffic</td> </tr> <tr> <td>window_noise_traffic_night</td> <td>The amount of noise received on the area’s windows from night-time car traffic</td> </tr> <tr> <td>window_noise_train_day</td> <td>The amount of noise received on the area’s windows from daytime train traffic</td> </tr> <tr> <td>window_noise_train_night</td> <td>The amount of noise received on the area’s windows from night-time train traffic</td> </tr> </tbody> </table> <p>Area-Wise Noise</p> <p>The area-wise noise describes the amount of noise received from a noise source aggregated over the whole area in an unaggregated form. For instance, <code>noise_traffic_night</code> describes the dBA of noise received in the area from car traffic at night when propagating noise from all windows.</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>noise_traffic_day</td> <td>The amount of noise received in the area from daytime car traffic</td> </tr> <tr> <td>noise_traffic_night</td> <td>The amount of noise received in the area from night-time car traffic</td> </tr> <tr> <td>noise_train_day</td> <td>The amount of noise received in the area from daytime train traffic</td> </tr> <tr> <td>noise_train_night</td> <td>The amount of noise received in the area from night-time train traffic</td> </tr> </tbody> </table> <p><br> <strong>Connectivity</strong></p> <p>Centrality simulations help to analyze a floor plan, whether it’s a shopping mall and you want to identify prominent areas in order to select the most prominent spot or it’s an interior design circulation path and you want to determine open floor plan areas. Centrality simulations are done using topological measures that score grid cells by their importance as a part of a grid cell network.</p> <p>The distances and centralities are aggregated via <em>min</em>, <em>max</em>, <em>mean</em>, <em>std</em>, <em>median</em>, <em>p20,</em> and <em>p80</em>. For instance, <code>connectivity_balcony_distance_min</code> describes the shortest distance to the next balcony from the point closest to the balcony in the area.</p> <p>Distances</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>connectivity_room_distance</td> <td>Distance to the next area of type ROOM</td> </tr> <tr> <td>connectivity_living_dining_distance</td> <td>Distance to the next area of type LIVING_DINING</td> </tr> <tr> <td>connectivity_bathroom_distance</td> <td>Distance to the next area of type BATHROOM</td> </tr> <tr> <td>connectivity_kitchen_distance</td> <td>Distance to the next area of type KITCHEN</td> </tr> <tr> <td>connectivity_balcony_distance</td> <td>Distance to the next area of type BALCONY</td> </tr> <tr> <td>connectivity_loggia_distance</td> <td>Distance to the next area of type LOGGIA</td> </tr> <tr> <td>connectivity_entrance_door_distance</td> <td>Distance to the next apartment exit</td> </tr> </tbody> </table> <p>Centralities</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>connectivity_eigen_centrality</td> <td>The Eigen-Centrality value</td> </tr> <tr> <td>connectivity_betweenness_centrality</td> <td>The Betweenness-Centrality value</td> </tr> <tr> <td>connectivity_closeness_centrality</td> <td>The Closeness-Centrality value</td> </tr> </tbody> </table> <p><strong>Location Properties</strong></p> <p>In addition to the apartment-related data, we also provide simulation data on the climatic, and infrastructural characteristics of the locations. The file <code>locations.csv</code> contains the simulation data aggregated on a per-building basis. Each row contains the identifier <code>building_id</code> corresponding to the building ids referenced in <code>geometries.csv</code> and <code>simulations.csv</code>.</p> <p><strong>Climate</strong></p> <p>The climate features represent 39 simple features based on the spatial climate analysis of Meteo Swiss as derived from <a href="https://www.meteoswiss.admin.ch/climate/the-climate-of-switzerland/spatial-climate-analyses.html.">MeteoSwiss</a>. Each column is formatted as <code>climate_<category>_<period>. </code>For instance, the column <code>climate_tnorm_january</code> describes the monthly mean temperature in degrees Celsius (from the norm period of 1991-2020) at the location of the building. The aggregation methods vary per simulation category and are described in detail below.</p> <p>Temperature Normals</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>climate_tnorm_year</td> <td>The yearly mean temperature in degrees Celsius of the current norm period from 1991 to 2020 (TnormY9120)</td> </tr> <tr> <td>climate_tnorm_january</td> <td>The monthly mean temperature in January in degrees Celsius of the current norm period from 1991 to 2020 (TnormM9120)</td> </tr> <tr> <td>climate_tnorm_februry</td> <td>The monthly mean temperature in February in degrees Celsius of the current norm period from 1991 to 2020 (TnormM9120)</td> </tr> <tr> <td>...</td> <td>...</td> </tr> <tr> <td>climate_tnorm_december</td> <td>The monthly mean temperature in December in degrees Celsius of the current norm period from 1991 to 2020 (TnormM9120)</td> </tr> <tr> <td>climate_tminnorm_january</td> <td>The monthly minimum temperature in January in degrees Celsius of the current norm period from 1991 to 2020 (TminnormM9120)</td> </tr> <tr> <td>...</td> <td> </td> </tr> <tr> <td>climate_tminnorm_december</td> <td>The monthly minimum temperature in December in degrees Celsius of the current norm period from 1991 to 2020 (TnormM9120)</td> </tr> <tr> <td>climate_tmaxnorm_january</td> <td>The monthly maximum temperature in January in degrees Celcius of the current norm period from 1991 to 2020 (TnormM9120)</td> </tr> <tr> <td>...</td> <td> </td> </tr> <tr> <td>climate_tmaxnorm_december</td> <td>The monthly maximum temperature in December in degrees Celcius of the current norm period from 1991 to 2020 (TnormM9120)</td> </tr> </tbody> </table> <p>Sunshine Duration Normals</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>climate_snorm_year</td> <td>The yearly mean relative sunshine duration in percent of the current norm period from 1991 to 2020 (SnormY9120). Relative sunshine duration (RSD) is the ratio between the effective sunshine duration and the duration maximally possible if no clouds were covering the sun. A period with sunshine is defined as a period when the direct solar irradiance exceeds 200 W/m²</td> </tr> <tr> <td>climate_snorm_january</td> <td>The monthly mean relative sunshine duration for January in percent of the current norm period</td> </tr> <tr> <td>climate_snorm_februry</td> <td>The monthly mean relative sunshine duration for February in percent of the current norm period</td> </tr> <tr> <td>...</td> <td>...</td> </tr> <tr> <td>climate_snorm_december</td> <td>The monthly mean relative sunshine duration for December in percent of the current norm period</td> </tr> </tbody> </table> <p>Precipitation Normals</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>climate_rnorm_year</td> <td>The yearly mean precipitation in mm of the current norm period (RnormY9120)</td> </tr> <tr> <td>climate_rnorm_january</td> <td>The monthly mean precipitation for January in mm of the current norm period (RnormM9120)</td> </tr> <tr> <td>climate_rnorm_februry</td> <td>The monthly mean precipitation for February in mm of the current norm period (RnormM9120)</td> </tr> <tr> <td>...</td> <td>...</td> </tr> <tr> <td>climate_rnorm_december</td> <td>The monthly mean precipitation for December mm of the current norm period (RnormM9120)</td> </tr> </tbody> </table> <p><strong>10-Minute Walkshed Infrastructure</strong></p> <p>Based on OpenStreetMap data and its tagging system we counted all 465 tags (key and value tuples as listed here: https://wiki.openstreetmap.org/wiki/Map_features) which can be reached within a 10-minute walk from the location of the building. Each column is formatted as <code>walkshed_<poi_category>_<poi_type>. </code>For instance, the column <code>walkshed_shop_coffee</code> describes the number of coffee shops located within 10 minutes of walking from the building.</p> <p>The following is an excerpt of support categories and their corresponding types.</p> <ul> <li><code>shop: antique, art, ...</code></li> <li><code>amenity: art, atm, ...</code></li> <li><code>tourism: alpine, attraction, ...</code></li> <li><code>leisure: amusement, beach, ...</code></li> <li><code>healthcare: clinic, dentist, ...</code></li> <li><code>historic: archaeological, battlefield, ...</code></li> <li><code>ariaelway: station</code></li> </ul> <p><strong>Location Ratings</strong></p> <p>The location ratings, provided by <a href="https://en.fpre.ch/">Fahrländer Partner AG</a>, give insights into the living situation at locations in which the buildings are situated. The file location_ratings.csv provides the following information:</p> <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>location_rating_MIKRAT_W</td> <td>Living situation - Overall (1.0=worst, 5.0=best)</td> </tr> <tr> <td>location_rating_IMAGE_W</td> <td>Living situation - Image (1.0=worst, 5.0=best)</td> </tr> <tr> <td>location_rating_DL_W</td> <td>Living situation - Service Quality (1.0=worst, 5.0=best)</td> </tr> <tr> <td>location_rating_FZ_W</td> <td> <p>Living situation - Leisure Quality (1.0=worst, 5.0=best)</p> </td> </tr> <tr> <td>location_rating_NASE_W_DOM</td> <td>The most dominant segment of demand:<br> <br> 1 Rural-traditional<br> 2 Modern worker<br> 3 Transitional-alternative<br> 4 Traditional middle class<br> 5 Liberal middle class<br> 6 Established alternative<br> 7 Upper middle class<br> 8 Professional elite<br> 9 Urban elite<br> 10 Unknown<br> <br> <a href="https://en.fpre.ch/marktdaten/nachfragersegmente/nachfragersegmente-im-wohnungsmarkt/">More Information</a></td> </tr> <tr> <td>location_rating_FGFRQZ</td> <td> <p>The mean number of pedestrians per hour throughout a day between 7 am and 8 pm of an average working day.<br> <br> 1 <50<br> 2 50-100<br> 3 100-200<br> 4 200-500<br> 5 >500</p> </td> </tr> </tbody> </table>
Queensland Road Traffic Crashes Fatalities and Hospitalisations 2011-2021
<p>Data sets that have been prepared from the Open Data Portal of the Queensland Government (2022) available from <a href="https://www.data.qld.gov.au/dataset/crash-data-from-queensland-roads">https://www.data.qld.gov.au/dataset/crash-data-from-queensland-roads</a>.</p> <p>Provides information from 2011 - 2021 on all police reported fatalities and hospitalisations that have occurred during this time period, showing road conditions and driver demographics.</p>
A Tagged Traffic Accident Dataset for Machine Learning
<p>This dataset contains tagged accident data and is provided for reproducibility for our journal paper </p> <p><strong>Pablo Moriano, Andy Berres, Haowen Xu, Jibonananda Sanyal. “Spatiotemporal Features of Traffic Help Reduce Automatic Accident Detection Time.” <em>Expert Systems with Applications</em> 244 (2024): 122813. <a title="Persistent link using digital object identifier" href="https://doi.org/10.1016/j.eswa.2023.122813" target="_blank" rel="noopener">https://doi.org/10.1016/j.eswa.2023.122813</a></strong></p> <p>The accompanying Data in Brief publication discusses the methodology behind the creation of these data.</p> <p><strong>Berres, Andy, Pablo Moriano, Haowen Xu, Sarah Tennille, Lee Smith, Jonathan Storey, and Jibonananda Sanyal. "A Traffic Accident Dataset for Chattanooga, Tennessee." <em>Data in Brief</em> (2024): 110675.</strong></p> <p> </p> <p>The zip folder <strong><em>annotatedData.zip</em></strong> contains two subfolders: <strong><em>allData</em></strong> and <strong><em>bestData</em></strong>. The <em>bestData</em> folder contains all data for which a full neighborhood of five sensors upstream and five sensors downstream is available, whereas <em>allData</em> includes everything from <em>bestData</em> as well as data with a smaller number of neighboring sensors. Each folder contains one subfolder called <strong><em>accidents</em></strong> and one subfolder called <strong><em>non-accidents</em></strong>. The <em>accidents</em> folder contains one file per accident. The <em>non-accidents</em> folder contains files for the same location, day of the week and time as a corresponding accident, for each week during which there was no accident impact on the traffic.</p> <p>The file names in both folders are formatted as follows: <strong>yyyy-mm-dd-hhmm-rrrrrXaaa.a.csv</strong>, consisting of date (yyyy-mm-dd), time (hhmm in 24-hour format), and sensor name (rrrrrXaaa.a), which consists of road name (rrrrr; 5 alphanumerical characters), heading (X), and mile marker (aaa.a). For example, the file <em>2020-11-03-1611-00I24W182.8.csv </em> contains data for an accident which occurred at 4:11 p.m. on November 3, 2020 on I-24 Westbound near the radar sensor at mile marker 182.8.</p> <p>The content of each CSV file is a timeseries of radar data beginning 15 minutes prior to the reported incident and ending 15 minutes after the reported incident. It also contains metadata, such as the accident type, etc. Each CSV file contains the following columns:</p> <ul> <li><strong>incident at sensor(i)</strong>: 1 for yes (<em>accidents</em> folder), 0 for no (<em>non-accidents</em> folder)</li> <li><strong>road</strong>: road name with heading, e.g. 00I24E</li> <li><strong>mile</strong>: mile marker of nearest radar sensor, e.g. 182.8</li> <li><strong>type</strong>: accident type, e.g. “Prop Damage (over)” for property damage exceeding a certain threshold. For non-accidents, the type is given as “None”.</li> <li><strong>date</strong>: date of the data sample. For accidents, this is the date on which the accident occurred. For non-accidents, this is the date for which the non-accident data sample is collected.</li> <li><strong>incident_time</strong>: time the reference accident was reported in hh:mm. This is the time which is provided in E-TRIMS as the time the 911 call was made.</li> <li><strong>incident_hour</strong>: just the hour from the incident_time, in integer format.</li> <li><strong>data_time</strong>: timestamp for the timeseries contained in the file in hh:mm:ss format. The timeseries consists of 30 second timesteps.</li> <li><strong>weather</strong>: weather during <em>data_time</em>, based on data collected from NASA POWER. We used dry bulb temperature (°C), precipitation (mm/h), and wind speed (m/s) from the raw NASA POWER data to produce the classifications of <em>rain</em> (at least 1mm precipitation and temperatures above 2°C), <em>snow </em>(at least 1mm precipitation and temperatures at or below 2°C), and <em>wind</em> (wind speeds over 30 mph or 13.5 m/s). If there were no inclement weather conditions, we set the category to <em>“--"</em>.</li> <li><strong>light</strong>: light conditions during data_time. To produce this field, we collected sunrise, sunset, civil twilight start and civil twilight end times from <a href="https://sunrise-sunset.org">https://sunrise-sunset.org</a>, and derived the categories dawn, daylight, dusk, and dark using these start and end times.</li> <li>The last 33 columns contain radar data for the 11 sensors surrounding the accident or non-accident. For each sensor, we collected <em>speed</em> (mean over 30-second interval in miles per hour, or empty if no vehicles passed), <em>volume</em> (count of all vehicles passing during 30-second interval), and <em>occupancy</em> (mean % of occupancy over 30-second interval). These three variables are grouped in triples, of <strong>speed (k), volume (k), occupancy (k)</strong>, where <em>k</em> indicates the sensor number relative to the closest sensor <em>i</em> to the incident, <em>k<i</em> indicate upstream sensors and <em>k>i</em> indicate downstream sensors. For example, <strong>speed (i-5)</strong> refers to the mean speed at the sensor which is 5 hops upstream from the accident, and <strong>volume(i+1) </strong>refers to the number of vehicles at the sensor immediately downstream from the accident.</li> </ul> <p>The folder <strong><em>metaData.zip</em></strong> contains the following files:</p> <ul> <li><strong>Accidents.csv</strong>: cleaned-up accidents file with all accidents which happened on Chattanooga area highways between November 1, 2020 and April 29, 2021. We have removed accidents which happened on non-highway roads, and we have corrected the timestamps (which were in 12-hour format but missing a.m./p.m. markers) by cross-referencing light and weather conditions.</li> <li><strong>WeatherDict</strong><strong>.json:</strong> a dictionary containing the weather data synthesized from NASA POWER.</li> <li><strong>LightDict.json</strong>: a dictionary containing the light data synthesized from Sunrise-and-Sunset.</li> <li><strong>SensorTopology.csv</strong>: neighborhood information for each radar sensor in the Chattanooga area.</li> <li><strong>SensorZones.geojson</strong>: polygons used to determine the nearest radar sensor for each accident location. Each polygon is tagged with the corresponding radar sensor’s name.</li> </ul>
Transit Bus Left Side Camera Video Traffic Monitoring Dataset
<p>This dataset contains the raw data used in the research and development study reported in “Automated Traffic Surveillance Using Existing Cameras on Transit Buses”.</p> <p>This dataset consists of 11 video clips, each approximately 20 min. in duration, taken from the driver (left) side read camera of an in-service Ohio State University (OSU) Campus Area Bus Service (CABS) 40-foot transit bus running the West Campus Loop route. One set, consisting of 7 videos, was collected on a sunny day in October 2019. A second set, consisting of 3 videos, was collected during and after periods of rain and heavy rain in March 2022. Each video is accompanied by manually extracted ground truth of vehicles, and some other objects, that are in the roadway and observed by the camera.</p> <p> </p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.