This is the appendix section of the documentation that contains reference information for all user types. The following is a list of included sections and their purposes:
Outlines files and data formats used in the tools with how they were used.
Details the primary calculations used in processing the data.
Explains the process of conflating OpenStreetMap data with NPMRDS data.
Lists the Application Programming Interfaces (APIs) used within the tool.
Reference guides have one job only: to describe. They are code-determined, because ultimately that’s what they describe: key classes, functions, APIs, and so they should list things like functions, fields, attributes and methods, and set out how to use them. Reference material is information-oriented.
The TMC_Identification.csv file is included with RITIS Massive Data Downloader results. It contains the associated metadata for all the TMCs in the download. Per RITIS, this CSV file, not the shapefile, is the autoritative source for all road segment metadata.
Field Definitions
The NPMRDS Shapefiles are provided by RITIS. They contain "a combination of attributes for each specific TMC segment and relevant HPMS data related to route, inventory, network type and traffic volume attributes. NPMRDS users should note that TMC segment attributes are for a particular travel direction, whereas the HPMS attributes assigned to that TMC segment (indicated in the Appendix A table) are for BOTH TRAVEL DIRECTIONS". Per RITIS, the TMC_Identification CSV file, not the shapefile, is the autoritative source for all road segment metadata.
A roadway layer generated from NYSDOTs Roadway Inventory System showing roadway characteristics and administrative attributes. The layer covers all public owned roads. The state highway system currently includes more comprehensive attribution. The roadway data reflects conditions one year previous to the publication date. For more information, contact NYSDOT Highway Data Services HDSB@dot.ny.gov.
A common problem when trying to understand and analyze data to understand the behavior and measure the performance of transportation networks is that data providers often use entirely different digital geometries to represent the same road physical roads. Internally NYSDOT maintains a linear referencing system which represents New York's road network and many different departments in NYSDOT report a rich array of programmatic data into this system.
In working to make a performance measurement system for NPMRDS there were many occasions where it would have been very useful to be able use data for NYSDOT's LRS system along side NPMRDS data to get a more informative analysis but doing so is difficult to impossible because the geometries representing the roads were very different.
We initially considered solving this problem by making a direct conflation between NPMRDS and NYSDOT's LRS but this approach was problematic. LRS is cernterline (one line reprsenting both directions of a road) and TMC geometries are directional (one line for each direction of a road) and because the LRS system often simplifies the representation of highway ramps, interchanges and traffic circles a number of difficult edge cases arise in converting it a directional representation. Additionally neither set of geometries is designed to be a routable graph which is a very desirable feature, not only during a conflation but also for subsequent analysis.
OpenStreetMap (OSM) is a collaborative project to create a free editable map of the world. The geodata underlying the map is considered the primary output of the project. The creation and growth of OSM has been motivated by restrictions on use or availability of map data across much of the world, and the advent of inexpensive portable satellite navigation devices. OSM's street network has become a highly accurate and reliable (1) representation of the roads in the United States relied on by large companies like Apple. Microsoft, Uber and Lyft.
OSM's street network is designed from the ground up to be a routable graph network with I highly accurate representation of difficult road infrastructure such as ramps, clovers and traffic circles. Additionally it represents not only the full set of public roads like LRS but has build in additional information about private roads, sidewalks, bike paths which have become increasingly valuable as planners continue to incorporate Complete Streets(2) approaches to design and planning.
Additionally as OSM becomes a more widely adopted standard for road networks there is a growing amount of open source software and more companies are providing useful data on OSM segments, for example Replica(3) models publish results on OSM links, and Uber publishes a free probe speed data set (4) in select cities using OSM links.
In our research we found Shared Streets (5) a linear referencing system designed to make it easier to conflate different road network geometries onto OSM, an evolution of the OpenLR(6) system developed by TomTom. This work provided us with a clear path forward for making consistent longitudinal conflation between both NYSDOT's LRS and TMC network by mapping both sets of segment ID's onto OSM geometries.
To create a system that allows us to switch data between the different road networks we set out to split the OSM network into segments such that each segment had a unique value from OSM, LRS and TMCs.
The overview for the conflation process is:
Conflation output is a directional shapefile where direction is noted both in metadata (dir, osm_fwd) and by the orientation of the line geometries. Using an offset will allow you visualize both directions. Each segment has a single OSM, RIS and TMC ids related to the IDS in the corresponding input files. There will be many segments to each conflation ID type which can be selected by ID to reconstitute the approximated segment in the OSM geometry.
In making data available for viewing on this website AVAIL has created restful API's representing a number of data sources raw and computed for user's who would benefit from programmatic access to these data set
This api powers the reporting view and allows raw and aggregated data to be fetched by TMC, time range and aggregation level.
This api powers macro view and returns data by TMC for annually aggregated performance mesaures