This layer is deprecated as of April 3, 2023. Use this layer as a replacement: https://noaa.maps.arcgis.com/home/item.html?id=b0cdf263cea24544b0da2fc00fb2b259This nowCOAST time-enabled map service provides maps of NOAA/National Weather Service RIDGE2 mosaics of base reflectivity images across the Continental United States (CONUS) as well as Puerto Rico, Hawaii, Guam and Alaska with a 2 kilometer (1.25 mile) horizontal resolution. The mosaics are compiled by combining regional base reflectivity radar data obtained from 158 Weather Surveillance Radar 1988 Doppler (WSR-88D) also known as NEXt-generation RADar (NEXRAD) sites across the country operated by the NWS and the Dept. of Defense and also from data from Terminal Doppler Weather Radars (TDWR) at major airports. The colors on the map represent the strength of the energy reflected back toward the radar. The reflected intensities (echoes) are measured in dBZ (decibels of z). The color scale is very similar to the one used by the NWS RIDGE2 map viewer. The radar data itself is updated by the NWS every 10 minutes during non-precipitation mode, but every 4-6 minutes during precipitation mode. To ensure nowCOAST is displaying the most recent data possible, the latest mosaics are downloaded every 5 minutes. For more detailed information about the update schedule, see: https://new.nowcoast.noaa.gov/help/#section=updateschedule

Background Information

Reflectivity is related to the power, or intensity, of the reflected radiation that is sensed by the radar antenna. Reflectivity is expressed on a logarithmic scale in units called dBZ. The "dB" in the dBz scale is logarithmic and is unit less, but is used only to express a ratio. The "z" is the ratio of the density of water drops (measured in millimeters, raised to the 6th power) in each cubic meter (mm^6/m^3). When the "z" is large (many drops in a cubic meter), the reflected power is large. A small "z" means little returned energy. In fact, "z" can be less than 1 mm^6/m^3 and since it is logarithmic, dBz values will become negative, as often in the case when the radar is in clear air mode and indicated by earth tone colors. dBZ values are related to the intensity of rainfall. The higher the dBZ, the stronger the rain rate. A value of 20 dBZ is typically the point at which light rain begins. The values of 60 to 65 dBZ is about the level where 3/4 inch hail can occur. However, a value of 60 to 65 dBZ does not mean that severe weather is occurring at that location. The best reflectivity is lowest (1/2 degree elevation angle) reflectivity scan from the radar. The source of the base reflectivity mosaics is the NWS Southern Region Radar Integrated Display with Geospatial Elements (RIDGE2).

Time Information

This map is time-enabled, meaning that each individual layer contains time-varying data and can be utilized by clients capable of making map requests that include a time component.

This particular service can be queried with or without the use of a time component. If the time parameter is specified in a request, the data or imagery most relevant to the provided time value, if any, will be returned. If the time parameter is not specified in a request, the latest data or imagery valid for the present system time will be returned to the client. If the time parameter is not specified and no data or imagery is available for the present time, no data will be returned.

In addition to ArcGIS Server REST access, time-enabled OGC WMS 1.3.0 access is also provided by this service.

Due to software limitations, the time extent of the service and map layers displayed below does not provide the most up-to-date start and end times of available data. Instead, users have three options for determining the latest time information about the service:

Issue a returnUpdates=true request for an individual layer or for
the service itself, which will return the current start and end times of
available data, in epoch time format (milliseconds since 00:00 January 1,
1970). To see an example, click on the "Return Updates" link at the bottom of
this page under "Supported Operations". Refer to the ArcGIS REST API Map Service Documentation for more information.


  Issue an Identify (ArcGIS REST) or GetFeatureInfo (WMS) request against
  the proper layer corresponding with the target dataset. For raster
  data, this would be the "Image Footprints with Time Attributes" layer
  in the same group as the target "Image" layer being displayed. For
  vector (point, line, or polygon) data, the target layer can be queried
  directly. In either case, the attributes returned for the matching
  raster(s) or vector feature(s) will include the following:


      validtime: Valid timestamp.


      starttime: Display start time.


      endtime: Display end time.


      reftime: Reference time (sometimes reffered to as
      issuance time, cycle time, or initialization time).


      projmins: Number of minutes from reference time to valid
      time.


      desigreftime: Designated reference time; used as a
      common reference time for all items when individual reference
      times do not match.


      desigprojmins: Number of minutes from designated
      reference time to valid time.




  Query the nowCOAST LayerInfo web service, which has been created to
  provide additional information about each data layer in a service,
  including a list of all available "time stops" (i.e. "valid times"),
  individual timestamps, or the valid time of a layer's latest available
  data (i.e. "Product Time"). For more information about the LayerInfo
  web service, including examples of various types of requests, refer to
  the nowCOAST help documentation at:https://new.nowcoast.noaa.gov/help/#section=layerinfo

