Strategic Intermodal System:
Conceptual Database Design
white
paper
prepared for
Florida Department of Transportation,
Office of Policy Planning
prepared by
Cambridge Systematics, Inc.
June 2002
white paper
Strategic Intermodal System:
Conceptual Database Design
prepared for
Florida Department of Transportation
Office of Policy Planning
prepared by
Cambridge Systematics, Inc.
4445 Willard Avenue, Suite 300
Chevy Chase, Maryland 20815
June 2002
Strategic Intermodal System: Conceptual Database Design
( White Paper)
Table of Contents
Introduction..............................................................................................................................
1
Data Integration.......................................................................................................................
2
Business Processes and Functional Requirements..............................................................
6
System Design..........................................................................................................................
10
Database and Mapping Work Plan.......................................................................................
14
Summary: Next Steps.............................................................................................................
16
Appendix A. SIS Data Sets and Sources..............................................................................
A-1
Appendix B. Example of ArcCatalog Metadata Template ...............................................
B-1
Appendix C. National Spatial Data Infrastructure Framework Transportation
Identification Standard: Summary ..............................................................................
C-1
List of Figures
1a
Phase 1 Essential Business Processes (Strategic Intermodal System) ....................
8
1b
Phase 2 Essential Business Processes (Strategic Intermodal System) ....................
9
2
Example Three-Tier Architecture (SIS System Design) ...........................................
11
3
Example Two-Tier Architecture (SIS System Design) .............................................
12
Cambridge Systematics, Inc.
7139.004
i
Strategic Intermodal System: Conceptual Database Design
( White Paper)
Strategic Intermodal System: Conceptual Database Design
(White Paper)
„ Introduction
The Florida Department of Transportation (FDOT) work plan for the Strategic Intermodal
System (SIS) includes an integrated multimodal database and mapping capabilities. This
White Paper describes options for a high-level database and mapping architecture and the
plan for developing this database and the mapping interface to support the SIS
implementation.
An earlier technical memorandum on existing transportation data sources1 identified a
number of databases and applications that contain information of use for the SIS. These
databases contain a broad range of data, including geospatial and attribute data that could
serve as the foundation for the SIS database. Following a review of the available data sets
and sources, an interim list of data is proposed for the SIS database. This list can be added
to as other data becomes available. Consequently the database needs to be designed to
accommodate for future expansion.
This White Paper lays out a two-stage work plan to develop the SIS database and the
mapping and analyses capabilities.
Phase 1 – Integration of data sets for criteria selection testing to designate the SIS components. It first describes those data sources considered suitable candidates for the SIS
databases, and evaluates the data formatting and conversion issues. These include digital
geospatial data, such as the Roadway Characteristics Inventory (RCI) that are used to create FDOT’s basemaps, as well as other transportation features, including bridges, tunnels,
overpasses, and pavement sections that may be geospatially referenced. In addition, there
are many transportation attributes of interest to the SIS, such as speed restrictions, traffic
counts, AADT volumes, crash data, to name a few, which are stored in these disparate
databases. Second, in order to query these data sets for the SIS, a set of selection criteria
will be developed and included with the SIS reporting and mapping tools. These will
enable SIS users to visualize the SIS facilities and data by the chosen selection criteria. In
the first phase of the project, the data sets will be compiled for simple query and analysis
to support the identification, testing and designation of the strategic intermodal corridors
and facilities.
Phase 2 – Development of the final product to support the full SIS implementation. For
the second phase of the project the White Paper proposes a data integration method for
1
An Evaluation of Existing Transportation Data Sources for Use in Defining a Strategic Intermodal
System, Cambridge Systematics, Inc., March 2002.
Cambridge Systematics, Inc.
1
Strategic Intermodal System: Conceptual Database Design
( White Paper)
accomplishing the full integration of the disparate spatial and non-spatial data sets into a
single georeferencing system. This is a significant task given that the data comes from
disparate sources, including local, statewide and national sources. This step is required
for the development of more advanced tools for complex queries and gaming of the SIS as
part of scenario planning exercises. The data integration method employs metadata standards that are supported by the GIS (Geographic Information System) vendors and recommended by the Federal Geographic Data Committee (FGDC). Finally, the SIS business
processes are reviewed together with an evaluation of the available technologies to support the SIS implementation. Based on this assessment, the White Paper describes the
proposed development and phasing in of the systems architecture and database design to
meet SIS functional requirements
„ Data Integration
Database and Mapping Design Issues
The key issues to be addressed in the database and mapping design are:
•
Integration of data from multiple sources, not all in an electronic format today.
•
FDOT has a common base map and linear referencing system, but the other national
and local data sets do not share the same geometry or measurement system.
•
Evolving requirements – In the near term, the requirement is for the graphic display of
alternative system definitions; in the medium term, additional analytical support for
needs assessment and project prioritization as part of strategic planning is required;
and in the long term, “gaming tools” for corridor planning need to be integrated.
•
Rapid development cycle – There is limited time for new data collection or tools
development.
The Database Committee meeting of April 5, 2002, reviewed the technical memorandum
on transportation data sources and identified some additional data requirements to support the SIS functionality, specifically:
•
Address the need for data regarding truck terminals, rest areas, truck stops, weigh
stations, and other elements of the freight system. In some cases, definitions of these
terms may need to be developed.
•
Review MPO and transit agency plans to identify major projects.
•
Define “intermodal connectors” – Look at the work of the Freight Stakeholders Task
Force in this area and the work done for the NHS intermodal connectors.
•
Add data on pipelines.
Cambridge Systematics, Inc.
2
Strategic Intermodal System: Conceptual Database Design
( White Paper)
•
Include other socioeconomic data sources such as the InfoUSA database purchased by
the Systems Planning Office, and community and environmental data collected by the
Environmental Management Office.
The Committee discussed issues and strategies for developing the SIS database. A key
requirement is the capability to “game” the system under different sets of criteria (and to
demonstrate this by the summer). This should include the capability to determine what is
programmed today given these criteria. The map is the key product of the work program.
GIS software will be required to integrate the spatial and attribute data and provide the
mapping functionality. Much of the data already exist – the major technical issue is one of
integrating and assimilating the various data sets.
Database Development Approach
As the SIS database will be integrating data from a number of disparate sources a methodology to accomplish this needs to be established, as follows.
Phase 1. Development of Integrated Database and Visualization Tools to Support
SIS Identification and Designation
1. The database design should specify the types of data to be stored and the data format.
As a first step, Appendix A lists the currently available data sets and sources. These
can be added to as the SIS evolves. The SIS database will be managing geospatial as
well as non-spatial data from different sources, therefore a suitable metadata catalog
will need to be adopted to ensure consistency across the data sets. GIS software such
as ESRI’s ArcCatalog provide this capability as well as conforming to the FGDC
guidelines, and is therefore proposed as this tool in the data compilation. An example
of the ArcCatalog metadata template is illustrated in Appendix B. During this stage
the data sets will be converted into shapefiles and projected into the SPO’s standard
projection system (UTM zone 17: NAD 83).
2. A user-friendly interface with mapping and reporting tools will be developed. The
mapping interface will be created using ArcMap and employ user-friendly icons, buttons, menus and dialog boxes to support the criteria selection and mapping process.
With only a minimal amount of training, the user will be able to intuitively select the
SIS criteria for reporting or mapping. For example, the selection criteria can be related
to the five issues/policy categories identified by the Multimodal team, namely: economic competitiveness (e.g., primary economic activity centers), infrastructure (such
as major transportation corridors and intermodal sites), operations (e.g., location of
bottlenecks on defined performance measures such as LOS), environment and community (including growth management areas and environmentally sensitive areas)
and financial (e.g., right-of-way costs).
3. Within these five categories the specific selection criteria will be determined by the
Criteria Subcommittee of the FDOT Multimodal Team. Two technical memoranda
Cambridge Systematics, Inc.
3
Strategic Intermodal System: Conceptual Database Design
( White Paper)
have been produced that describe FDOT’s past initiatives in developing criteria for
selecting strategic transportation facilities,2 together with a review of selection criteria
developed in five other states.3 These criteria provide a starting point for the creation
of selection criteria for the SIS. Until guidelines or replacement criteria are recommended by the Criteria Subcommittee, they will be implemented in the SIS data analysis and reporting tools using the existing data sets. The selection criteria and the
datasets will be accessed via the mapping/visualization interface.
4. Initially, the selection criteria will be developed independent of the data sets. This will
highlight those issues/policy categories for which data is missing or incomplete. Recommendations can then be made by the Database Subcommittee on whether to collect
the required data from some other source or, if this proves too problematic, to change
the selection criteria to one that is measurable with the data available. It is expected
that the GIS and mapping tools will be extremely valuable in this process, as one of the
ways of determining the completeness of the data to support the criteria analyses is
through geolocation of the data. Therefore, location serves critical functions as data
integrator and as identifier of data gaps. With respect to the latter, knowing the extent
of the data gaps by geography also can indicate the effort involved in rectifying the
problem.
5. The results of Phase 1 development will be a set of tools and data that can be used to
designate the facilities and data requirements for the strategic intermodal system. The
Phase 1 system architecture will use existing client/server hardware and software in
use in the department, including ArcGIS client mapping interface.
Phase 2. SIS Implementation
As the SIS evolves it will incorporate additional data sets and functionality, such as the
analytical and gaming tools required in the planning exercises. In order to implement
these in the most efficient and cost-effective manner, it is proposed to utilize as far as possible standard software and hardware components that are presently in use at FDOT. The
SIS will therefore be able to draw upon a broader base of agency technical expertise and
support with accompanying economies of scale and effort.
1. The SIS database will be a “superset” of the various data sources, including FIHS,
other FDOT, FGDL, federal, and local sources, that will ultimately need to be stitched
together to create a single comprehensive database and mapping system. This is perhaps the greatest challenge in the SIS development. It is assumed that the SIS will not
conflate the spatial data objects – a large exercise unrealistic in the timeline available –
and will therefore need to implement a simpler method to accomplish the conflation
through feature association. One option is to use the FIHS as the foundation or
2
Development of Strategic Transportation Facility and Service Selection Criteria in Florida – Past
Initiatives, Cambridge Systematics, Inc., March 2002.
3
Developing Facility Selection Criteria for Florida’s Strategic Intermodal System, Cambridge Systematics,
Inc., March 2002.
Cambridge Systematics, Inc.
4
Strategic Intermodal System: Conceptual Database Design
( White Paper)
reference network to which the other networks and features are attached at connector
nodes. These nodes can serve as anchor points for the registration of feature layers
and for the linear referencing of transportation data by measurement along the networks. The reference network can be coded to the FGDC’s National Spatial Data
Infrastructure (NSDI) Framework Model standard, which identifies the unique
Feature Nodes and Feature Segments to which all network features are referenced.
This is considered a robust model for applications such as the SIS and is therefore proposed as the geospatial data integration method. A brief summary of the NSDI
Framework Model is described in Appendix C.
2. On-going research in the FDOT Systems Planning Office is developing a conflation
tool for transportation planning and modeling. When this tool is available (scheduled
for the end of December), the data integration between various planning data sources
will be accomplished very efficiently, and these can then be referenced to other data
sets using the NSDI schema outlined above.
3. Beyond the metadata, the data sets will need to be defined in a data model that will
normalize the data and entity relationships, support the storage of spatial data objects
as well as attribute data, and optimize performance for data access and query. This
requires the use of a robust object-relational database management system such as
Oracle together with a spatial indexing system employing ESRI software such as
ArcGIS and ArcSDE. The formal data model should adhere to the NCHRP Report 460,
“Guidelines for the Implementation of Multimodal Transportation Location
Referencing Systems.” This is consistent with the NSDI model proposed above.
Another (optional) consideration is conformity to the ITS America Architecture
Standards with respect to navigable databases and georeferenced networks. A draft
international standard, the Geographic Data Format, is presently under review and
likely to be adopted by ITS America, ANSI, and the ISO (International Standards
Organization) later this year. It may be prudent for the SIS to ultimately incorporate
this geographic data model into its design. The GDF is a more formal data model than
NSDI but the two are not mutually incompatible; indeed, there are many areas of
overlap. A decision on whether to implement the GDF data model is not critical and it
is therefore recommended that this be put off until the SIS is in production.
4. Georeferencing includes the ability to geocode by coordinates (e.g., lat/long and x,y
coordinates), by network feature (node or segment) or using FDOT’s LRS. Fortunately, GIS software is able to perform these functions as well as build the topology to
connect the networks and other spatial features (points and polygons). As indicated
above, these features will need to be stitched together if analysis and editing of multiple features is to performed in the SIS. There are possible non-geographic data that
shall need to be displayed in the SIS map interface such as transportation model
results from FSUTMS. These applications have their own proprietary databases that
will make it unwieldy to fully integrate them with the SIS database. Therefore, the
focus will be on the compilation of the model outputs and how these can be georeferenced to the SIS base map.
Cambridge Systematics, Inc.
5
Strategic Intermodal System: Conceptual Database Design
( White Paper)
5. Finally, how the SIS is to be accessed will influence the selection of the specific hardware, software, and network components. For example, if the SIS database and mapping is to be accessed via browser technology on the Internet/Intranet, an Internet
Map Server (thinner client) will need to be included in the system. Alternatively, a client-server configuration using a LAN/WAN will have a thicker client mapping software. Other design issues to be considered are performance, security access
privileges, version management of scenarios, long transaction processing from multiple users, and – especially relevant to these last two issues – the ability to edit the data
on-line in real time as required in the “gaming” exercises. In Phase 2, consideration
will be given to adding an Internet Map Server to enable SIS users to access the SIS
and perform mapping via a thin client web browser.
„ Business Processes and Functional Requirements
A high-level business analysis of essential business processes and information flows to be
included in the SIS indicates the following components are required:
Phase 1
1. Data compilation and cataloging procedures
2. Digital base map to georeferencing the data by coordinates, linear referencing, or node
and segment
3. Data transformation to a standard spatial data format (shapefile) and FDOT projection
system (UTM Zone 17: NAD 83)
4. Database management system (Oracle) to manage the attribute and spatial data. A
data layering schema will be developed
5. Geographic information system to provide spatial indexing, geocoding, topology
creation, spatial analysis tools, and mapping interface to the SIS database (ArcGIS)
6. Reporting tools to the SIS database. Scenarios saved in the database will be coded by
drafting group to allow easy selection and reporting of results
7. Gaming toolbox for interactive query and analysis of the SIS database. This toolbox
will also contain a “redlining” tool to enable users to highlight features and add conditions, together with some basic editing tools to allow the addition of spatial features
such as points, lines or polygons
Phase 2
8. Implementation of metadata and georeferencing standards for data integration, especially the stitching together of the disparate datasets.
Cambridge Systematics, Inc.
6
Strategic Intermodal System: Conceptual Database Design
( White Paper)
9. The SIS interface seamlessly works with the new GIS for Transportation Modeling
(GIS-TM) tools while accessing all planning models available in the state. The next
generation of GIS-TM is being developed on the ArcGIS platform, and is being rolledout to FSUTMS users beginning this Fall 2002.
10. Export of data to other systems such as the GRIP database; and
11. Security to enable access privileges to be defined.
These 11 essential business processes provide the framework for defining the specific
components for the SIS.
Figures 1a and 1b illustrate the Phase 1 and Phase 2 essential business processes
respectively.
Cambridge Systematics, Inc.
7
Cambridge Systematics, Inc.
Other
RCI
National,
e.g., NHPN
County/
MPO
Transit
Transearch
(Reebie)
Rail
Florida Intrastate
Highway System
Extract/
Transform/
Georeference
Compile Data
Apply Selection
Criteria
FDOT Base Map
Phase 1 GIS Database
Phase 1 Essential Business Processes
Strategic Intermodal System
Ports/Airports
Figure 1a.
Mapping
Tools
Reporting
Tools
Designate SIS
Network
and Facilities
SIS Users
Strategic Intermodal System: Conceptual Database Design
( White Paper)
8
Cambridge Systematics, Inc.
Optional
New Data Sets
Extract/
Transform/
Georeference
Integrate
Spatial Data
Amend Selection
Criteria/System Designation
Designated
SIS Network
and Facilities
Phase 1
SIS Database
Scenarios Tests
Edit Future SIS
External
Database
Security
Privileges
Mapping
Tools
Reporting
Tools
SIS
“Gaming”
Tools
GIS-TM
GeoReferenced
Information
Portal (GRIP)
Export
FDOT Base Map
Phase 2 SIS Database
Import
Phase 2 Essential Business Processes
Strategic Intermodal System
Model Results
FSUTMS,
Freight, etc.
Figure 1b.
FDOT User
Internet
Map
Server
SIS Users
Strategic Intermodal System: Conceptual Database Design
( White Paper)
9
Strategic Intermodal System: Conceptual Database Design
( White Paper)
„ System Design
As indicated earlier, the SIS database design and mapping systems will utilize existing
FDOT software, hardware, and network equipment as much as possible. This will enable
easier integration of the SIS into FDOT’s systems architecture. Even so, some decisions are
needed on, for example, which database and GIS software platforms to use, and the specific
architecture for the SIS. Two system design options that meet these criteria are follows:
1. Three-tier systems architecture comprising the database, applications software, and
user interface; and
2. Two-tier systems architecture of database/applications and browser technology.
The three-tier architecture option employs a standard design that separates the database,
the applications/business logic, and user interface. This option has the benefit of being
able to integrate Oracle, GIS software, and the mapping interface (including Internet map
server) in a proven methodology. This also would be the easiest and most cost-effective to
implement.
The two-tier architecture merges the applications and business logic with the database
and interface layers in a simpler design that is more web accessible and somewhat more
independent of specific software components, such as GIS software. This options requires
some specialist components, such as Oracle spatial for spatial data management, and will
require more programming effort in customizing the interface. However, this design is
more customizable than the three-tier COTS solution.
The features and implications of the two design options are discussed further below.
Systems Architecture
An example of a traditional three-tier systems architecture for the SIS is depicted in
Figure 2. This configuration is compatible with the existing system components in the
Systems Planning Office at FDOT. The alternative two-tier option, depicted in Figure 3,
utilizes browser technology interfaced to the DBMS in a configuration similar to the GRIP
application, which is the other long-term option for the SIS.
In evaluating the technology components, the three-tier system architecture is considered
to be most appropriate technology and configuration to meet the SIS business processes
and functional requirements in Phase 1. Given the short timeline to develop Phase 1
functionality there is little option but to use existing components within the present SPO
client/server system architecture. As indicated in Figure 1b, the Phase 2 Business Process
diagram, a requirement to exchange data with external applications such as the GRIP
database is assumed. The latter could become the SIS database and user interface per the
systems architecture option depicted in Figure 3. While the GRIP could be used for the
Phase 2 SIS implementation, it is designed for much broader purposes and functionality
than the SIS and would take longer to program the needed SIS gaming functionality.
Cambridge Systematics, Inc.
10
Strategic Intermodal System: Conceptual Database Design
( White Paper)
Therefore, in order to keep focused on SIS requirements and be consistent with the
Phase 1 design the recommended system architecture for Phase 2 is the three-tier architecture illustrated in Figure 2.
Figure 2.
Example Three-Tier Architecture
SIS System Design
SIS Planning
FDOT Users
Outside of SPO
Non-FDOT
System Users
III. SIS Interface
Statewide
Planning
Tools
Gaming
Tools
Mapping
Tools
Reporting
Tools
HTML
II. Applications and Business Logic
ArcGIS
SDE
GIS-TM
Map
Server
GIS Applications
Server
ArcIMS
Web
Server
I. SIS Database
Oracle/Oracle
Spatial/Geodatabase
GIS/SIS
Repository
Extraction, Transformation, and Loading Processes
FIHS
GIS Basemap
Planning/
Models
Data
Aviation
SED
Owned or Maintained by FDOT
Cambridge Systematics, Inc.
Rail
GRIP
Transit
BTS
Reebie/
Transearch
County/
MPO
FHWA
Images
Owned or Maintained Outside of FDOT
11
Strategic Intermodal System: Conceptual Database Design
( White Paper)
Figure 3.
Example Two-Tier Architecture
SIS System Design
SIS Planning
Users
FDOT Users
Outside of SPO
1. SIS Interface, Applications, and Business Logic
GIS-TM
Statewide
Planning
Tools
Gaming
Tools
Mapping
Tools
Non-FDOT
System Users
GeoReference Information Portal (GRIP)
Reporting
Re
Tools
HTML
I. SIS Database, Applications, and Business Logic
Web
Server
Oracle Spatial
SIS Data
Repository
Extraction, Transformation, and Loading Processes
FIHS
CAD and
GIS Files
Other
Inventory
RCI
Rail
Transit
Reebie/
Transearch
FHWA/
BTS
Census
Planning/
Model
Data
Aviation
County/
MPO
Videolog
Integrated in GRIP
Not Yet Integrated in Grip
Database Design
In a similar way to the systems architecture design, the database design also must meet
the functional business requirements. The appropriate data are first identified and categorized into the entities that represent discrete business items. The logical relationship
between these is then modeled to create a normalized database that performs as efficiently
as possible.
Cambridge Systematics, Inc.
12
Strategic Intermodal System: Conceptual Database Design
( White Paper)
Managing spatial data has particular challenges in database design because the spatial
data entities may be managed by the GIS and cross-referenced to the attribute data in the
DBMS. This may have performance implications if the spatial indexing is not optimized;
for example, when specifying route-systems that cross-reference several spatial objects or
performing spatial overlay type of analyses. Techniques to overcome some of these limitations, include use of spatial database middleware, such as ESRI’s Spatial Database
Engine (ArcSDE), designed to work specifically with GIS, or storing the spatial objects
directly in the database with Oracle Spatial. The latter is employed by the GRIP application, for example. Oracle Spatial objects also can be read directly by GIS software,
including ESRI products, without the need for middleware like ArcSDE. However,
ArcSDE may be of benefit for other reasons beyond spatial data management (for example, the ability to manage coverages, shapefiles, and compressed binary data objects). At
present the SPO is utilizing Oracle without employing the Spatial extension and uses
Arc/Info to index and manage the spatial data. It is proposed to continue to employ this
software with Oracle DBMS and explore possible upgrade to ArcGIS and ArcSDE.
Interface and Toolbox Design
From the user’s perspective, the interface design is critical as this is how they will interact
with the system. The functionality specified in the design document is used to create a
user-friendly graphic user interface (GUI) for the user to browse and navigate data and
functions as easily and intuitively as possible. Techniques employed to develop interfaces
include Joint Application Development sessions where interface options can be rapidly
mocked-up. The GUI will include standard Windows folders, buttons, menus, dialog
boxes, and other icons.
The SIS presentation interface will be used to query and display data in tabular and map
format, as well as perform “gaming” exercises. This aspect of the design will need to
incorporate the management of different scenarios in the SIS database. The gaming exercises also will select datasets from the SIS and may ultimately be used to select additional
data for loading into the SIS database. As indicated in Figure 1a, the Phase 1 interface will
have at two ways of accessing the SIS: firstly, a GIS mapping GUI; and secondly, a
reporting interface perhaps using a standard forms type GUI. In Phase 2, a third access
tool will be added for the gaming analyses. Although the results of the planning analyses
may be loaded into the SIS database for display in the map or reporting GUIs, it is not currently part of the design to re-engineer the planning applications to work inside the SIS.
This is because applications like FSUTMS are proprietary systems with their own database
structure. Thus, at this time it is considered best to keep them separate, although it will be
possible to access them through the SIS interface.
For other external users it will be possible to enable access to the SIS via the Internet if
deemed appropriate. The Internet may be a useful medium to distribute SIS results to a
wider audience, and the Internet Map Server technology exists to support on-line mapping. The Internet service can be set-up to restrict user access or limit the data available to
on-line users. Optionally, external users also could review the SIS database via the GRIP
interface.
Cambridge Systematics, Inc.
13
Strategic Intermodal System: Conceptual Database Design
( White Paper)
„ Database and Mapping Work Plan
The previous sections have outlined the systems design approach to the SIS development,
including options that are compatible with FDOT’s current information technology. The
work plan lays out a plan to accomplish the design objectives.
Phase 1 (through December 2002)
1. Confirm the Business Analysis and functional requirements described in this report.
Based on the requirements, confirm the appropriate systems design and architecture,
data, and technology to be employed in the two phases. Produce a systems specification document for hardware, software, network, and data components.
2. Identify data sources and data availability and start to compile the geospatial and
attribute data in the GIS. Catalog the data using an agreed metadata standard for the
SIS. As appropriate, some of the data will require transformation or reformatting,.
3. Integrate the selection criteria and parameters. This step is potentially the most problematic in the Phase 1 design. Some of the criteria may not have data available or may
require programming to parse the selection in the required data formats. The specification for this will be determined once the selection criteria is known.
4. Develop the SIS interface. User interface requirements will be determined in collaboration with FDOT staff and in accordance with the technology standard adopted; e.g.,
GIS platform. The design will initially specify the mapping, gaming and reporting
tools, with additional analyses tools added in Phase 2.
5. Train FDOT Multimodal Team in how to use the SIS mapping and reporting tools for
system identification and designation. As far as possible, the tools will automate the
selection, mapping and reporting processes. As Version 1.0 it is best regarded as a
beta version for in-house deployment and user testing prior to further development.
This approach is consistent with the December deadline for initial system development and demonstration.
6. Prepare systems designation report documenting the agreed multimodal facilities and
transportation data, system selection criteria and data gaps.
Phase 2 (2003)
7. SIS Data model and database design – Based on the Phase 1 results, a logical data
model for the SIS will be developed. Once the data has been compiled it can be
populated into the physical database repository in Oracle. Prior to full loading of the
database, a sample of the data can be utilized to test the robustness of the data model
and performance in data query and reporting.
Cambridge Systematics, Inc.
14
Strategic Intermodal System: Conceptual Database Design
( White Paper)
8. Spatial data integration. The spatial data objects will need stitching together by the
method of attribute conflation (feature association) described above. This method
does not change the data object but it will amend the feature properties to enable the
connection of links, for example, at anchor nodes. There also may be a need to digitize
some features such as links to connect key facilities where these may be missing (this
also may be needed for future scenario testing). The spatial database will be updated
to incorporate these changes.
9. Gaming development. The basic gaming tools created in Phase 1 will be developed
further with the addition of more analyses tools. These will be specified in agreement
with FDOT staff. At this time the requirements have not been defined, and as in
Phase 1, the ability to analyse the system may be limited by the availability of the data.
A prototype gaming and analysis module will be developed for testing and review.
The prototype will be created in the development environment, which is where the
preliminary testing will occur.
10. Following the initial testing, the prototype system can be modified to fine-tune the
functionality and design. An acceptance test plan for the SIS shall be developed
incorporating the agreed functions to be performed by the SIS. It should be noted that
the SIS is a work in progress in so far as all the data required for the SIS functions may
not be available.
11. Implementation – This step includes systems configuration and acceptance testing
on-site in FDOT. A separate testing environment should be established in FDOT that
mirrors the production environment. After acceptance testing and certification, the
SIS data and software can be loaded into the production environment.
12. Provide user training to different levels of users, from executive managers to technical
staff.
13. Produce the Final Report and Systems Documentation.
Phase 1 shall precede Phase 2, but within each phase each task is not on a critical path; i.e.,
the completion of one task is not essential for the start of another task. In fact, some of the
tasks will be carried out in parallel. For applications like the SIS, an iterative development
procedure is preferred. After each step, the design will be revisited to confirm the business logic and fine-tune the design as appropriate. In general, we would wish to limit any
design changes to only those considered essential; however, we recognize that some flexibility and openness to change is beneficial to the SIS evolution.
A project schedule depicting the task timeline and staffing estimates for the database and
mapping development will be provided separately.
Cambridge Systematics, Inc.
15
Strategic Intermodal System: Conceptual Database Design
( White Paper)
„ Summary: Next Steps
Data compilation is proceeding. Decisions are needed on the selection criteria and the
system architecture for Phase 1 (database management system, GIS software and systems
design). Once these elements are selected the Phase 1 system identification and designation activities can proceed in full. The detailed design of the SIS data model, the spatial
data integration and development of the additional gaming/analyses tools shall proceed
once a decision is made on the Phase 2 architecture and the SIS implementation design.
Given the relatively short scheduled timeline for the project, the three-tier systems architecture option that utilizes existing FDOT software and hardware is recommended as the most
efficient means of developing the SIS database and mapping system for Phases 1 and 2.
Cambridge Systematics, Inc.
16
Appendix A
SIS Data Sets and Sources
Strategic Intermodal System: Conceptual Database Design
( White Paper)
Appendix A. SIS Data Sets and Sources
„ Current Florida GIS Data Sets Available
Infrastructure Data
Source: FDOT
•
Rail (2000 Florida Rail System Plan)
•
Amtrak Stations
•
Rail Freight Stations
•
Fixed Transit Systems
•
Intercity Bus Stops
•
Intercity Bus Routes
•
Water Ports
•
Airports (and Forecast Data)
•
Road Network (FIHS, SHS)
•
Florida Urban Transit Lines (FTIS data)
Source: BTS (Bureau of Transportation Statistics)
•
BTS Commercial Air Segment Network (maintained by BTS)
•
Airports (and Runways) (maintained by BTS)
•
National Highway Planning Network (maintained by FHWA)
•
National Railway Network 1999 (maintained by FRA)
•
Amtrak Stations (maintained by FRA)
•
Intermodal Terminals (maintained by BTS)
•
Fixed-Guideway Transit and Ferry Network (maintained by BTS)
•
Water Port Facilities (maintained by Army Corps of Engineers)
•
Navigable Waterways (maintained by Army Corps of Engineers)
Source: CTA Transportation Networks (Oak Ridge National Lab)
•
Highway Network – all major roads
•
CTA Rail
•
Intermodal Transportation Network
Cambridge Systematics, Inc.
A-1
Strategic Intermodal System: Conceptual Database Design
( White Paper)
Source: ESRI
•
Airports – Point Locations and Detailed Polygon outlines
•
U.S. Roads
•
U.S. Rail Lines
Source: NTAD
•
Airports – Point Locations of U.S. Airports and Heliports
•
Terminals – Point Locations of U.S. Freight Terminals
•
Ports – Point Locations of Major U.S. Ports
•
Amtrak Stations – Point locations
•
Waterways – Navigable Waterways in U.S.
•
Waterways Nodes
•
Transit – Light/Heavy Rail Lines and some Ferry Routes
•
Runway – Linear Locations of U.S. Public Use Airport Runways (1998)
•
Rail – Rail100k (FRA 2000 at 1:100,000 base scale)
•
NHPN
Source: U.S. Census Bureau
•
TIGER/Line Files – All U.S. Roads (Geocoding Address Info)
•
TIGER/Line Files – U.S. Rail Lines
Source: Caliper
•
U.S. Roads (all roads)
Source: USGS
•
Airports
Source: FAF-FHWA (Freight Analysis Framework)
•
Road Network (with large number of impedance attributes)
Environmental and Community Data
Source: ESRI
•
Detailed State Outline
•
Detailed Counties
•
Major Water Bodies
Cambridge Systematics, Inc.
A-2
Strategic Intermodal System: Conceptual Database Design
( White Paper)
•
Parks
•
Recreation Areas
•
Urbanized Areas
•
Zip Code Boundaries
Source: U.S. Census Bureau
•
Blocks (and demographics)
•
Blocks Groups (and demographics)
•
Census Tracts (and demographics)
•
Designated Places (and demographics)
•
Counties (and demographics)
•
Urbanized Areas
Source: FGDL
•
County Subdivisions
•
Biking/Hiking/Multi-Use Trails
•
Biodiversity Hotspots
•
Boat Marinas
•
Coral Reefs
•
Cultural/Historic Sites
•
Ecosystem Management Areas
•
Future Land Use
•
Forest Type/Density
•
Habitat Conservation Areas
•
Hazardous Materials Sites
•
Major Rivers/Hydrography
•
Manatee Zones
•
Paddling Trails
•
Power plant Locations
•
Wildlife Refuges
Cambridge Systematics, Inc.
A-3
Strategic Intermodal System: Conceptual Database Design
( White Paper)
Source: Florida Fish and Wildlife Conservation Commission
•
Biodiversity Hotspots
•
Species Habitats
•
Land Cover
•
Land Value
Cambridge Systematics, Inc.
A-4
Appendix B
Example of ArcCatalog Metadata Template
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
Appendix B. Example of ArcCatalog Metadata Template
„ Public-Use Airports
Metadata:
•
Identification_Information
•
Data_Quality_Information
•
Spatial_Data_Organization_Information
•
Spatial_Reference_Information
•
Entity_and_Attribute_Information
•
Distribution_Information
•
Metadata_Reference_Information
Cambridge Systematics, Inc.
B-1
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
Identification_Information:
Citation:
Citation_Information:
Originator: Bureau of Transportation Statistics
Publication_Date: 2001
Publication_Time: Unknown
Title:
Public-Use Airports
Geospatial_Data_Presentation_Form: vector digital data
Online_Linkage: http://www.bts.gov/gis/ntatlas/facilities.html
Description:
Abstract:
The Public-Use Airports database is a geographic point database of aircraft
landing facilities in the United States and U.S. Territories. Attribute data is provided on the physical and operational characteristics of the landing facility, current usage including enplanements and aircraft operations, congestion levels
and usage categories.
Purpose:
The database provides locational and attribute information for use in national
and regional cartographic and spatial analysis applications.
Time_Period_of_Content:
Time_Period_Information:
Single_Date/Time:
Calendar_Date: 199510
Currentness_Reference:
ground conditions and annual summaries
Status:
Progress: Complete
Maintenance_and_Update_Frequency: Annually
Spatial_Domain:
Bounding_Coordinates:
West_Bounding_Coordinate: -177.379517
East_Bounding_Coordinate: 174.113617
North_Bounding_Coordinate: 71.285446
South_Bounding_Coordinate: -14.331023
Keywords:
Theme:
Theme_Keyword_Thesaurus: None
Theme_Keyword: point
Theme_Keyword: transportation
Theme_Keyword: airport
Access_Constraints: None
Use_Constraints:
None. Acknowledgment of the Bureau of Transportation Statistics National
Transportation Atlas Database would be appreciated.
Cambridge Systematics, Inc.
B-2
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
Point_of_Contact:
Contact_Information:
Contact_Person_Primary:
Contact_Organization: BTS
Contact_Address:
Address_Type: mailing and physical address
Address:
400 Seventh Street, SW
City: Washington
State_or_Province: District of Columbia
Postal_Code: 20590
Contact_Voice_Telephone: (202) 366-DATA
Contact_Facsimile_Telephone: (202) 366-3640
Contact_Electronic_Mail_Address: answers@bts.gov
Native_Data_Set_Environment:
Microsoft Windows 2000 Version 5.0 (Build 2195) Service Pack 2; ESRI ArcCatalog
8.1.2.671
Back to Top
Data_Quality_Information:
Attribute_Accuracy:
Attribute_Accuracy_Report:
Attribute_Accuracy_Report: Airport attributes were obtained from the Federal
Aviation Administration (FAA) National Flight Data Center Airport Master
Record (NFDC 5010) database and the Office of Airline Information (OAI).
Some airport features in this version are not assigned Site Numbers (SITE_NO).
These are airports where the location identifier (LOCID) did not match any current record in the NFDC data. These features have no corresponding records in
any attribute file. They were not deleted from this version in anticipation of
performing a more thorough review.
Logical_Consistency_Report:
All point records are represented by a single coordinate pair and a unique feature
identifier – the landing facility’s location identifier (LOCID) and Site Number
(SITE_NO) assigned by the FAA.
Completeness_Report:
Landing facilities in this database consist of those identified in the NFDC 5010 database to be either publicly owned, or privately owned but open to the public, or
owned by the U.S. military. The following landing facilities have been excluded:
private landing facilities not open to the public, glider ports and ultra light landing
facilities, as well as landing facilities that do not have a current LOCID assigned to
them.
Positional_Accuracy:
Horizontal_Positional_Accuracy:
Horizontal_Positional_Accuracy_Report:
Cambridge Systematics, Inc.
B-3
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
Horizontal positional accuracy is based on coordinate data provided in the
NFDC 5010 database. These coordinate data identify the approximate
location of the Airport Reference Point (ARP) as reported by the landing
facility on the NFDC 5010 form. According to NFDC guidelines, the location of the ARP should be reported to a horizontal accuracy of one arc
second of latitude and longitude. However, the accuracy of these reported
coordinates are not verified by FAA. The records were loaded into a GIS
and checked for any unusual or obviously erroneous locations.
Back to Top
Spatial_Data_Organization_Information:
Direct_Spatial_Reference_Method: Vector
Point_and_Vector_Object_Information:
SDTS_Terms_Description:
SDTS_Point_and_Vector_Object_Type: Entity point
Point_and_Vector_Object_Count: 19793
Back to Top
Spatial_Reference_Information:
Horizontal_Coordinate_System_Definition:
Geographic:
Latitude_Resolution: 0.000278
Longitude_Resolution: 0.000278
Geographic_Coordinate_Units: Decimal degrees
Geodetic_Model:
Horizontal_Datum_Name: North American Datum of 1983
Ellipsoid_Name: Geodetic Reference System 80
Semi-major_Axis: 6378206.400000
Denominator_of_Flattening_Ratio: 294.978698
Back to Top
Entity_and_Attribute_Information:
Detailed_Description:
Entity_Type:
Entity_Type_Label: airport
Attribute:
Attribute_Label: FID
Attribute_Definition:
Internal feature number.
Cambridge Systematics, Inc.
B-4
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
Attribute_Definition_Source:
ESRI
Attribute_Domain_Values:
Unrepresentable_Domain:
Sequential unique whole numbers that are automatically generated.
Attribute:
Attribute_Label: Shape
Attribute_Definition:
Feature geometry.
Attribute_Definition_Source:
ESRI
Attribute_Domain_Values:
Unrepresentable_Domain:
Coordinates defining the features.
Attribute:
Attribute_Label: VERSION
Attribute_Definition:
The VERSION is a two-digit number that will be incremented for all records in the database whenever a new release is distributed. In this release
the value is 04.
Attribute:
Attribute_Label: REVISION
Attribute_Definition:
The REVERSION is a two-digit number that will be incremented for all
records in the database whenever a new revision is distributed. In this
release the value is 01.
Attribute:
Attribute_Label: SITE_NO
Attribute_Definition:
Site Number – A unique identifying number followed by an asterisk and
the ‘landing facility type’ code, forms the key to the airport records in the
NFDC (5010) database. Example: 04508.*A
Attribute_Definition_Source:
NFDC
Attribute:
Attribute_Label: LOCID
Attribute_Definition:
Unique three- to four-character identifier assigned to the landing facility
Attribute:
Attribute_Label: FAC_TYPE
Attribute_Definition:
Facility Type
Attribute:
Attribute_Label: EFF_DATE
Attribute_Definition:
Information effective date – date
Attribute:
Attribute_Label: FAA_REGION
Cambridge Systematics, Inc.
B-5
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
Attribute_Definition:
FAA Region where the facility is located
Attribute:
Attribute_Label: FAA_DIST
Attribute_Definition:
FAA District or field office code
Attribute:
Attribute_Label: ST_POST_CD
Attribute_Definition:
The two letter postal abbreviation for the state where the associated city is
located, not necessarily the state where the landing facility is physically
located.
Attribute:
Attribute_Label: STFIPS
Attribute_Definition:
State FIPS Code
Attribute:
Attribute_Label: ST_NAME
Attribute_Definition:
Associated State Name
Attribute:
Attribute_Label: COUNTY
Attribute_Definition:
County Name of the facility location
Attribute:
Attribute_Label: CITY
Attribute_Definition:
City that the landing facility is associated with, heretofore referred to as
the associated city; not necessarily the city where the landing facility is
physically located.
Attribute:
Attribute_Label: FULL_NAME
Attribute_Definition:
Official Airport Name
Attribute:
Attribute_Label: FAC_USE
Attribute_Definition:
Facility use – public or private
Attribute:
Attribute_Label: OWN_TYPE
Attribute_Definition:
Type of Facility Owner
Attribute:
Attribute_Label: LONGITUDE
Attribute_Definition:
The longitude of the point expressed as a signed real number. This value
is in decimal degrees with negative values indicating West longitude and
positive values indicating East longitude.
Cambridge Systematics, Inc.
B-6
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
Attribute:
Attribute_Label: LATITUDE
Attribute_Definition:
The latitude of the point expressed as a signed real number. This value is
in decimal degrees with negative values indicating South latitude and
positive values indicating North latitude.
Attribute:
Attribute_Label: COORD_DET
Attribute_Definition:
Determination method for airport Coordinate value
Attribute:
Attribute_Label: ELEV
Attribute_Definition:
Elevation in feet at the highest point on the centerline of the usable landing
surface
Attribute:
Attribute_Label: AERO_CHT
Attribute_Definition:
Aeronautical chart on which the airport Facility appears
Attribute:
Attribute_Label: CBD_DIST
Attribute_Definition:
Distance from the central business district of the associated city to the
landing facility in nautical miles (one nautical mile = 6,080 feet).
Attribute:
Attribute_Label: CBD_DIR
Attribute_Definition:
Direction of airport from the central Business district of the associated city
Attribute:
Attribute_Label: ACT_DATE
Attribute_Definition:
Identifies the month and year that the facility was added to the NFDC airport database – only available for facilities opened since 1981 (MM/YY)
Attribute:
Attribute_Label: CERT
Attribute_Definition:
Certification type and date – The month/year of certification (e.g., 01/83)
concatenated with the certification code.
Attribute:
Attribute_Label: FED_AGREE
Attribute_Definition:
NASP/Federal Agreement Code – a combination of one to seven codes
that indicate the type of federal agreements existing at the airport
Attribute:
Attribute_Label: CUST_INTL
Attribute_Definition:
Cambridge Systematics, Inc.
B-7
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
Customs international airport – Whether the landing facility has been
designated by the U.S. Treasury as an international airport of entry for
customs.
Attribute:
Attribute_Label: C_LDG_RTS
Attribute_Definition:
Customs Landing Rights Airport – Whether the landing facility has been
designated by the U.S. Treasury as a customs landing rights airport (some
landing facilities may have these rights for cargo only).
Attribute:
Attribute_Label: JOINT_USE
Attribute_Definition:
Joint Use – Whether the landing facility has a military/civil joint use
agreement that allows civil operations at a military airport or military
operations at a civil airport.
Attribute:
Attribute_Label: MIL_RTS
Attribute_Definition:
Military Landing Rights – Whether the airport has entered into an agreement that grants landing rights to the military.
Attribute:
Attribute_Label: NAT_EMER
Attribute_Definition:
National Emergency Status – Status of an airport that is available for use
during a national emergency. These are civil airports that were formerly
military airfields but the military services have a continuing interest in
their use during national emergencies. Data values in this field are one or
a series of alphanumeric codes indicating national emergency status, with
each code in a series separated by a ‘/’. (Ex. 6 1/4 3E/8/1).
Attribute:
Attribute_Label: MIL_EMER
Attribute_Definition:
Military Emergency Interest – Military department(s) that maintains
national emergency use interest in this civil facility. Data values in this
field are one, two, or three alphanumeric codes indicating military emergency use interest, with each code in a series separated by a ‘/’.
Attribute:
Attribute_Label: CNTL_TWR
Attribute_Definition:
Airport Control Tower located on the airport
Attribute:
Attribute_Label: S_ENG_GA
Attribute_Definition:
Based Single Engine General Aviation Aircraft
Cambridge Systematics, Inc.
B-8
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
Attribute:
Attribute_Label: M_ENG_GA
Attribute_Definition:
Based Multi-engine general aviation aircraft
Attribute:
Attribute_Label: JET_EN_GA
Attribute_Definition:
Based Jet engine general aviation aircraft
Attribute:
Attribute_Label: HELI_GA
Attribute_Definition:
Based Helicopters – General Aviation
Attribute:
Attribute_Label: OP_GLID
Attribute_Definition:
Base Operational Gliders – General aviation
Attribute:
Attribute_Label: OPER_MIL
Attribute_Definition:
Based Military Aircraft – including helicopters
Attribute:
Attribute_Label: ULTRA
Attribute_Definition:
Based Ultralight aircraft – general aviation
Attribute:
Attribute_Label: COMMSERV
Attribute_Definition:
Commercial Services – scheduled operations by CAB certified carriers or
intrastate carriers and any scheduled commuter/cargo carriers (Annual
Operations)
Attribute:
Attribute_Label: AIR_TAXI
Attribute_Definition:
Air Taxi operators carrying passengers, mail, or mail for revenue (Annual
Operations)
Attribute:
Attribute_Label: LOCAL_GA
Attribute_Definition:
General Aviation, Local Operations – Those operating in the local traffic
pattern or within a 20-mile radius (Annual Operations)
Attribute:
Attribute_Label: ITIN_GA
Attribute_Definition:
General Aviation – Itinerant Operations Those general aviation operations
(excluding commuter or air taxi) not qualifying as local (Annual
Operations)
Cambridge Systematics, Inc.
B-9
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
Attribute:
Attribute_Label: MIL_OPS
Attribute_Definition:
Military Aircraft Operations (Annual Operations)
Attribute:
Attribute_Label: DOM_TOT
Attribute_Definition:
Total domestic enplanements (inbound plus outbound) – this field only
valid for some airports
Back to Top
Distribution_Information:
Distributor:
Contact_Information:
Contact_Person_Primary:
Contact_Organization: BTS Product Distribution Center
Contact_Address:
Address:
400 Seventh Street, SW
City: Washington
State_or_Province: District of Columbia
Postal_Code: 20590
Contact_Voice_Telephone: (202) 366-DATA
Contact_Facsimile_Telephone: (202) 366-3640
Contact_Electronic_Mail_Address: answers@bts.gov
Resource_Description: National Transportation Atlas Database 2001
Distribution_Liability:
None
Standard_Order_Process:
Digital_Form:
Digital_Transfer_Information:
Format_Name: ESRI Shapefile
File_Decompression_Technique: No compression applied
Transfer_Size: 7.295
Back to Top
Metadata_Reference_Information:
Metadata_Date: 20020508
Metadata_Contact:
Contact_Information:
Contact_Organization_Primary:
Cambridge Systematics, Inc.
B-10
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
Contact_Organization: Bureau of Transportation Statistics
Contact_Address:
Address_Type: 400 Seventh Street, SW
City: Washington
State_or_Province: D.C.
Postal_Code: 20590
Contact_Voice_Telephone: (202) 366-3282
Contact_Facsimile_Telephone: (202) 366-3640
Contact_Electronic_Mail_Address: answers@bts.gov
Metadata_Standard_Name: FGDC Content Standards for Digital Geospatial Metadata
Metadata_Standard_Version: FGDC-STD-001-1998
Metadata_Time_Convention: local time
Metadata_Extensions:
Online_Linkage: http://www.esri.com/metadata/esriprof80.html
Profile_Name: ESRI Metadata Profile
Back to Top
Cambridge Systematics, Inc.
B-11
Appendix C
National Spatial Data Infrastructure Framework
Transportation Identification Standard: Summary
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
Appendix C. National Spatial Data Infrastructure
Framework Transportation Identification Standard:
Summary
„ 1.0 Introduction
1.1
Background
Many users of geospatial data within both the transportation and GIS communities have
questions about the relationships among transportation features such as roads, their representation as geospatial objects in geographic information systems (GIS), and their representation in analytical networks. Much of this confusion results from the inconsistent use
of terminology to describe transportation features and their representations. It also is
perpetuated by current versions of GIS software, which fail to adequately address the differences between lines used for cartographic displays and those used for network analysis.
1.2
Need for Standards
One consequence of this confusion has been an inability to promulgate national standards
for transportation spatial features to facilitate data sharing under the National Spatial
Data Infrastructure (NSDI) initiative. A fundamental requirement of spatial data sharing
is that both the supplier and the recipient of the data understand what the data represents
in terms of real-world features. This is relatively straightforward for features having welldefined boundaries such a building or airport. However, many transportation features
are characterized by extensive linear networks, with no universally agreed-upon standard
for partitioning these networks into unique “segments.” Each developer of a transportation network spatial database partitions the network to meet his or her specific application
needs.
1.3
FGDC Action
The Federal Geographic Data Committee (FGDC) was established by the Office of
Management and Budget (OMB) under Circular A-16 to promote the coordinated development, use, sharing, and dissemination of geographic data. The committee, which is
composed of representatives from 17 departments and independent agencies, oversees
and provides policy guidance for agency efforts to coordinate geographic data activities.
The FGDC created the Ground Transportation Subcommittee in January 1992 to address
data issues involving transportation features and networks. The objectives of the
Subcommittee are to:
Cambridge Systematics, Inc.
C-1
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
•
Promote standards of accuracy and currency in ground transportation data that is
financed in whole or in part by federal funds;
•
Exchange information on technological improvements for collecting ground transportation data;
•
Encourage the federal and non-federal community to identify and adopt standards
and specifications for ground transportation data; and
•
Promote the sharing of ground transportation data among federal and non-federal
organizations.
1.4
NSDI Framework Data
Transportation is one of the seven Framework layers identified in the National Spatial
Data Infrastructure. NSDI framework data represents the “best” available geospatial data
for an area. The data is collected or compiled to a known level of spatial accuracy and
currency, documented in accordance with established metadata standards, and made
available for dissemination at little or no cost and free of restrictions on use. Framework
data is not necessarily uniform from one area to another; the quality of the data for a given
area depends on the requirements of the participating data developers. The NSDI does
not specify threshold standards for spatial accuracy, attribution, completeness of coverage, or currency for any of its framework themes. The resulting framework will be a
“patchwork quilt” consisting of high-quality, geospatial data for some geographic areas,
with lower quality or even missing data for other areas. As more data developers
upgrade their geospatial data and participate in the NSDI, the overall quality of the data
comprising the NSDI Framework and the completeness of nationwide coverage will
improve.
For further information see the FGDC publication “NSDI Framework
Introduction and Guide,” http://www.fgdc.gov/framework/frameworkintroguide/.
1.5
The Transportation Framework Data Layer
The importance of geospatial data depicting transportation features – especially road networks – extends well beyond their cartographic value. Road networks provide the basis
for several indirect location referencing systems, including street addresses and various
linear referencing methods commonly used to locate features like bridges, signs, pavement conditions, and traffic incidents. Geospatial transportation segments can be connected to form topological networks, which can be used to more accurately measure overthe-road travel distances between geographic locations. Furthermore, when combined
with the variety of network analysis tools that are available, topological networks can be
used to find the shortest paths between two or more locations, to determine the most efficient route to cover all transportation segments (e.g., for planning of snow removal), or to
estimate traffic volumes by assigning origin-to-destination flows to network segments.
Integration of the “best available” transportation databases into a national framework
layer must provide for nationwide connectivity in order to support the network
Cambridge Systematics, Inc.
C-2
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
applications described above. This means that there can be no “gaps” (geographic areas
where transportation data is totally absent). Further, the transportation data for each particular geographic area must be produced so that it can be connected topologically to
transportation data for adjacent areas.
1.6
Federal, State, and Local Transportation Data Resources
A nationwide NSDI framework road layer could be constructed from the national-level
databases developed by federal agencies: Bureau of the Census TIGER/Line files,
U.S. Geological Survey Digital Line Graph (USGS/DLG) files, and the National Highway
Planning Network (NHPN) developed by the Federal Highway Administration (FHWA).
These databases serve most federal needs and many general public requirements for
national level road data at the 1:100,000 scale, and provide network connectivity in those
areas where more accurate transportation data does not exist. However, such a database
would not offer the currency, completeness, and accuracy required by many other users.
More than half of the state Departments of Transportation (DOT) have developed road
databases at a scale of 1:24,000 or better. These databases are almost certainly of superior
accuracy, completeness, and currency than the national databases, and could take the place
of federal road data as the framework database for their respective areas, providing they
meet other NSDI framework requirements (e.g., metadata documentation, no restrictions
on use). Road data that is even more accurate and current exists for many smaller geographic units; e.g., counties or metropolitan areas. These databases could be utilized
instead of either the federal or state transportation data as the framework database for
their specific areas.
1.7
The Challenge
Creation of the NSDI framework transportation layer will require the participation of a
large number of federal, state, and local transportation agencies, and their contribution of
transportation databases developed for specific geographic areas and applications. The
databases will be – or have been – developed at different scales, with different levels of
positional accuracy, detail, and completeness of coverage, and currency. These databases
will have to be “stitched together” in order to provide the network connectivity required
for many transportation applications. When new databases are added to the framework,
or when specific attributes are updated or enhanced, users of framework data will need to
be able to incorporate this new information into their applications in ways that are costeffective.
The process of transferring information (including more accurate coordinates) from one
geospatial database to another is known as “conflation.” Successful conflation requires
that the features in one geospatial database be matched to their counterparts in the other
database. Once this match is achieved, geometric and/or attribute data can be exchanged
from either of the two databases to the other. For example, coordinate data depicting the
alignment of a transportation segment can be transferred from a transportation database
Cambridge Systematics, Inc.
C-3
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
digitized from 1:12,000 scale digital orthophotoquads (DOQ) to a database that had originally been digitized from 1:24,000 scale USGS topographic maps.
Typically the process of conflation uses a combination of coordinate matching and name
matching. Depending on the similarity of the two databases, the percentage of successfully matched features can vary from more than 90 percent to well less than 50 percent.
This range of variability is unacceptable for successful implementation of the NSDI
framework, which will require ongoing additions of new framework databases and transactional updates to attributes in existing framework databases.
A more promising conflation method starts with the assignment of a stable and unique
identifier to each geospatial feature. This identifier can then be used to match features
across databases without having to rely on coordinate accuracy or the use of standard
names. Unique feature identifiers work best when instances of features are well-defined
and spatially distinct. The identification of a discreet feature instance is not always obvious for linear features such as roads and surface waters. Roads are segmented in an
almost infinite number of ways, depending on the application needs of the database
developer. Roads may be segmented at intersections for path building, or at changes in
one or more attributes for use in facility management. Also, a transportation segment
may terminate at a state, county, or municipal border, or other jurisdictional boundary.
Within the same geographical area multiple entities may create, update, and/or use different transportation databases. For example, a state DOT may create a transportation
database that includes only state highways, and may segment its roads wherever one
highway intersects another. A local transportation planning agency might create a database for the same area that includes all local roads; this agency could segment the state
highways wherever they intersect any road. Finally, an E-911 agency could create yet a
third transportation database for the area, segmenting all roads at each private driveway.
Most geographic information system (GIS) software packages currently do not enable the
user to distinguish between an instance of a linear geospatial feature and how that feature
is represented in a topological network. Each of the transportation databases mentioned
above represents the same physical transportation network but divides it into different –
often overlapping – segments in order to establish topological connections needed for the
respective applications. Each segment becomes a distinct record in the geospatial database unique to that application. Finding a set of common transportation segments that
carry topology and are useful in all existing and potential applications is impossible in
most geographic areas.
Cambridge Systematics, Inc.
C-4
Strategic Intermodal System: Conceptual Database Design
(Draft White Paper)
The concept of a permanent transportation segment identifier is attractive, but the need to
add new transportation segments to accommodate other applications or to reflect changes
in infrastructure can create problems. Consider the case of a road segment (Segment_A)
with an assigned permanent identifier, as illustrated in Figure 1. A new road (Segment_B)
is built that intersects the old road segment part way along its length. In order to maintain
network topology, the old road segment must be split and a node established where the
new road intersects. The identifier for the old road segment is no longer valid. It must be
retired and three new identifiers created: one for the new intersecting road (Segment_B)
and one for each new segment (Segments_AA and AB) of the (now split) old road segment. Recording, disseminating, and applying these transactions could become prohibitively complex or time consuming, both for the database developer and for users trying to
incorporate the updated information into their own application database.
In summary, the growing needs of users make the argument for constructing an NSDI
framework transportation data layer(s) a compelling one. Also, all users will benefit if the
investments in high-quality transportation information being made by many units of state
and local government can be incorporated. The related technical requirements present a
challenge in the development of standards, technology, and procedures that will be
needed in order to accomplish this task.
Cambridge Systematics, Inc.
C-5