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).