References

NWS, 2003: NWS Product Description Document for Radar Integrated Display with Geospatial Elements Version 2- RIDGE2, NWS/SRH, Fort Worth, Texas (Available at https://products.weather.gov/PDD/RIDGE_II_PDD_ver2.pdf). NWS, 2013: Radar Images for GIS Software (https://www.srh.noaa.gov/jetstream/doppler/gis.htm).

Summary:

Estimated stand-off distance between ADS-B equipped aircraft and obstacles. Obstacle information was sourced from the FAA Digital Obstacle File and the FHWA National Bridge Inventory. Aircraft tracks were sourced from processed data curated from the OpenSky Network. Results are presented as histograms organized by aircraft type and distance away from runways.

Description:

For many aviation safety studies, aircraft behavior is represented using encounter models, which are statistical models of how aircraft behave during close encounters. They are used to provide a realistic representation of the range of encounter flight dynamics where an aircraft collision avoidance system would be likely to alert. These models currently and have historically have been limited to interactions between aircraft; they have not represented the specific interactions between obstacles and aircraft equipped transponders. In response, we calculated the standoff distance between obstacles and ADS-B equipped manned aircraft.

For robustness, this assessment considered two different datasets of manned aircraft tracks and two datasets of obstacles. For robustness, MIT LL calculated the standoff distance using two different datasets of aircraft tracks and two datasets of obstacles. This approach aligned with the foundational research used to support the ASTM F3442/F3442M-20 well clear criteria of 2000 feet laterally and 250 feet AGL vertically.

The two datasets of processed tracks of ADS-B equipped aircraft curated from the OpenSky Network. It is likely that rotorcraft were underrepresented in these datasets. There were also no considerations for aircraft equipped only with Mode C or not equipped with any transponders. The first dataset was used to train the v1.3 uncorrelated encounter models and referred to as the “Monday” dataset. The second dataset is referred to as the “aerodrome” dataset and was used to train the v2.0 and v3.x terminal encounter model. The Monday dataset consisted of 104 Mondays across North America. The other dataset was based on observations at least 8 nautical miles within Class B, C, D aerodromes in the United States for the first 14 days of each month from January 2019 through February 2020. Prior to any processing, the datasets required 714 and 847 Gigabytes of storage. For more details on these datasets, please refer to "Correlated Bayesian Model of Aircraft Encounters in the Terminal Area Given a Straight Takeoff or Landing" and “Benchmarking the Processing of Aircraft Tracks with Triples Mode and Self-Scheduling.”

Two different datasets of obstacles were also considered. First was point obstacles defined by the FAA digital obstacle file (DOF) and consisted of point obstacle structures of antenna, lighthouse, meteorological tower (met), monument, sign, silo, spire (steeple), stack (chimney; industrial smokestack), transmission line tower (t-l tower), tank (water; fuel), tramway, utility pole (telephone pole, or pole of similar height, supporting wires), windmill (wind turbine), and windsock. Each obstacle was represented by a cylinder with the height reported by the DOF and a radius based on the report horizontal accuracy. We did not consider the actual width and height of the structure itself. Additionally, we only considered obstacles at least 50 feet tall and marked as verified in the DOF.

The other obstacle dataset, termed as “bridges,” was based on the identified bridges in the FAA DOF and additional information provided by the National Bridge Inventory. Due to the potential size and extent of bridges, it would not be appropriate to model them as point obstacles; however, the FAA DOF only provides a point location and no information about the size of the bridge. In response, we correlated the FAA DOF with the National Bridge Inventory, which provides information about the length of many bridges. Instead of sizing the simulated bridge based on horizontal accuracy, like with the point obstacles, the bridges were represented as circles with a radius of the longest, nearest bridge from the NBI. A circle representation was required because neither the FAA DOF or NBI provided sufficient information about orientation to represent bridges as rectangular cuboid. Similar to the point obstacles, the height of the obstacle was based on the height reported by the FAA DOF. Accordingly, the analysis using the bridge dataset should be viewed as risk averse and conservative. It is possible that a manned aircraft was hundreds of feet away from an obstacle in actuality but the estimated standoff distance could be significantly less. Additionally, all obstacles are represented with a fixed height, the potentially flat and low level entrances of the bridge are assumed to have the same height as the tall bridge towers. The attached figure illustrates an example simulated bridge.

It would had been extremely computational inefficient to calculate the standoff distance for all possible track points. Instead, we define an encounter between an aircraft and obstacle as when an aircraft flying 3069 feet AGL or less comes within 3000 feet laterally of any obstacle in a 60 second time interval. If the criteria were satisfied, then for that 60 second track segment we calculate the standoff distance to all nearby obstacles. Vertical separation was based on the MSL altitude of the track and the maximum MSL height of an obstacle.

For each combination of aircraft track and obstacle datasets, the results were organized seven different ways. Filtering criteria were based on aircraft type and distance away from runways. Runway data was sourced from the FAA runways of the United States, Puerto Rico, and Virgin Islands open dataset. Aircraft type was identified as part of the em-processing-opensky workflow.

All: No filter, all observations that satisfied encounter conditions

nearRunway: Aircraft within or at 2 nautical miles of a runway

awayRunway: Observations more than 2 nautical miles from a runway

glider: Observations when aircraft type is a glider

fwme: Observations when aircraft type is a fixed-wing multi-engine

fwse: Observations when aircraft type is a fixed-wing single engine

rotorcraft: Observations when aircraft type is a rotorcraft

License

This dataset is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International(CC BY-NC-ND 4.0).

This license requires that reusers give credit to the creator. It allows reusers to copy and distribute the material in any medium or format in unadapted form and for noncommercial purposes only. Only noncommercial use of your work is permitted. Noncommercial means not primarily intended for or directed towards commercial advantage or monetary compensation. Exceptions are given for the not for profit standards organizations of ASTM International and RTCA.

MIT is releasing this dataset in good faith to promote open and transparent research of the low altitude airspace. Given the limitations of the dataset and a need for more research, a more restrictive license was warranted. Namely it is based only on only observations of ADS-B equipped aircraft, which not all aircraft in the airspace are required to employ; and observations were source from a crowdsourced network whose surveillance coverage has not been robustly characterized.

As more research is conducted and the low altitude airspace is further characterized or regulated, it is expected that a future version of this dataset may have a more permissive license.

Distribution Statement

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

© 2021 Massachusetts Institute of Technology.

Delivered to the U.S. Government with Unlimited Rights, as defined in DFARS Part 252.227-7013 or 7014 (Feb 2014). Notwithstanding any copyright notice, U.S. Government rights in this work are defined by DFARS 252.227-7013 or DFARS 252.227-7014 as detailed above. Use of this work other than as specifically authorized by the U.S. Government may violate any copyrights that exist in this work.

This material is based upon work supported by the Federal Aviation Administration under Air Force Contract No. FA8702-15-D-0001. Any opinions, findings, conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the Federal Aviation Administration.

This document is derived from work done for the FAA (and possibly others); it is not the direct product of work done for the FAA. The information provided herein may include content supplied by third parties. Although the data and information contained herein has been produced or processed from sources believed to be reliable, the Federal Aviation Administration makes no warranty, expressed or implied, regarding the accuracy, adequacy, completeness, legality, reliability or usefulness of any information, conclusions or recommendations provided herein. Distribution of the information contained herein does not constitute an endorsement or warranty of the data or information provided herein by the Federal Aviation Administration or the U.S. Department of Transportation. Neither the Federal Aviation Administration nor the U.S. Department of Transportation shall be held liable for any improper or incorrect use of the information contained herein and assumes no responsibility for anyone’s use of the information. The Federal Aviation Administration and U.S. Department of Transportation shall not be liable for any claim for any loss, harm, or other damages arising from access to or use of data or information, including without limitation any direct, indirect, incidental, exemplary, special or consequential damages, even if advised of the possibility of such damages. The Federal Aviation Administration shall not be liable to anyone for any decision made or action taken, or not taken, in reliance on the information contained

This dataset comes as SQL-importable file and is compatible with the widely available MariaDB- and MySQL-databases.

It is based on (and incorporates/extends) the dataset "1151 commits with software maintenance activity labels (corrective,perfective,adaptive)" by Levin and Yehudai (https://doi.org/10.5281/zenodo.835534).

The extensions to this dataset were obtained using Git-Tools, a tool that is included in the Git-Density (https://doi.org/10.5281/zenodo.2565238) suite. For each of the projects in the original dataset, Git-Tools was run in extended mode.

The dataset contains these tables:

x1151: The original dataset from Levin and Yehudai.

despite its name, this dataset has only 1,149 commits, as two commits were duplicates in the original dataset.

This dataset spanned 11 projects, each of which had between 99 and 114 commits

This dataset has 71 features and spans the projects RxJava, hbase, elasticsearch, intellij-community, hadoop, drools, Kotlin, restlet-framework-java, orientdb, camel and spring-framework.

gtools_ex (short for Git-Tools, extended)

Contains 359,569 commits, analyzed using Git-Tools in extended mode

It spans all commits and projects from the x1151 dataset as well.

All 11 projects were analyzed, from the initial commit until the end of January 2019. For the projects Intellij and Kotlin, the first 35,000 resp. 30,000 commits were analyzed.

This dataset introduces 35 new features (see list below), 22 of which are size- or density-related.

The dataset contains these views:

geX_L (short for Git-tools, extended, with labels)

Joins the commits' labels from x1151 with the extended attributes from gtools_ex, using the commits' hashes.

jeX_L (short for joined, extended, with labels)

Joins the datasets x1151 and gtools_ex entirely, based on the commits' hashes.

Features of the gtools_ex dataset:

SHA1

RepoPathOrUrl

AuthorName

CommitterName

AuthorTime (UTC)

CommitterTime (UTC)

MinutesSincePreviousCommit: Double, describing the amount of minutes that passed since the previous commit. Previous refers to the parent commit, not the previous in time.

Message: The commit's message/comment

AuthorEmail

CommitterEmail

AuthorNominalLabel: All authors of a repository are analyzed and merged by Git-Density using some heuristic, even if they do not always use the same email address or name. This label is a unique string that helps identifying the same author across commits, even if the author did not always use the exact same identity.

CommitterNominalLabel: The same as AuthorNominalLabel, but for the committer this time.

IsInitialCommit: A boolean indicating, whether a commit is preceded by a parent or not.

IsMergeCommit: A boolean indicating whether a commit has more than one parent.

NumberOfParentCommits

ParentCommitSHA1s: A comma-concatenated string of the parents' SHA1 IDs

NumberOfFilesAdded

NumberOfFilesAddedNet: Like the previous property, but if the net-size of all changes of an added file is zero (i.e. when adding a file that is empty/whitespace or does not contain code), then this property does not count the file.

NumberOfLinesAddedByAddedFiles

NumberOfLinesAddedByAddedFilesNet: Like the previous property, but counts the net-lines

NumberOfFilesDeleted

NumberOfFilesDeletedNet: Like the previous property, but considers only files that had net-changes

NumberOfLinesDeletedByDeletedFiles

NumberOfLinesDeletedByDeletedFilesNet: Like the previous property, but counts the net-lines

NumberOfFilesModified

NumberOfFilesModifiedNet: Like the previous property, but considers only files that had net-changes

NumberOfFilesRenamed

NumberOfFilesRenamedNet: Like the previous property, but considers only files that had net-changes

NumberOfLinesAddedByModifiedFiles

NumberOfLinesAddedByModifiedFilesNet: Like the previous property, but counts the net-lines

NumberOfLinesDeletedByModifiedFiles

NumberOfLinesDeletedByModifiedFilesNet: Like the previous property, but counts the net-lines

NumberOfLinesAddedByRenamedFiles

NumberOfLinesAddedByRenamedFilesNet: Like the previous property, but counts the net-lines

NumberOfLinesDeletedByRenamedFiles

NumberOfLinesDeletedByRenamedFilesNet: Like the previous property, but counts the net-lines

Density: The ratio between the two sums of all lines added+deleted+modified+renamed and their resp. gross-version. A density of zero means that the sum of net-lines is zero (i.e. all lines changes were just whitespace, comments etc.). A density of of 1 means that all changed net-lines contribute to the gross-size of the commit (i.e. no useless lines with e.g. only comments or whitespace).

AffectedFilesRatioNet: The ratio between the sums of NumberOfFilesXXX and NumberOfFilesXXXNet

This dataset is supporting the paper "Importance and Aptitude of Source code Density for Commit Classification into Maintenance Activities", as submitted to the QRS2019 conference (The 19th IEEE International Conference on Software Quality, Reliability, and Security). Citation: Hönel, S., Ericsson, M., Löwe, W. and Wingkvist, A., 2019. Importance and Aptitude of Source code Density for Commit Classification into Maintenance Activities. In The 19th IEEE International Conference on Software Quality, Reliability, and Security.

Abstract

The dataset is a relational dataset of 8,000 households households, representing a sample of the population of an imaginary middle-income country. The dataset contains two data files: one with variables at the household level, the other one with variables at the individual level. It includes variables that are typically collected in population censuses (demography, education, occupation, dwelling characteristics, fertility, mortality, and migration) and in household surveys (household expenditure, anthropometric data for children, assets ownership). The data only includes ordinary households (no community households). The dataset was created using REaLTabFormer, a model that leverages deep learning methods. The dataset was created for the purpose of training and simulation and is not intended to be representative of any specific country.

The full-population dataset (with about 10 million individuals) is also distributed as open data.

Geographic coverage

The dataset is a synthetic dataset for an imaginary country. It was created to represent the population of this country by province (equivalent to admin1) and by urban/rural areas of residence.

Analysis unit

Household, Individual

Universe

The dataset is a fully-synthetic dataset representative of the resident population of ordinary households for an imaginary middle-income country.

Kind of data

ssd

Sampling procedure

The sample size was set to 8,000 households. The fixed number of households to be selected from each enumeration area was set to 25. In a first stage, the number of enumeration areas to be selected in each stratum was calculated, proportional to the size of each stratum (stratification by geo_1 and urban/rural). Then 25 households were randomly selected within each enumeration area. The R script used to draw the sample is provided as an external resource.

Mode of data collection

other

Research instrument

The dataset is a synthetic dataset. Although the variables it contains are variables typically collected from sample surveys or population censuses, no questionnaire is available for this dataset. A "fake" questionnaire was however created for the sample dataset extracted from this dataset, to be used as training material.

Cleaning operations

The synthetic data generation process included a set of "validators" (consistency checks, based on which synthetic observation were assessed and rejected/replaced when needed). Also, some post-processing was applied to the data to result in the distributed data files.

Response rate

This is a synthetic dataset; the "response rate" is 100%.

Introduction

The 802.11 standard includes several management features and corresponding frame types. One of them are Probe Requests (PR), which are sent by mobile devices in an unassociated state to scan the nearby area for existing wireless networks. The frame part of PRs consists of variable-length fields, called Information Elements (IE), which represent the capabilities of a mobile device, such as supported data rates.

This dataset contains PRs collected over a seven-day period by four gateway devices in an uncontrolled urban environment in the city of Catania.

It can be used for various use cases, e.g., analyzing MAC randomization, determining the number of people in a given location at a given time or in different time periods, analyzing trends in population movement (streets, shopping malls, etc.) in different time periods, etc.

Related dataset

Same authors also produced the Labeled dataset of IEEE 802.11 probe requests with same data layout and recording equipment.

Measurement setup

The system for collecting PRs consists of a Raspberry Pi 4 (RPi) with an additional WiFi dongle to capture WiFi signal traffic in monitoring mode (gateway device). Passive PR monitoring is performed by listening to 802.11 traffic and filtering out PR packets on a single WiFi channel.

The following information about each received PR is collected: - MAC address - Supported data rates - extended supported rates - HT capabilities - extended capabilities - data under extended tag and vendor specific tag - interworking - VHT capabilities - RSSI - SSID - timestamp when PR was received.

The collected data was forwarded to a remote database via a secure VPN connection. A Python script was written using the Pyshark package to collect, preprocess, and transmit the data.

Data preprocessing

The gateway collects PRs for each successive predefined scan interval (10 seconds). During this interval, the data is preprocessed before being transmitted to the database. For each detected PR in the scan interval, the IEs fields are saved in the following JSON structure:

PR_IE_data = { 'DATA_RTS': {'SUPP': DATA_supp , 'EXT': DATA_ext}, 'HT_CAP': DATA_htcap, 'EXT_CAP': {'length': DATA_len, 'data': DATA_extcap}, 'VHT_CAP': DATA_vhtcap, 'INTERWORKING': DATA_inter, 'EXT_TAG': {'ID_1': DATA_1_ext, 'ID_2': DATA_2_ext ...}, 'VENDOR_SPEC': {VENDOR_1:{ 'ID_1': DATA_1_vendor1, 'ID_2': DATA_2_vendor1 ...}, VENDOR_2:{ 'ID_1': DATA_1_vendor2, 'ID_2': DATA_2_vendor2 ...} ...} }

Supported data rates and extended supported rates are represented as arrays of values that encode information about the rates supported by a mobile device. The rest of the IEs data is represented in hexadecimal format. Vendor Specific Tag is structured differently than the other IEs. This field can contain multiple vendor IDs with multiple data IDs with corresponding data. Similarly, the extended tag can contain multiple data IDs with corresponding data.
Missing IE fields in the captured PR are not included in PR_IE_DATA.

When a new MAC address is detected in the current scan time interval, the data from PR is stored in the following structure:

{'MAC': MAC_address, 'SSIDs': [ SSID ], 'PROBE_REQs': [PR_data] },

where PR_data is structured as follows:

{ 'TIME': [ DATA_time ], 'RSSI': [ DATA_rssi ], 'DATA': PR_IE_data }.

This data structure allows to store only 'TOA' and 'RSSI' for all PRs originating from the same MAC address and containing the same 'PR_IE_data'. All SSIDs from the same MAC address are also stored. The data of the newly detected PR is compared with the already stored data of the same MAC in the current scan time interval. If identical PR's IE data from the same MAC address is already stored, only data for the keys 'TIME' and 'RSSI' are appended. If identical PR's IE data from the same MAC address has not yet been received, then the PR_data structure of the new PR for that MAC address is appended to the 'PROBE_REQs' key. The preprocessing procedure is shown in Figure ./Figures/Preprocessing_procedure.png

At the end of each scan time interval, all processed data is sent to the database along with additional metadata about the collected data, such as the serial number of the wireless gateway and the timestamps for the start and end of the scan. For an example of a single PR capture, see the Single_PR_capture_example.json file.

Folder structure

For ease of processing of the data, the dataset is divided into 7 folders, each containing a 24-hour period. Each folder contains four files, each containing samples from that device.

The folders are named after the start and end time (in UTC). For example, the folder 2022-09-22T22-00-00_2022-09-23T22-00-00 contains samples collected between 23th of September 2022 00:00 local time, until 24th of September 2022 00:00 local time.

Files representing their location via mapping: - 1.json -> location 1 - 2.json -> location 2 - 3.json -> location 3 - 4.json -> location 4

Environments description

The measurements were carried out in the city of Catania, in Piazza Università and Piazza del Duomo The gateway devices (rPIs with WiFi dongle) were set up and gathering data before the start time of this dataset. As of September 23, 2022, the devices were placed in their final configuration and personally checked for correctness of installation and data status of the entire data collection system. Devices were connected either to a nearby Ethernet outlet or via WiFi to the access point provided.

Four Raspbery Pi-s were used: - location 1 -> Piazza del Duomo - Chierici building (balcony near Fontana dell’Amenano) - location 2 -> southernmost window in the building of Via Etnea near Piazza del Duomo - location 3 -> nothernmost window in the building of Via Etnea near Piazza Università - location 4 -> first window top the right of the entrance of the University of Catania

Locations were suggested by the authors and adjusted during deployment based on physical constraints (locations of electrical outlets or internet access) Under ideal circumstances, the locations of the devices and their coverage area would cover both squares and the part of Via Etna between them, with a partial overlap of signal detection. The locations of the gateways are shown in Figure ./Figures/catania.png.

Known dataset shortcomings

Due to technical and physical limitations, the dataset contains some identified deficiencies.

PRs are collected and transmitted in 10-second chunks. Due to the limited capabilites of the recording devices, some time (in the range of seconds) may not be accounted for between chunks if the transmission of the previous packet took too long or an unexpected error occurred.

Every 20 minutes the service is restarted on the recording device. This is a workaround for undefined behavior of the USB WiFi dongle, which can no longer respond. For this reason, up to 20 seconds of data will not be recorded in each 20-minute period.

The devices had a scheduled reboot at 4:00 each day which is shown as missing data of up to a few minutes.

 Location 1 - Piazza del Duomo - Chierici

The gateway device (rPi) is located on the second floor balcony and is hardwired to the Ethernet port. This device appears to function stably throughout the data collection period. Its location is constant and is not disturbed, dataset seems to have complete coverage.

 Location 2 - Via Etnea - Piazza del Duomo

The device is located inside the building. During working hours (approximately 9:00-17:00), the device was placed on the windowsill. However, the movement of the device cannot be confirmed. As the device was moved back and forth, power outages and internet connection issues occurred. The last three days in the record contain no PRs from this location.

 Location 3 - Via Etnea - Piazza Università

Similar to Location 2, the device is placed on the windowsill and moved around by people working in the building. Similar behavior is also observed, e.g., it is placed on the windowsill and moved inside a thick wall when no people are present. This device appears to have been collecting data throughout the whole dataset period.

 Location 4 - Piazza Università

This location is wirelessly connected to the access point. The device was placed statically on a windowsill overlooking the square. Due to physical limitations, the device had lost power several times during the deployment. The internet connection was also interrupted sporadically.

Recognitions

The data was collected within the scope of Resiloc project with the help of City of Catania and project partners.

This dataset contains information about vehicles (or units as they are identified in crash reports) involved in a traffic crash. This dataset should be used in conjunction with the traffic Crash and People dataset available in the portal. “Vehicle” information includes motor vehicle and non-motor vehicle modes of transportation, such as bicycles and pedestrians. Each mode of transportation involved in a crash is a “unit” and get one entry here. Each vehicle, each pedestrian, each motorcyclist, and each bicyclist is considered an independent unit that can have a trajectory separate from the other units. However, people inside a vehicle including the driver do not have a trajectory separate from the vehicle in which they are travelling and hence only the vehicle they are travelling in get any entry here. This type of identification of “units” is needed to determine how each movement affected the crash. Data for occupants who do not make up an independent unit, typically drivers and passengers, are available in the People table. Many of the fields are coded to denote the type and location of damage on the vehicle. Vehicle information can be linked back to Crash data using the “CRASH_RECORD_ID” field. Since this dataset is a combination of vehicles, pedestrians, and pedal cyclists not all columns are applicable to each record. Look at the Unit Type field to determine what additional data may be available for that record.

The Chicago Police Department reports crashes on IL Traffic Crash Reporting form SR1050. The crash data published on the Chicago data portal mostly follows the data elements in SR1050 form. The current version of the SR1050 instructions manual with detailed information on each data elements is available here.

Change 11/21/2023: We have removed the RD_NO (Chicago Police Department report number) for privacy reasons.

A. SUMMARY This data was created by the San Francisco Department of Public Health (SFDPH) to update the 2017 Vision Zero High Injury Network dataset. It identifies street segments in San Francisco that have a high number of fatalities and severe injuries. This dataset is a simplified representation of the network and only indicates which streets qualified; it does not contain any additional information, including prioritization by mode or a breakdown of count reported/unreported severe/fatal injuries by corridorized segment. SFDPH shares this network with CCSF agencies to help inform where interventions could save lives and reduce injury severity.

B. HOW THE DATASET IS CREATED The 2022 Vision Zero High Injury Network is derived from 2017-2022 severe and fatal injury data from Zuckerberg San Francisco General (ZSFG), San Francisco Police Department (SFPD), the Office of the Medical Examiner (OME), and Emergency Medical Services agencies. ZSFG patient records and SFPD victim records were probabilistically linked through the Transportation Injury Surveillance System (TISS) using LinkSolv Software. Injury severity for linked SFPD/ZSFG records was reclassified based on injury outcome as determined by ZSFG medical personnel (net 1732 police reported severe injuries) consistent with the Vision Zero Severe Injury Protocol (2017) while unlinked SFPD victim records were not changed (178 police reported severe injuries). Severe injuries captured by ZSFG but not reported to SFPD were also included in this analysis (650 unreported/unlinked geocodable severe injury patient records). Fatality data came from OME records that meet San Francisco’s Vision Zero Fatality Protocol (129 fatalities). Only transportation-related injuries resulting in a severe injury or fatality were used in this analysis. Each street centerline segment block was converted into ~0.25 mile overlapping corridorized sections using ArcPy. These sections were intersected with the severe/fatal injury data. Only severe/fatal injuries with the same primary street as the corridorized section were counted for that section. The count of severe/fatal injuries was then normalized by the sections mileage to derive the number of severe/fatal injuries per mile. A threshold of ≥10 severe/fatal injuries per mile was used as the threshold to determine if a corridorized segment qualified for inclusion into the network. A full methodology of the 2022 update to the Vision Zero High Injury Network can be found here: https://www.visionzerosf.org/wp-content/uploads/2023/03/2022_Vision_Zero_Network_Update_Methodology.pdf

C. UPDATE PROCESS This dataset will be updated on an as needed basis.

D. HOW TO USE THIS DATASET The 2022 Vision Zero Network represents a snapshot in time (2017-2021) where severe and fatal injuries are most concentrated. It may not reflect current conditions or changes to the City’s transportation system. Although prior incidents can be indicative of future incidents, the 2022 Vision Zero High Injury Network is not a prediction (probability) of future risk. The High Injury Network approach is in contrast to risk-based analysis, which focuses on locations determined to be more dangerous with increased risk or danger often calculated by dividing the number of injuries or collisions by vehicle volumes to estimate risk of injury per vehicle. The High Injury Network provides information regarding the streets where injuries, particularly severe and fatal, are concentrated in San Francisco based on injury counts; it is not an assessment of whether a street or particular location is dangerous. The 2022 Vision Zero Network is derived from the more severe injury outcomes (count of severe/fatal injuries) and may not cover locations with high numbers of less severe injury collisions. Hospital and emergency medical service records from which SFPD-unreported injury and reclassified injury collisions are derived are protected by the Health Insurance Portability and Accountability Act and state medical privacy laws, thus have strict confidentiality and privacy requirements. As of November 2021, SFDPH is working in conjunction with SFDPH’s Office of Compliance and Privacy Affairs, Zuckerberg San Francisco General Hospital (“ZSFG”) and the SFMTA to determine how SFDPH can share the data in compliance with federal and state privacy laws. Intersection and other small-area specific counts of severe/fatal injuries have thus been intentionally excluded from this document as data sharing requirements are yet to be determined.

E. RELATED DATASETS