4.5.4 Development of Special Transportation Planning and Engineering Analysis Tools and Concepts

One of the concerns with implementing an ADUS is the ease and effectiveness with which users can retrieve data and create information. This data archive capability should help users in their analysis needs as well as facilitate them addressing their responsibilities. This section focuses more on software and ways in which the CHART II data archive will be used and applied. This is in contrast to the previous section that was focused on communications integration and hardware needs. This section also responds to the CHART II Software Functional Requirements Document (RFP) prepared by MDSHA that anticipated the need for the proposed design to describe and specify the (1) graphically presented, pre-defined queries for access to the CHART data archive, (2) procedures for ad-hoc queries from a SQL prompt, (3) access for users of the MDOT Enterprise Network, as well as (4) the Graphical User Interface (GUI) for exporting of specified map data to the WWW server.

This section also identifies other desirable features for retrieval of data and information from the CHART data archive by a broader range of stakeholder users. Within the constraints of time and budget, a number of these additional desirable features are incorporated in our design. Depending upon the final review and negotiations, a set of remaining data archive user interface features will be prepared by the CSC/PBFI Team during the implementation phase of CHART II. It would also be important to involve the ADWG in that process so that the full set of interface features directly responds to user needs, as defined by the users.

Such interface procedures have been divided into two main classes for purposes of discussion. The first class is oriented to transportation planning and systems management users and activities. The second class of interface procedures is more oriented to traffic engineering and operations management users and activities. From a system design perspective, however, there will only be one interface approach that contains both orientations. Potential Transportation Planning and System Management Tools

There are a number of transportation planning related agencies or units within larger agencies that are the stakeholders and anticipated users of the CHART II data archive. Some stakeholders need the data for analyzing regional plans, planning processes, or techniques, such as validation of a travel forecasting model. Other transportation planning stakeholders have more of a system management need, such as (a) monitoring trends in congestion as part of Congestion Management System (CMS) planning by MWCOG or BMC, or (b) as part of the tracking of overall Performance Measures by the MDSHA OPPE staff. Other stakeholders, primarily at local planning agencies with responsibilities for regulating development, have a need that stems from the administration of their jurisdiction’s Adequate Public Facilities Ordinances. Those ordinances usually require an applicant for a subdivision to prepare a Transportation Impact Study, which uses recent or current traffic counts and/or link volumes. That information is then used in calculations of Level of Service (LOS) for critical intersections and/or roadway links in the vicinity of the proposed land development project, which is a key indicator of the adequacy of the transportation facilities to serve the proposed development.

This listing of stakeholder needs is meant to be illustrative and not exhaustive. The draft report for the ADUS presents a more comprehensive set of needs. That set may still be modified, and the latest version will be used as a check-point in the implementation phase of CHART II. The data archive and retrieval features are being designed to meet such anticipated planning analysis, system management monitoring, and regulatory data and information needs. An important aspect to account for in the CHART II design, is that while these needs are not real-time in nature, they are nevertheless time sensitive. As such, all data elements will have a time stamp associated with them. Most of the interest in the data by these stakeholders stems from how the data and measures of performance vary in one or more of the following dimensions:

It is expected that most users of the data archive will want to access the data and organize the resulting information using a Windows, menu oriented approach, including a number of pre-defined GUIs. That type of approach and other means for users to access the data archive are described next. Access to the CHART II Data Archive Using a "Motion Maps" Approach

Access to the data archive will be possible from any of the workstations that are part of the CHART II architecture and are being designed to be similar in look and functionality to the GUI for system operators. This will facilitate the use of the data archive by the operators who may have needs to access the data archive while they are on the system. The prototype of the GUI for a system operator User’s View that has been prepared is a map based interface with imbedded Object Oriented linkages. There are many layers of data from detectors as well as for icons representing various types of data or information, such as an icon for confirmed incidents, which are available for selection by the operator.

The latter is done in a fashion similar to a Windows file manager by having a nested tree of choices in the left-side of the overall Window screen. The operators working map is on the right-side and as many as six more Window Dialog Boxes could be opened to be able to concurrently apply or use various functions. The geographic extent of the map, and thus its scale-size, can be selected by the operator. The operator can also select the level of network detail as well as other layers of information that are useful for the particular operation being performed. For purposes of readability, attention needs to be paid to line width as operators change scale.

One human factors challenge for operators is to avoid using too many layers or inappropriate scales so as not to clutter the graphic or have an information overload, which could reduce the operator’s ability to detect change or to perceive important patterns. While different operators have different abilities and some can work effectively with more concurrent information packed on a screen, there still becomes a point where the data and information being represented on the screen becomes unreadable.

