CHAPTER 14

LinkerAT: Guidelines and Demonstration for Implementation of an Improved Conflation and Geodata Reference Process

This chapter provides information on installing and using LinkerAT as well as details about the creation and methodology of this tool. Developed as part of NCHRP Project 08-119, LinkerAT is a prototype public, open-source software tool intended for transportation agencies and their partners to use to create and establish specific data cross-references between a source dataset and a target dataset. LinkerAT addresses the problem of associating network linkages between physical locations (e.g., roads), other transportation modes (e.g., railroads), pipelines, and communication links.

LinkerAT is a JavaScript program designed to help cross-reference different street network maps. Software, documentation, and example datasets for LinkerAT are in the public domain and can be downloaded for free from the NCHRP 08-119 website (https://data.transportationops.org/linkerat-guidance-and-demonstration-improved-conflation-and-geodata-reference-process). LinkerAT includes all necessary libraries and instructions to run the program on a standard Windows computer. No special libraries or proprietary software are required.

LinkerAT was designed to address the problem of relating the Regional Integrated Transportation Information System (RITIS)/Traffic Message Channel (TMC) network and the All Roads Network of Linear Referenced Data (ARNOLD). These network datasets describe roads and connections in the United States for all 50 states and the District of Columbia. The RITIS/TMC network is used to segment and report real-time vehicle speed data. ARNOLD is a specification used to inventory road configurations and conditions by roadway segment for each state’s roadway network. ARNOLD serves as the mapping foundation of the national Highway Performance Monitoring System (HPMS). Because of the different purposes of the RITIS/TMC network and ARNOLD, segmentation of the networks and representation of network features often do not align. LinkerAT uses a series of algorithms so that each successive program run builds program knowledge to resolve deviation between network datasets. Additional background details are discussed later in this chapter under “More About LinkerAT.”

Implementation

LinkerAT can be modified for use between state, regional, and local transportation agencies. Implementation and customization of LinkerAT requires (1) knowledge of principles of geographic information systems (GIS) and associated tools and (2) proficiency in JavaScript software development. The implementation steps below, for both a trial run and state-specific implementation processes, are based on the case study of prototyping for the Colorado Department of Transportation (CDOT).

Trial Run: Access, Install, and Run LinkerAT

A trial run is recommended to enable the user to effectively apply and understand LinkerAT processes and advantages.

Access

• Visit “LinkerAT: Guidance and Demonstration for Improved Conflation and Geodata Reference Process” on the NCHRP 08-119 website (https://data.transportationops.org/linkerat-guidance-and-demonstration-improved-conflation-and-geodata-reference-process).
• Download the following:
  • LinkerAT software (LinkerAT.zip).
  • Trial RITIS/TMC and ARNOLD datasets from Colorado and Arkansas. These datasets are provided in two zipped folders called LinkerAT(ARKDB).zip and LinkerAT(CODB).zip.

Install and Update

• Extract the contents of the zipped folders to the root directory operating system (e.g., C:) (Windows 10 or higher recommended). This creates two separate folder trees: LinkerAT and ARNOLD-RITIS. The trees include all necessary subfolders to trial run the program. Figure 14-1 shows an image of the installed folder trees for ARNOLD-RITIS (left) and LinkerAT (right).

Update System Parameters

LinkerAT requires an update to system parameters to update settings on your machine. (This may be something your IT support staff has to approve.) To perform the update,

• Right-click on file C:\LinkerAT\Scripts\CMD\LinkerAT.reg and select “Merge.”

Run

• Type the local file path C:\LinkerAT\Pages\LinkerAT.htm into the browser bar.
  • Alternatively, in My Documents, open the LinkerAT folder:
    • Open the subfolder pages.
    • Double-click on the LinkerAT html page (this automatically opens LinkerAT software in your default web browser).

• If you wish to run LinkerAT from a different web browser, right-click on the LinkerAT html page and select the desired browser. [Note: LinkerAT requires Version 9 or later of Internet Explorer or Microsoft Edge (using Internet Explorer mode) because it uses ActiveX controls.]
• This displays the current program settings and the “Run LinkerAT” button, as well as buttons to load and save custom settings, shown in Figure 14-2.
• Verify the settings and click the “Run LinkerAT” button.
• Two windows provide up-to-the-minute information on run progress and a summary of problems in resolved route tracing. These windows, shown in Figure 14-3, can be disabled in the Settings page. Refer to the next section, “State-Specific Processes,” for guidelines about adjusting model settings and parameters.

State-Specific Processes

Applying LinkerAT to local networks requires additional input from the user in the form of

• Modifying the scripts to add new road IDs and coding schema: LinkerAT relies on each state’s coding schema to determine flow direction of candidate links. Though there may be some similarities, each state’s coding schema is different. The process of modifying the scripts has been simplified to isolating the handling of flow direction to a limited number of functions and embedding the state-specific logic in a simple “if . . . else” block based on the

• parameter of the state name (e.g., “Colorado”). This isolates the state-specific code to a user-specified option.
• Using supplemental state file inputs based on state-specific considerations: In the case of Colorado, a route-naming file that translates the coded route ID to associated street names and highway numbers was required as input. The logic for implementing this type of customization is available in the software.
• Developing state-specific handlers: These code blocks are designed to be augmented and updated to address state-specific conventions. A framework model has been implemented to guide development of state-specific handlers. Details of this framework model can be found under “State-Specific Handlers” below.

Access and Preparation

• Download the following:
  • LinkerAT software (LinkerAT.zip).
  • Necessary network data from RITIS/TMC and ARNOLD. [RITIS/TMC data must be accessed through an account with RITIS (https://npmrds.ritis.org/analytics/shapefiles). ARNOLD data from other states are available from FHWA (https://www.fhwa.dot.gov/policyinformation/tables/performancenetwork/).]
• Convert RITIS/TMC and ARNOLD datasets to GeoJSON-compliant format. [Original datasets from https://ritis.org (University of Maryland) and the FHWA website are in shapefile format. To support LinkerAT and provide a fully open-source software implementation, LinkerAT requires that the networks be in GeoJSON format.]
  • QGIS, a public domain and freeware software, can convert the datasets to GeoJSON.

Install and Customize

• Extract the contents of the zipped folders to the root directory operating system (e.g., C:) (Windows 10 or higher recommended).
• This creates two separate folder trees: LinkerAT and ARNOLD-RITIS.
  • For new states, the tree under ARNOLD-RITIS must be supplemented with a new branch for that state. Figure 14-1 shows an image of the installed folder trees for ARNOLD-RITIS (left) and LinkerAT (right).

To run LinkerAT for additional states or with different networks, the user must customize LinkerAT.

Input Project-Specific Rules. Although LinkerAT is designed to accommodate different source–target definitions, the purpose and design are optimized for datasets like RITIS/TMC and ARNOLD. Therefore, understanding the roles and relationships between links in the network requires a flexible approach.

LinkerAT incorporates several software entry points where specific coding can be added or modified to address specific state-level assumptions and conventions. These entry points include inputting special supplemental files and data, adjusting algorithms to account for local information handling, and measuring and defining network link relationships.

Modify LinkerAT Settings. It is recommended that the user first run LinkerAT with the default settings, review the output results, and then modify settings. Most of the settings in LinkerAT control the behavior of the software in the search for qualified links and nodes. These are mainly the search radius and distance separation measures.

Figure 14-4 provides a view of the available settings. In the active program, hovering over the question mark symbol (?) displays a definition of the intended use. For specific network geographies (e.g., states), some settings may need to be changed to address local conditions.

Settings can be modified by doing either of the following:

• Modify directly in the settings file with a text editor.
• Modify in the separate web browser–based settings editor.

Preprocess Incoming Network Data. LinkerAT’s main processing loop takes each source link as input and attempts to define a route between a candidate target start link and a candidate target end link.

• Audit one-way ARNOLD segments to ensure that the GeoJSON structure is consistent with the represented traffic flow direction.
  • As RITIS/TMC segments, regardless of whether they describe one-way or two-way road operations, represent each direction of travel separately, matching those segments to one-way ARNOLD segments requires ensuring that travel direction for corresponding segments is the same. This is complicated by the fact that ARNOLD coding is sometimes done by inventorying segments (identifying their topological direction) in the direction opposite their flow or travel direction. To match the input source link to the corresponding target segments, these segments must have their inventory direction reversed, based on the road naming and identification coding used in each state.
  • LinkerAT achieves this by examining the road/corridor identifiers and processing those data to obtain the likely flow direction represented. This direction is compared with the inventory direction, and a report is generated that identifies target segments likely to have inconsistent inventory flow directional coding. These segments can then be reviewed to verify flow direction and flagged as appropriate. Checking inventory versus flow direction is optional. This feature can be turned off once the user is satisfied with the network configuration. If the user wishes to restart processing with the updated network, an option is available to save changes to a new base file after this process.
• Customize input files for application and read previous “cross-reference” list.
  • LinkerAT builds GeoJSON objects from the input maps. Part of this process involves customizing and adding attributes to the maps required by LinkerAT as well as performing any necessary reformatting of the input data. Before the very first run is performed, the attributes added to the objects are predefined in the program. For subsequent software runs, LinkerAT checks whether these attributes already exist in each network. In the LinkerAT Settings Page, under “Other Settings,” there is an option to allow the program to remember attributes from previous runs.
  • A strength of the LinkerAT model is its ability to recognize and reuse previously established route cross-references. On subsequent runs, output files (XID.CSV) from prior runs can be used as input files as a base for the iteration. LinkerAT creates a comma-delimited cross-reference table for the output files (Figure 14-5).

State-Specific Handlers. Coding practices used for target networks vary from state to state. The trial implementation was customized with a series of “code blocks,” which, when identified as such, are specifically used for the CDOT networks. These code blocks can be augmented and updated to address other state, regional, or local conventions.

The following framework model, which guides the development of state-specific handlers, consists of the following components:

• A subfolder structure and series of inclusion files that can be used to input special rules on a state-by-state basis. The main folder for this structure is located under the path \LinkerAT\ Scripts as “StateHandlers.” Under StateHandlers, the following subfolders for each user entry point are provided:
  • StateGlobals—Currently not in use. Designed to address the need for additional JavaScript global variables for state-specific handling.

• GetStateFiles—Called once when initiating the function FillCorridorID. Designed to allow specification of custom inputs.
• FillCorridorID—Controls source and concatenation of incoming data descriptors used to assemble the route Corridor_ID (see the “More on CORRIDOR_IDs” section).
• Check2WayFlow—Returns outcome of check on whether input link is unidirectional or bidirectional.
• CheckAngles—Identifies and uses source and target segment departure angles to test source–target link matches.
• The individual state handler folder (e.g., CheckAngles) provides
  • An “include” file template for each state,
  • A “head” file to be concatenated with the templates at the front,

• A “tail” file to be added to the end, and
• A “command” file (*.BAT), which will create a new version of the function by using the previous three types of files in the StateHandlers folder.

Once changes to the state-specific files for any of the handlers are complete, run each handler command file to create a working copy of the function. For this to be included in LinkerAT, the file must be copied to the \LinkerAT\Scripts folder, and the current version must be overwritten. The resulting version of the handler includes all state-specific customized handlers that are in use. Figure 14-6 shows the StateHandlers folder structure and an example of a specific handler.

More on CORRIDOR_IDs. On the basis of the input characteristics for both the source (RITIS/TMC) and target (ARNOLD) networks, LinkerAT assembles a composite route identifier that attempts to capture the common semantics of links comprising the same route. While components of this composite route identifier are intended to include attributes common to all source or target networks, modifying the components for state-specific implementations may improve solution finding. To modify these components, the user must change the logic that performs the assembly of the CORRIDOR_ID network attribute.

LinkerAT has CORRIDOR_IDs for source and target networks specified as follows:

• Source or TMC ROADNUMBER,
• Source or TMC ROADNAME,
• Source or TMC DIRECTION (N/W/S/E), and
• Source or TMC F_SYSTEM (FHWA Facility Class Code).

Target CORRIDOR_IDs are implementation dependent. While a minimum value is established on the basis of immutable FHWA ARNOLD attributes, the value can be customized depending on individual state coding conventions. The default values are shown below:

• Target or ARNOLD ROUTE_NUMB,
• Target or ARNOLD ROUTE_ID, and
• Target or ARNOLD F_SYSTEM (FHWA Facility Class Code).

Run and Analyze

The user may need to return to the customization steps after completing successive runs of LinkerAT to further define and adjust the program and desired output.

Run. Click the “Run LinkerAT” button on the Settings webpage.

• The settings include a project directory structure with (1) assigned locations and filenames for the input network (e.g., RITIS/TMC and ARNOLD) GeoJSON datasets and (2) locations to store LinkerAT’s outputs.
• A run produces these outputs:
  • A summary of performance in successfully assigning source network (RITIS/TMC) identifiers to target network (ARNOLD) link records.
  • A comprehensive log of route finding to associate target links with source links and whether each effort was successful or resulted in an exception. The log itemizes information about the method used to perform the association and, for exceptions, the type of exceptions encountered. Supplemental steps required to obtain associations are also itemized (e.g., adding target nodes to establish new links matching source link end points). Figure 14-7 shows an excerpt of a LinkerAT standard report. Figure 14-8 shows a sample log of route finding results and exceptions.
  • A separate file (comma-delimited text) listing the chains or route information. There is an entry in this file for each successfully cross-referenced source link that lists the identities of the associated target links for any complete or partial path identified (see Figure 14-5).
  • Codes that identify the outcome of each target route-building effort are added to the “VISIT” field in the source dataset. (A successful visit implies that a solution was previously found for a specific link.) These codes list exceptions encountered by location and type in a map view (e.g., QGIS). An example of using visit outcomes to view reported exceptions for the city of Denver and surrounding area is provided in Figure 14-9.

Analyze. Analyze LinkerAT results and, if needed, return to the customization steps to prepare a follow-up run to possibly address any errors or reported exceptions. The source database is automatically updated with the result code for each source link. This provides a simple tabular and graphic reference for further analysis. Where available, source identifiers (in this case, the “TMC_ID”) are written to corresponding target links.

The route is deemed complete when the route reaches the independently identified target end link. This process continues until all source links have been queried.

LinkerAT incorporates features that help establish source–target correspondences. These include

• Target node generation: If a node is not found on a target start or end link close enough to match the corresponding source node, LinkerAT splits the target link and adds the necessary node. The addition of the node is reported to the user.
• Reverse route tracing: In the case of the current implementation of ARNOLD, many of the target links represent both directions of travel. The source in this case, the RITIS/TMC network, always represents directional segments separately. LinkerAT will revisit unresolved routes and, if the determined route is one direction and the target link coding is two-way (both travel directions on the same links), LinkerAT will reverse trace the defined route to create the source link references for the opposite direction. Exceptions can result from different causes, which include the following:
  • Source/target file coding errors: LinkerAT will not be able to make a match between source and target links where the routes identified are miscoded or links are not properly aligned. It is also possible that identifier coding will be correct but inconsistent for some

connections (e.g., coding conventions that follow geographic or other criteria that change over the length of a route). For these situations, LinkerAT adds a field to the target file database, which allows specification of a different ID specifically for route-finding purposes.

• Settings and tolerances that inhibit route finding:
  • In the case of the ARNOLD dataset as a target (this may or may not be the case for other potential target datasets), there is limited resolution of common locations for different links, and the same location may be referenced as multiple and geographically distinct nodes.
  • The LinkerAT settings implement a fuzzy tolerance model to associate these together. In some areas, the proximity of other nodes could potentially allow their identification as connection candidates. Adjusting the radius and proximity settings will sensitize these settings to local conditions and, potentially, improve route-finding success.

The route-finding process in LinkerAT involves specific criteria and proximity rules to define when target links are candidates to become part of a route. If these criteria are not met, the target link is rejected as a candidate, and LinkerAT uses secondary strategies to attempt to complete the route. When all options are exhausted, if a path of acceptable candidates cannot be found to connect a start link candidate with an end link candidate, path building is terminated, the source link is flagged with an exception, and the program moves to the next source link.

LinkerAT exceptions, along with how each one is handled (noted in parentheses), are as follows:

• No target start link found matching the source (TMC) link “begin segment” (abandon route).
• No target end link found matching the source (TMC) link “tail segment” (save partial route).
• No connection found for current route path (middle link) to usable segment (save partial route).
• Route path follows circular pattern. Reuses previously visited target link (save partial route).
• Path attempts to reuse start node of link as an end node (ignore source link).
• Route path cannot be completed. Maximum links exceeded (abandon route).

Each route-finding operation results in either a complete path or an error condition. A complete path returns the outcome:

• Route complete and source link cross-references written to corresponding target links.

If the result is an error condition, the program completes as much of the route as possible and reports the error. Error outcomes include

• Source–target start correspondence cannot be established (no links cross-referenced).
• Start links identified but no source–target end link found (start link and connected middle links written as partial path).
• Route ends before target end link (start link and connected middle links written as partial path).
• Route returns to used target link (start link and connected middle links written as partial path to location of duplicate link).
• Target start and end links are the same (no links cross-referenced—probable phantom source link).
• Route length exceeds maximum link criteria (no links cross-referenced).

More About LinkerAT

This section provides additional details about the originating problem, the solutions to which LinkerAT contributes, and the methodology of the software.

Problem

Location maps are often developed by different groups, and often linkages (or links) themselves may be represented differently and at different levels of resolution. When an attempt is being made to combine associated information in one network with that of another network, conclusively establishing what represents the corresponding link or links can be a difficult task.

Most commonly, the approach used to make such connections relies on a map matching process called conflation. Conflation involves establishing a direct relationship using spatial proximity between map elements. This process has been used and refined in attempting to relate the network information embedded in the TMC database to more generalized map descriptions such as OpenStreetMap and the federal government product ARNOLD, which supports the HPMS. (The appendix to this chapter provides summary information regarding the datasets and other technical details and links to additional resources and information.)

LinkerAT is not a conflation tool (although LinkerAT outputs can help inform the conflation process). LinkerAT processing focuses on creating and establishing specific data cross-references between a source dataset (e.g., RITIS/TMC data) and a target database (e.g., ARNOLD). Conflation normally involves aligning two networks so that the locations of specific points and the representation of link alignments correspond for use external to those networks.

Solution

LinkerAT represents a new approach to addressing this problem, one that provides a more reliable way to establish the associative relationships alluded to previously while incorporating conflation as a step in processing. LinkerAT addresses the problem of associating networks describing linkages between physical locations (e.g., roads), other transportation modes (e.g., railroads), pipelines, or communication links.

Unlike standard network conflation, which relies solely on geographic matches between points and segments and applies that model for the entire map at one time, LinkerAT’s route-finding process works on source links one by one (Figure 14-10). LinkerAT completes each source link, including both flow directions, individually before moving onto the next source link, which allows multiple target segments to be cross-referenced to a single source link in separate solutions.

The independence of the solution sets provides two significant advantages: (1) when or if the program is restarted, it can use any previous solutions and add new solutions to the set and (2) types of reported errors are specific to a given source segment and can be displayed or reported with that segment. Further adjustment to the program inputs or parameters will only affect those links not successfully visited previously.

Reusability of these solution sets means that, unlike conflation, rerunning the entire process with global changes in settings is not needed to achieve better global convergence. Global changes in settings are normally required by conflation-based processing due to complete reliance on spatial matching methods that affect the entire map. The route-finding method used by LinkerAT allows solutions to be archived, reused, and effectively exploited by storing and recalling them from the source–target route cross-reference table (XID.CSV).

Limitations

While the goal of LinkerAT is to minimize the amount of manual effort and to provide feedback on the process limitations, there currently is no way to completely automate the process. Manual intervention to correct exceptions (i.e., outputs from LinkerAT that let users know the tool cannot complete building the specified route) is inevitable given network coding errors, isolated inconsistencies of coding conventions, and the attempt to use information organized for a different purpose. As LinkerAT is applied to more dissimilar cases involving different coding practices and network descriptions, its broader operational effectiveness will be tested.

Additional Methodology

Some of the methodology of LinkerAT processes and functions is discussed earlier under “State-Specific Processes.” This section includes additional methodology not previously discussed.

The LinkerAT process treats the problem of associating one source link with the associated target link(s) as an independent step (see Figure 14-10). This allows the problem to be solved independently of all unapplied source and target elements and to be revisited only for those elements for which a solution cannot be found.

LinkerAT uses a combination of geographic and thematic cross-referencing to identify how the ARNOLD network represents parallel elements in the RITIS/TMC network. LinkerAT uses a series of algorithms to identify corresponding elements in the source (RITIS/TMC) and target (ARNOLD) networks. The process involves a series of steps or phases executed to maximize the likelihood of a solution. Most of the process is automated while the program runs in the background and tabulates a solution set. As the program runs, it learns more about the network and how elements can be cross-referenced, so multiple program runs are executed sequentially to effectively apply this new knowledge.

For the identified source link, the process can be broken down into three major steps:

1. Identify target start link. After a source start link is chosen, a corresponding target start link is identified by
   • Its proximity to the start node of the source link;
   • The departure angle of the first segment of the source link matching that of the corresponding segment of the target link; and
   • Optionally, when available, cross-referencing the route name of the source link to the target link. (LinkerAT builds a table of these cross-references as they are resolved and uses that table to check for preexisting relationships.)

2. Identify target end link. When the target start link has been identified, the target end link is found by
   • Using its proximity to the end node of the source link and
   • Matching the route name of the target start link.
3. Identify middle or connecting links. Beginning with the end node of target start link, the connecting links between target start and end links is traced by
   • Using its proximity to the end node of the previous link and
   • Matching the route name of the target start link.

Appendix: Terms and Concepts

LinkerAT operation relies on outside data sources and standards. This appendix describes those resources and provides links to additional information.

All Roads Network of Linear Referenced Data

The All Roads Network of Linear Referenced Data (ARNOLD) was used as the target database for this project. ARNOLD was developed as a resource by FHWA to support state-by-state road mapping data used to report highway performance. The basis of the ARNOLD network is information regarding the linear referencing systems (LRS) used by states to identify mile-posted sections of roadways with common characteristics (e.g., number of traffic lanes). Performance reporting requirements dictate that the network include all publicly funded roads. Since ARNOLD is based on the LRS, it does not specifically address the problem of identifying road junctions. Identifying these junctions was one of the major challenges involved in implementing the LinkerAT model.

Currently, ARNOLD networks can be downloaded directly from the web on a state-by-state basis for specified years (2017 data as of October 2024) (https://www.fhwa.dot.gov/policyinformation/tables/performancenetwork/). The ARNOLD Reference Manual is online (https://highways.dot.gov/safety/data-analysis-tools/rsdp/rsdp-tools/arnold-reference-manual).

Code Blocks

Code blocks are used to describe a programming practice to provide implementation-specific processes in the context of a more generalized program framework. In the case of LinkerAT, this approach implements rules for (1) interpretation for specific states and (2) either input implementation of specific data or decoding. At the programming level, this translates to identifying when and where such data and rules are needed and then conditionally applying them to a specific state implementation. This approach makes it comparatively easy to customize the software to support local (e.g., state-level) data standards and practices. A short example of the required source code is shown in Figure 14A-1.

GeoJSON

GeoJSON is an open industry standard for storing (serializing) and managing geographic mapping data. It is based on the JSON (JavaScript Object Notation) standard, which provides a model for storing and describing database objects. Many of the open-source tools used to analyze and process geographic information rely on GeoJSON to input and organize their information and processes. For LinkerAT, an open-source geoprocessing library (Turf.js, available at https://turfjs.org/) that is based on GeoJSON was used to analyze node and link relationships. GeoJSON is the standard format used for LinkerAT inputs and outputs and is an open software industry standard. For more information about GeoJSON and its characteristics, go to https://datatracker.ietf.org/doc/html/rfc7946.

OpenStreetMap

OpenStreetMap is a crowd-sourced extensive global database—stored as an Extensible Markup Language (XML) file—that contains far more information than just the road network. Its data model organizes features into nodes (points), ways (lines), and relations (rules that organize nodes and ways), each of which has associated attribute data in the form of key/value pairs. OpenStreetMap has been used as a map base for several previous conflation projects. While similar in many ways to ARNOLD, both its structure and network coverages are different. It is mentioned here to provide another example of types of map inputs used in conflation-related projects. Additional information about and downloads of OpenStreetMap products are available from the OpenStreetMap website (https://www.openstreetmap.org/).

QGIS

QGIS (https://qgis.org/) is a publicly available and maintained desktop software product that supports an extensive array of geographic functions and formats. For LinkerAT, it was used (1) as a file converter to translate shapefiles (a proprietary map data format) to GeoJSON and (2) as a GeoJSON-based map viewer during development. QGIS is available as freeware and can be customized as a tool to edit and view LinkerAT map inputs and outputs.

Regional Integrated Transportation Information System

Regional Integrated Transportation Information System (RITIS) is a clearinghouse for big data resources and is primarily used by public agencies. RITIS is maintained by at the University of Maryland Center for Advanced Transportation Technology (CATT) Laboratory. In addition to geographic datasets, RITIS resources include connected vehicle and other sensor data linked to the TMC network. Access to RITIS is limited and provided only to subscribing public agencies and their contractors. Additional information about RITIS and its products is available at https://ritis.org/.

Traffic Message Channel

Traffic Message Channel (TMC) codes were originally developed to communicate traffic information to in-vehicle navigation systems via FM radio. TMC location points typically represent key intersections along a road network and are named on the basis of a unique country identifier, table code, and location code (e.g., 110+04110). Segment-level TMC geospatial road networks are created by connecting TMC location nodes.

The TMCs were developed and are maintained by the international Traveler Information Services Association (TISA, https://tisa.org/) and include an extensive range of network facility types. Only a small subset of the TMC network is used in RITIS, and it is this subset that serves as input to the current implementation of LinkerAT. Additional information regarding structure and elements is available from the TISA website.