custom applications knowledge centers products ontrac corporate contact us  


 
 
OnTRAC2 Volume FAQS You are in: TRIMAP > products > ontrac > volume faqs

  1. What does it include?
  2. Is TRIMAP committed to continuing development?
  3. Does TRIMAP staff have expertise in the transportation field?
  4. What form does the data have to be in?
  5. What about other data?
  6. How is all this information made manageable?
  7. How are estimates of intersection counts derived?

  1. What does it include?

    This solution is actually comprised of two components. The first is a client server application written in Delphi. It is used to derive, for a user specified year, estimates of traffic volume for every link and node in a road network (AADT for segments and approach AADT for intersections). Data used by the application can be resident in any SQL 92 compliant database, OR, the applicable information can be accessed from a directory where raw text files representing typical turning movement data are stored (one file per count).

    The key to our application is that relationships are defined that associate sources of traffic count data with specific links and nodes represented in a road network. One way or another, each link in the network contains a reference to a source of traffic count data. To complete the estimating process, user-defined business rules are accessed to define how specific counts should be factored up to AADT counts (i.e. based of time intervals, day of week and month of year factors). Flags can also be set to determine whether a specific count is suitable for estimating traffic counts (the count may be a special 5 hour count that is really not applicable when it comes to projecting an AADT value).

    The second component of our solution deals with the actual management of traffic volume data. This web-based component is a XML / Java-based application that uses Oracle as the RDBMS. Its purpose is to facilitate the import typical traffic volume data (i.e. turning movement data), to enable the direct data entry of some traffic count data (i.e. tube-based ATR data), to provide the ability for end users to interrogate and complete a quality assurance process before specific count data is actually used, and to provide a simple interface that allows users to find and view details of specific counts or create specific reports based on this data.
    >> top

  2. Is TRIMAP committed to continuing development?

    We are committed to the ongoing development of the OnTRAC suite of products including both the collision and traffic volume modules. These products are in use by traffic agencies throughout Ontario, in the Province of Manitoba and soon, in the City of Calgary. Since they were brought to the market in 1998, we have embarked on continuous improvements of our products and are extremely excited about the potential of the current integrated web-based versions on OnTRAC.

    We believe that our solutions are cost effective when it comes to comparing in-house systems that are truly “one-off” applications. While we have recognized that all of our current clients deal with both collision and traffic volume data in slightly different ways, the differences are usually negligible. We have found that the needs of new customers can generally be met by configuring the existing application or making minor changes that leverage existing functionality.
    >> top

  3. Does TRIMAP staff have expertise in the transportation field?

    While TRIMAP is an information technology-based company, we have substantial expertise and knowledge of transportation and traffic issues. Besides our involvement in development of the OnTRAC products, both founders of TRIMAP Communications are transportation engineers. Dr. Dalkie received his doctorate based on work completed in the transportation field and was the manager of transportation planning for a regional municipality in the Greater Toronto Area. Mr. Stephen Karakatsanis has several years experience with the Toronto Transit Commission, GO Transit and other transport-related agencies. Dr. Richard Soberman, a TRIMAP senior associate, was formerly Dean of Civil Engineering at the University of Toronto and has been actively involved in transportation engineering and planning for over 40 years. Recently, the City of Toronto retained the services of Dr. Soberman, through TRIMAP, to complete the transportation component of the City’s new Official Plan.
    >> top

  4. What form does the data have to be in?

    While our data model is still subject to new revisions, we have designed our application to simplify the process of moving data from a variety of sources into an applicable database environment. An important feature or our application is that a product we developed to process telephone-based transaction data handles the actual import of collision data. This product, roBott, is an XML-based work-flow engine that can readily be configured to read specific files, parse the data and then insert applicable information into a complex database structure in any SQL 92 compliant database.
    >> top

  5. What about other data?

    No problem, this is what the roBott was designed to do. More importantly, as your needs evolve, you can make the changes by yourself (more or less of course!). Obviously, your database may need to revised with the assistance of one of your Oracle dba’s, but very little would have to be done to the roBott to move new data around.
    >> top

  6. How is all this information made manageable?

    One of the issues users typically face, is that they quickly amass large amounts of data (particularly if automated intersection count data is considered). Based on our current experience, an effective approach has been to publish summary data that is readily accessible by end users while archiving raw data. For example, you could publish peak period data or factored summaries while not worrying about managing all data that describes information at a 15-minute interval.
    >> top

  7. How are estimates of intersection counts derived?

    Our process involves taking all known applicable counts (turning movements or tube counts) and estimating an AADT value for each road segment. Since the application is a map-driven application, all links will be referenced to one or more sources of volume data. Once link traffic volumes are determined, approach AADT estimates are made for each intersection. This implies that while you may have a TMC at an intersection, the estimate of the approach AADT may or may not be derived solely from that count – all other applicable counts associated with the segments that make up that intersection would be considered. Notwithstanding creation of an overall AADT, all specific individual counts can be accessed and could be used to generate reports such as a traffic signal warrant report.
    >> top



accident analysis, accident investigation, accident reconstruction, accident record, arcview, asset management, autocad map, automated mapping, collision analysis, collision diagram, collision investigation, collision reconstruction, collision record, crash record, crime, damage, development, diagramming software, digital map, eai, electronic map, ems, esri, fatal, fatalities, fatality, fleet, gba master series, geographic information system, geomedia, gis, hansen, highway, highway safety, hsa, ims, infrastructure management, injury, intelligent map, intergraph, intersection, investigate, investigation, investigators, itx stanley, law enforcement, magic, mapinfo, mapobjects, mapping, mapscenes, mapx, mj harden, mv, ontrac, ontrac2, orthophoto, orthophotos, police software, policing, psi, public safety, public works, reconstruction, rqc, sheriff, sheriffs, spatial analysis, spatial attributes, spatial data, svg, traffic accident, traffic investigation software, traffic safety, transportation, trimap, truck, vector graphics, vehicle