For an archived data user, there will be the same basic arrangements with the left-side being used to specify which data is being accessed, and the right-side being used to specify from what area or network the data is being gathered. One Dialog Box or menu would be used to set: (a) the time interval, i.e. for a particular month, and (b) time increments, such as minute-by-minute,15 minute, hourly, or daily. These selections are then used in the processing of the data in the archive and in producing map oriented summaries of the data as well as data files for exporting. Other menu choices and/or Dialog Boxes could let users select items such as: (1) route and/or corridor summaries, i.e. a corridor associated with a Major Investment Study (MIS), (2) classes in a functional classification system, i.e. freeways, major highways, arterial highways, collector and minor arterial highways, or (3) classes in an administrative classification system, i.e. National Highway System roads with transit routes

The archived data users face a human factors challenge similar, but more daunting than that of the operators when the results of their query for data gets reported back to them. Unlike the operators, the data archive users will generally want to deal with not just current, real-time conditions, but more likely with repetitive data sets over a particular time period, and perhaps with a particular frequency or pattern of repeats, i.e. the peak hour every Friday afternoon for a whole year. If the data was only to be reported back as electronic files in organized databases or spreadsheets, then the users will have the challenge of sifting and sorting through a very voluminous amount of data in order to mine out the good nuggets of information they may be seeking. In some instances some archived data users, "power users" so to speak, will want electronic files in such formats and will have analytic systems to handle this challenge.

Other less experienced users, on the other hand, will want a graphically oriented approach to help them sift and sort through the result of their data query. Such users face the added dilemma of voluminous data but also the need to avoid the situation faced by the operators of excess clutter and information overload on the graphic representation. Unlike the operators, however, it will be more difficult for these less experienced archived data users to query in an iterative fashion until they find a workable and understandable set of results.

To address these human factors challenges for data archive users, we have built into our CHART II design the concept developed by Dr. Robert M. Winick, one of the subcontractors on the CSC/PBFI Team, which he has been developing under the name of "Motion Maps" (Trademark pending). In the implementation phase of CHART II, the CSC/PBFI Team is proposing to use Dr. Winick’s company, Motion Maps, LLC, as a subcontractor to develop and apply further enhancements to the data archive and retrieval process as well as to incorporate various additional functionality into the operating system of CHART II.

The proposed solution to the archived data users dilemma is to organize graphically presented results of the data query into files and associated graphics that would be the type of graphic that an operator would see in current time. Thus, a step in the data query process would be for each user to select an appropriate "base map", that will be used to display the results of their query. The user may also have the option of using a pre-defined set of colors for certain types of data, such as speed ranges. There may also be an option to let the user select a different set of ranges for certain types of data, and also to select color correspondences.

Other options provide for band-width plots for the line representing a network link, where the width of the line is directly proportional to the data, such as volume, or generally proportional with a fixed set of line widths corresponding to a range of values for a variable. The archived data user would first need to fix on a workable base map, with appropriate options and a small sample of the data being sought, before going through the whole data query. When the user gets to the step of the full query, the results will be reported back in a time series set of files, which can then be viewed by the user scrolling through a series of maps. Graphically Presented Pre-defined Queries

A set of pre-defined queries have been developed in the CHART II design. They, and possibly other pre-defined queries, will be finalized during the implementation phase. The current set of pre-defined user interface queries for users of the data archive include the following:

In addition to pre-defined queries, the system will allow users to query the archive database using the SQL prompt. This function will allow users to access data on an as needed basis. Two examples of ad hoc queries include:

-- Permanent Count Station Polling - queries of the permanent count station data other than the pre-defined times

-- Queries of data collected from detectors other than those used for permanent counts (i.e. intersection, as available)

-- Features for Users on the MDSHA Enterprise LAN

The potential users of the CHART II archive data who are connected via the MDOT Enterprise network, will be also be able to access the archive data database and perform the ad hoc queries of the database, or select from the pre-defined list of possible queries. The full set of features available to users on the MDSHA Enterprise LAN will be fully defined at a later stage.

As mentioned earlier, some of the potential users of the archive data will only be able to access the CHART system data via the Internet. Based on data that is made available by MDSHA to the WWW server, and the rights assigned to the user, certain features of the system may be available to the user on the Internet. For example, users may be able to perform queries on a limited set of data that is made available to the Internet users. Potential Transportation Engineering and Operations Management Tools

In addition to the transportation planning and system management tools, the CHART II system will have several transportation engineering and operations management tools that are based on having the archived data. The archive data database will be in such a format that users will be able to query the database to obtain a data file that can be used off-line to perform a variety of transportation engineering and operations analysis. Some of these analysis functions include the following: