Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 46
46
version in the series, which was published in 1998 in collab- BTS with data support from a large number of agencies.
oration with Canada and Mexico (121). NORTAD contained BTS collects data that those agencies produce and/or main-
updated NTAD datasets, border crossings, and datasets depict- tain, reprocesses the data into a central repository, and
ing Canadian and Mexican transportation infrastructure then makes the data available to users. This approach takes
facilities. advantage of existing resources at individual data produc-
Early NTAD versions followed an American Standard Code ers while avoiding data collection and data processing
for Information Interchange (ASCII) fixed-record-length for- redundancy. BTS's coordination role helps to improve the
mat that included six distinct record types, as follows (121): availability and standardization of critical transportation
data and metadata.
1. Link (.lnk file extension); · Develop spatial data programs that use industry stan-
2. Node (.nod file extension); dards. Originally, NTAD used an ASCII fixed-record-length
3. Point (.pnt file extension); format. However, modern encoding schemes such as
4. Area (.are file extension); Unicode started replacing the ASCII format. In addition,
5. Geography (.geo file extension), which contains shape infor- although data conversion tools to enable the conversion of
mation for network links and area boundaries; and NTAD data to other file formats were available, in practice,
6. Attribute (.txx file extensions, e.g., .t01, .t02, and .t03). the ESRI shapefile format became a de facto standard. As a
result, since the early 2000s, BTS has published NTAD in
Combinations of different record types defined the geom- this format.
etry, topology, and attributes of point, network, and area fea- The advantage of using a de facto standard such as the
ture types. BTS made these file formats available to GIS ven- ESRI shapefile format is that this format is widely used,
dors on a temporary basis to facilitate the development of data which facilitates data exchange. The disadvantage is that
conversion software tools. In practice, although BTS intended the shapefile format is an old data format that ESRI no
to migrate NTAD to the federal Spatial Data Transfer Standard longer maintains (although ESRI GIS software applica-
(SDTS), the ESRI shapefile format became a de facto standard. tions provide shapefile format backward compatibility).
As a result, since the early 2000s, BTS has published NTAD in With the introduction of ArcGIS 8 in 1999, ESRI started
this format. It is also worth noting that, although ASCII is still using "geodatabases" to store geographic datasets. A geo-
in use, it is quickly being replaced by more modern encoding database could be a "personal geodatabase" (in Microsoft®
schemes such as Unicode. Access® format) or an "ArcSDETM geodatabase" (with the
A number of agencies contribute data to NTAD, includ- data stored in a relational database such as Oracle®,
ing BEA, FAA, FHWA, FMCSA, FRA, FTA, the U.S. Census Microsoft Structured Query Language [SQL] Server®, IBM®
DB2®, or IBM Informix®) (124). Recently, ESRI introduced
Bureau, and USACE (Table 7). BTS collects data from these
a "file geodatabase" format to address the file size limita-
participating agencies and then processes and publishes the data
tions of personal databases (Access files cannot exceed
within NTAD. Data gathering for NTAD typically starts in
2 gigabytes in size). Although the use of geodatabases is
November of each year. In general, data creation, maintenance,
increasing, at this point it is not clear to what degree federal
update, spatial positional accuracy and resolution, and quality
agencies have started to require their use for data exchange
control responsibilities remain with the data source agencies.
purposes.
Depending on data format, quality, and completeness, BTS
processes data by checking spatial and attribute data character-
istics, inserting additional attribute data, and recompiling meta- General Observations
data using the FGDC metadata standard (122). Most data pro- and Lessons Learned
cessing takes place in an ESRI ArcGISTM environment. The previous sections included a summary of data sources,
systems, and architectures relevant to the freight community.
Lessons Learned Table 1 provides a listing of the freight data sources, systems,
and architectures reviewed, whereas Appendix A of the con-
NTAD is a popular data series that remains an important tractor's final report (available on the project web page)
program within BTS and RITA, along with the operation of the includes a detailed description of each data source, system, or
FGDC transportation subcommittee (123). Budgetary changes architecture. Although not comprehensive, the review pro-
have forced the agency to cut back other GIS programs. vides a sample of the typical data sources, systems, and archi-
Lessons learned in connection with the development, evo- tectures that could be included in a national freight data
lution, and maintenance of NTAD follow: architecture, as well as any potential implementations that
could derive from that data architecture.
· Implement interagency data exchange programs with In general, the material in Appendix A describes the cur-
centralized data coordination. NTAD is a product led by rent status and characteristics of the data sources, systems,
OCR for page 47
47
and architectures reviewed. For the research, it also was impor- portation aspects or components (see Chapters 3 and 4 for a
tant to learn about the process, institutional arrangements, more detailed discussion of those aspects and components).
and challenges associated with the development and mainte- From this perspective, all of the systems and architectures in
nance of the systems, as well as any strategies that have been this report should be included at some level in the design of a
deployed to address challenges and other data integration national freight data architecture if this data architecture is
issues, such as data quality, timeliness, and proprietary and indeed designed to address the needs of both public and pri-
privacy concerns. Given the large number of data sources, sys- vate decisionmakers not just at the national level, but also at
tems, and architectures uncovered during the literature search the state and local levels.
(49 according to Table 1), it was not practical to conduct a However, identifying which data sources, systems, and
comprehensive review of historical developments for all of architectures to include in a national freight data architecture
them. However, a few systems and architectures in Table 1 depends to a large degree on the vision that is laid out for this
were of interest because of the processes that led to their devel- data architecture. As Chapter 4 describes in more detail, it is
opment (e.g., in the form of issues, motivations, challenges, possible to outline a number of competing implementation
legislative efforts, and implemented strategies). Lessons learned alternatives, some of them more comprehensive and ambi-
from those processes can provide valuable information for, tious in scope than others. For example, a freight data archi-
and help to minimize the cost of, the development and imple- tecture that only focuses on commodity flow aspects for plan-
mentation of a national freight data architecture. ning purposes at the national level requires data sources,
The sample of systems and architectures selected for the systems, and architectures that are both commodity-related
detailed historical analysis covered a wide spectrum of topics and relevant at the national level. By comparison, a freight
related to freight transportation and included the following: data architecture that includes commodity, transportation
network, vehicle, and safety aspects to address the needs of
· ACE/ITDS, federal and state governments would require the inclusion of
· Carload Waybill Sample, a larger number of finer resolution data sources, systems, and
· CFS, architectures. Likewise, a freight data architecture that includes
· EDI standards, real-time supply chain data from the private sector would
· FAF, require conducting an analysis of the risks the private sector
· HPMS, would assume if it shares sensitive and/or confidential data
· NIPAs, elements that could undermine its competitive position and
· National ITS Architecture, decisionmaking process.
· NSDI, and Chapter 4 addresses different implementation alternatives
· NTAD. that may be possible for a national freight data architecture.
However, a summarized list of lessons learned from all of
For this sample of systems and architectures, the analysis the systems and architectures reviewed is appropriate here
covered several topics, including the following: because many of the lessons learned are sufficiently generic
and, consequently, could be used to guide the development
· Purpose and intended benefits; and implementation of any freight data architecture, regard-
· Content; less of implementation level. The summarized list of lessons
· Institutional arrangements used for developing and main- learned follows:
taining the system or architecture;
· Challenges and issues faced in creating and maintaining · Develop systems that are relevant to stakeholders, include
the architecture or system; adequate stakeholder participation, and provide incentives
· Strategies and methods for dealing with data integration to encourage participation, particularly in the case of state
issues, such as data quality, timeliness, and proprietary and and local entities (ACE/ITDS, NSDI);
privacy concerns; · Clearly define expected outcomes and development and
· Adaptability to serve evolving purposes and data sources; coordination plan (ACE/ITDS);
and · Articulate programs well; provide clear, uniform guidance;
· Assessment of how well the system or architecture works and provide good documentation (Carload Waybill Sample,
in the form of lessons learned. NSDI);
· Develop applications that rely on widely used data standards
In general, all of the systems and architectures reviewed in (EDI standards, National ITS Architecture, NSDI);
this report (including those described in detail in this chap- · Develop and compare candidate architecture concepts
ter) relate to processes that affect one or more freight trans- (National ITS Architecture);
OCR for page 48
48
· Consider federal legislation to support and develop the · Evaluate data disaggregation level requirements to ensure
program (National ITS Architecture); statistical significance (HPMS);
· Develop tools to measure benefits and costs early (National · Provide adequate resources for data collection, fully under-
ITS Architecture); stand the implications of small sample sizes, and continue
· Integrate archived data needs into frameworks and archi- to involve the U.S. Census Bureau for the use of survey
tectures early and develop data programs that use industry instruments (CFS);
standards (National ITS Architecture, NTAD); · Emphasize data access, quality, reliability, confidentiality,
· Implement interagency data exchange programs with cen- and integrity (Carload Waybill Sample, FAF, NIPAs);
tralized data coordination (NTAD); · Participate in the standards development process (EDI stan-
· Use available data sources and develop long-term plans dards, National ITS Architecture, NSDI);
while keeping systems flexible to respond to changes and · Create crosswalks to ensure compatibility of survey data
new data sources (FAF, HPMS, National ITS Architecture); internally over time and externally across other datasets
· Schedule major and regular revisions effectively while avoid- (CFS);
ing scope creep (HPMS, NIPAs); · Involve stakeholders early and often through a variety of
· Develop systems that are consistent with input data limi- mechanisms and technologies (ACE/ITDS, FAF, HPMS,
tations (FAF); National ITS Architecture); and
· Develop applications with backward compatibility (EDI · Develop and implement professional capacity and training
standards); programs early (National ITS Architecture).
