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 record’s 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 didn’t 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 (FTRP=‘P’, FTSeg=‘S’). “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 FTRP:FTRP, FTRP:FTSeg, and FTSeg:FTSeg 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@ocfl.net; 407-836-5514 Mark Bradford is Chair of the FGDC Ground Transportation Committee; mark.bradford@bts.gov.