Data

Waze offered a traffic data feed to government transportation agencies, which included alerts (citizen alerts of traffic delays, construction, accidents, etc.) and jams (slowdown information created algorithmically by the Waze platform). The Automated Waze Imports task consisted of several components: • Customized and deployed a Waze alerts importer. • Enhanced the alerts importer eligible for the 511 Google delay measurements. • Developed an importer for Waze Jams. The project involved importing all alert types from Waze, determining which events should be documented based on reliability and confidence scores, adding expected delays to 511 events, determining which jams should be eligible for import into 511, and adding directional information to displayed jams.

The project assessed MnDOT’s ability to share signal phasing and timing (SPaT) data and intersection geometry (MAP) data to travelers and third-party systems via a centralized process. The following tasks were completed: • Developed a concept of operations and systems requirements for a centralized data sharing system. • Conducted stakeholder interviews with multiple DOTs that used similar traffic signal software as MnDOT. • Demonstrated an existing software product (Q-Free's MAXVIEW version 2.X) against the system requirements and documented the results.

The following snow and ice formula computations were prepared utilizing the current snow and ice formula (latest change was in 1983). In March of 1986, all maintenance areas were requested to update their input data for the snow and ice formula for the upcoming winter season (1986-87). In addition, projections for the next five (5) winter seasons were asked for based upon the following: 1. Projected increases in lane miles and interchanges by an assumed completion date through new construction or jurisdictional changes. All these changes were itemized. 2. Changes in classification due to an increase in traffic volume. An increase of 2% per year was allowed. The data received was inputed into a computer program to generate the tables which follow.

This report shows the results of a study on traffic data and congestion.

The data contained in the Vehicle Classification Report is collected at 95 Trend sites on a two year cycle. Data is also collected at 939 Update sites on a six year cycle but due to their large number these are not discussed in this report. Comparisons contained in this report are among counts taken at the same location over a period of time. The resulting changes are specific to those sites and are not necessarily indicative of changes taking place on the whole system.

One of the key measures of freight performance along interstate corridors in the United States is the average speed of travel. This report documents the findings and analysis of the ATRI Freight Performance Measure (FPM) database systems and investigates a potential FPM system design that can efficiently and effectively processes more and larger Automatic Vehicle Location (AVL) datasets collected from various trucking companies. The current FPM system at ATRI was evolved from its previous system based on GIS software. The averaged speed calculations resulting from the data process of each FPM system are somewhat different. Analysis of the average speed calculation and investigation of speed differences are discussed in chapter one. FPM database system analysis and comparison are included in chapter two. The final chapter presents an ideal FPM system and requirements needed for migration.

The objective is to develop a model that defines the objects necessary for describing locations and the relationships between these objects. Objects include real-world and theoretical "anchors" of Mn/DOT's standard location reference systems (e.g., geodetic monuments, Public Land Survey corners, routes, mileposts, stations), geometric and topological representations of the transportation network (e.g., digitized line strings, topological links, nodes), and typical abstract or aggregated views of the network (e.g., pavement management segments, snow plow routes). [Mn/DOT 1993b] Individual end users of systems which reference spatial locations each have their own "external" view of how to locate objects. Roadway inventory may use route/reference point, construction surveying may use alignment station/offset, cartographers may use coordinates, traffic forecasting may use link/node, and traffic accident reporting street addresses. At the other end of the spectrum, different automated systems may each use different "internal" representation schemes for storing information in the computer. A CAD system, like Mn/DOT's Intergraph system represents roads as vectors on a drawing layer. ARC/Info approximates them as arcs (actually chords) on a map coverage. ORACLE Highways represents roads as rows in relational tables. An object based graphic data system like ODS models roads as individual objects with data and behavior consistent with a particular end user's view of the road. The objective of this project is to develop a single, comprehensive, conceptual model of location information. This model fits between the various external and internal views (see Figure 1). As such, it must support all of the identified external views. The internal views can be thought of as individual vendors' interpretation of that part ( or all) of the conceptual model necessary to support their delivered functionality, internally represented in the manner which best supports, in their opinion, that functionality.

The purpose of this document is twofold; To inform transportation oriented readers about existing systems that have been developed in other state agencies that may be of interest to them, and to provide an awareness of the State Information Systems Project (SISP), and encourage everyone to make use of this valuable resource. This directory contains information on many of the systems currently inventoried on the SISP. They were selected somewhat subjectively based on possible interest to users, planners, and systems developers. They are sorted and indexed by system name within agency. A second index in the back is sorted by system name only. Description, sources, produced materials, contact and record number are shown exactly as they appear in the SISP system. The SISP can provide additional information about these and other systems of other state agencies. Subject indexes are available and other methods of selecting and sorting are possible. Information is available in printed form or on floppy disks. All state agencies are required by law to keep their data in the SISP current.

This document represents Mn/DOT's commitment and successes in, the area of automated systems. It will serve as a valuable resource for legislators, state agencies and others as well as for our own use. The continued success of this document depends on the quality of the information it contains. Therefore all of us who are related to these systems in any way should be concerned with the accuracy of the information about the systems we are familiar with. Please browse the document for, inaccuracies and omissions. Changes and suggestions should be reported in the. manner described in the Introduction. Also please take the time just to see what types of data processing projects currently exist in our department. We should take pride in these accomplishments. Thank you in advance for your usual effort and cooperation in making this a success.

The Transportation Information System was developed as a tool to perform specific tasks relating to transportation data. Since its initial development, TIS has undergone many modifications and additions in order to meet new or changing demands. TIS has succeeded in meeting its original goals and in satisfying many new demands. But as new demands continue to mount, certain deficiencies in TIS are becoming apparent which will cause increasing difficulties in the future. Because system documentation and standards for system maintenance are inadequate, modifications and corrections to the system are time consuming and difficult. Therefore, some users have created their own data files and stand-alone systems, thus duplicating effort and creating data redundancy and inaccuracy. Because of the deficiencies of TIS, a Feasibility Study was initiated to research and analyze various alternative methods of resolving the shortcomings of TIS.