Applying the NSDI Framework Transportation Standard for Data Exchange

1
Applying the NSDI Framework Transportation
Standard for Data Exchange

• Facts and Fallacies

2
Facts

• The NSDI Framework Transportation Feature
  Identification Standard is intended to support
  data exchange.
• Proposes a method of identifying transportation
  features.
• Includes a means of transferring data about those
  features.

3
Files, Not Tables

• The standard is expressed as a set of feature
  naming rules and file formats.
• The standard is NOT a data model for production
  databases.
• The files are transactional in design to support
  chronological updates.
• Does not define a topological network.

4
Transactional Files

• Authority ID and the records creation date are
  always part of the primary key.
• No records are ever removed.
• Updates consist of extracting records written
  since a defined date, such as the last update for
  the user.

5
Problems with Previous Draft

• Readers tried to use the file structures as a
  data model for production systems.
• Many reviewers thought the graphic conventions
  used in the standard had to be adopted
  internally.
• Too much emphasis on feature segmentation methods.

6
Other Issues

• Color graphics didnt photocopy well.
• No guidance on moving between the exchange files
  and production databases.
• Lack of clear description of transactional
  nature.
• Confusing references to networks and topology.

7
Authority Defined

• Any organization that takes responsibility for
  proposing, designating, or working in partnership
  with other organizations to define FTRPs and
  FTSegs. Sec. 2.3.1

8
Characteristics of an Authority

• Create or update transportation databases (or
  plan to do so), and
• Share those databases or related attribute sets
  with others (or plan to do so), and
• Conform data exchange practices to this standard.
  Sec. 2.3.1

9
Authority ID

• Five characters in length.
• Starts with two-character FIPS code for the state
  or 00 for federal and multi-state entities.
• Last three characters are sequentially defined
  for each authority.
• Requires an authority registrar.

10
Transportation Features

• Framework Transportation Segments (FTSegs).
• Framework Transportation Reference Points
  (FTRPs).
• FTRPs are placed at the end of each FTSeg.
• Co-terminus FTSegs share a common FTRP.
• No topology required, but can be constructed
  using FTRP types.

11
FTSeg Defined

• A specified directed path between two Framework
  Transportation Reference Points (FTRPs) along a
  physical transportation feature that identifies a
  unique linear element of that feature. Sec.
  2.3.7

12
FTRP Defined

• The specified location of a (required) endpoint
  of a Framework Transportation Segment (FTSeg), an
  (optional) intermediate point along an FTSeg
  defined by an offset distance from the origin of
  the FTSeg, or a (optional) location off the
  linear system defined by FTSegs. Sec. 2.3.3

13
Example Data Sets
14
Multiple Segmentation

• Different Authorities can segment the same set of
  transportation features to meet different
  application needs
• State DOT segments break at State Road
  intersections and state line.
• County segments break at major roads and county
  line.
• City segments break at all street crossings.
• Reconciled using Equivalency File.

15
Feature IDs

• Basic form is AAAAA.F.XXXXXXXX.
• AAAAA is the Authority ID.
• F is the type of feature (FTRPP, FTSegS).
• XXXXXXXX is a sequence number defined by the
  Authority.
• Decimals are explicit i.e., include them.

16
How to Get Started

• Segment the transportation network into discrete
  linear elements.
• Place connection/termini points at the end of
  segments.
• Place other points at locations of special
  interest (along or off segments).
• Apply naming conventions.
• Publish initial set of segments and points.

17
The File Structure

• One header record that contains file name.
• One or more body records.
• Each data record uses ASCII character string
  fields separated by tab characters (ASCII 9) and
  terminated by a carriage return (ASCII 13) and a
  line feed (ASCII 11).
• All fields must be included null values (ASCII
  0) must be explicit.

18
Caveat

• The following slides are based on discussions to
  date and do not reflect an adopted standard.
  Final details may differ slightly from those
  shown here.

19
Authority File

• Authorities are involved in data development and
  maintenance.
• Authority creating the record need not be the one
  that created the identifiers.
• Status P, A, or R.

20
FTRP File

• Describes where it is and how the location was
  determined.
• Location stated using WGS 84 datum.
• Supported by FTRP feature type and measurement
  method files (look-up tables).

21
FTSeg File

• States terminal FTRPs, what path it follows, and
  how the segment length was determined.
• Length stated in meters.
• Supported by FTSeg feature type and measurement
  method files (look-up tables).

22
Intermediate FTRP File

• Indicates the FTSeg upon which the intermediate
  point exists.
• States the distance offset from FTSeg origin in
  .
• Supported by offset measurement method file
  (look-up table).

23
Equivalency File

• Indicates relationship between one set of
  features and another.
• Supports FTRPFTRP, FTRPFTSeg, and FTSegFTSeg
  equivalencies.
• Supports direction differences between FTSegs.

24
Attribute File

• The real data exchange mechanism.
• Some Authorities may only define and share
  attribute data.
• Supports linear LRS.
• Use SDTS for cartographic data.

25
Example of Integration
26
Close Up - FTSegs

• FTSeg Table derived from legacy transportation
  feature table.
• Extra FTSeg data stored in FTSeg Table.
• FTSeg File records are created as updates to
  FTSeg Table occur.

27
Close Up - Attributes

• Attribute Table derived from legacy Event Table.
• Attribute File records are created as updates to
  Event Table occur.

28
Final Draft Changes

• Emphasize transactional nature.
• Reduce segmentation content.
• Show how to migrate/integrate with existing
  databases.
• Illustrate how to use the standard with multiple
  examples.
• Use monochrome graphics conventions.

29
Contact the Author

• Al Butler, GIS Director
• Orange County, Florida
• Al.Butler_at_ocfl.net 407-836-5514
• Mark Bradford is Chair of the FGDC Ground
  Transportation Committee mark.bradford_at_bts.gov.