oregon road centerline data standard 6.0 … forum documents... · web viewtitle oregon road...

November 2013

Oregon Road CenterlineData Standard

Version 6.0November 2014

Please address comments to:

Framework Implementation Team Transportation SubcommitteeBrett Juul, GIS ManagerOregon Department of TransportationGIS [email protected]

Oregon Road Centerline Data Standard Version 6.0, pg. 1Transportation Framework Implementation Team

mailto:[email protected]

November 2013

Table of Contents

Section Title Page

1.0 Introduction.............................................................................................................31.1 Mission and Goals of the Standard.........................................................................31.2 Relationship to Existing Standards.........................................................................31.3 Description of the Standard....................................................................................41.4 Applicability and Intended Use of the Standard.....................................................41.5 Standard Development Procedures.........................................................................51.6 Maintenance of the Standard..................................................................................5

2.0 Body of the Standard..............................................................................................52.1 Scope and Content of the Standard.........................................................................52.2 Need for the Standard.............................................................................................62.3 Participation in Standards Development.................................................................62.4 Integration with Other Standards............................................................................72.5 Technical and Operational Context........................................................................7

2.5.1 Data Environment...................................................................................72.5.2 Reference System...................................................................................72.5.3 Global Positioning Systems (GPS).........................................................72.5.4 Integration of Themes.............................................................................82.5.5 Encoding.................................................................................................82.5.6 Resolution...............................................................................................82.5.7 Accuracy.................................................................................................82.5.8 Edge Matching........................................................................................82.5.9 Feature Identification Code....................................................................82.5.10 Attributes................................................................................................92.5.11 Transactional Updating..........................................................................92.5.12 Records Management.............................................................................92.5.13 Metadata...............................................................................................10

3.0 Data Characteristics..............................................................................................103.1 Minimum Graphic Data Elements........................................................................103.2 Minimum Attribute or Non-Graphic Data Elements............................................103.3 Optional Graphic Data Elements..........................................................................113.4 Optional Attribute or Non-Graphic Data Elements..............................................11

Appendix Title Page

A Prototype Data Structure (fifth draft)....................................................................12B Definitions of Terms.............................................................................................15C Reference Documents and Website Links............................................................18


November 2013

1.0 Introduction

Under the direction of the Oregon Geographic Information Council (OGIC), the Oregon Framework Implementation Team has delegated the development of a Transportation Framework Implementation Plan and a prototype Transportation Data Standard to the Framework Implementation Team Transportation Subcommittee (T-FIT). The Transportation Framework is a collection of prioritized, spatially referenced digital representations of broadly defined transportation feature sets for Oregon. The Transportation Framework Theme currently comprises (in no particular order): bridges, cable car & chairlifts, culverts, railroads, address ranges, roads (FTSeg), traffic analysis zones, trails, transportation structures, heliports, light houses, military operations, navigation hazards, paved areas (airports), runways, and air traffic navigation beacons (Very-high Omnidirectional Range (VOR) devices).

This document, the Oregon Road Centerline Data Standard version 5.0, replaces the previous versions that described the first iterative component of the Transportation Framework Implementation plan, which were used in draft form as a guide for the T-FIT pilot projects undertaken throughout the state. It is the result of several collaborative “minimal data standard” T-FIT meetings that occurred between February and August of 2002, and is oriented toward basic geospatial data support for the Oregon Office of Emergency Management’s (OEM) mapped Master Street Address Guide (MSAG) enhancement efforts, which supports Phase 2 E911 goals for cellular phones.

1.1 Mission and Goals of Standard

The Oregon Road Centerline Data Standard will provide a consistent and maintainable structure for transportation data producers and users, which will help to ensure the compatibility of datasets within the same framework feature set and between other framework feature sets and themes. Specifically, the data standard will assist agencies responsible for the creation, maintenance, and distribution of road centerline data sets by reducing the costs of data sharing, data development, and data maintenance between road authorities. It will also help to ensure that road centerline attribution (including geometry) is as up-to-date as possible by relying on road authorities’ data quality expertise and their local mandates for data quality (i.e., completeness, positional accuracy, attribute accuracy, etc.).

The goal of the Road Centerline Data Standard for Oregon is to ensure that transportation data applications are able to acquire data from disparate sources, use and display the results in an appropriate manner for the required need, and rely on local data-maintaining resources to assure that the most current data set is available for emergency planning and routing applications, infrastructure management, and resource planning.

1.2 Relationship to Existing Standards

The Federal Geographic Data Committee (FGDC) has prepared a document entitled “The NSDI Framework Transportation Identification Standard,” which serves as a reference for the Oregon standard. Oregon is participating in the creation of the Geospatial One-Stop Modeling Advisory Team for Roads’ Geographic Information Framework Data Content Standards for


November 2013

Transportation: Roads, the draft ANSI standard for a web-based exchange of geospatial roads data. All geospatial data sets developed under the Oregon Road Centerline Data Standard must adhere to the recently adopted Oregon Metadata Standard, once the implementation plan for that standard is published. Furthermore, the ORCDS has been written with consideration towards other standards being developed through the Geospatial Data Standards Development Process. Specifically, these include the Address Standard and the Governmental Unit Boundary Data Exchange Standard.

1.3 Description of Standard

The Oregon Road Centerline Data Standard (ORCDS) describes the essential elements and data structure necessary to adequately describe, produce, and use roads centerline data produced in Oregon (in support of Oregon mandates). The ORCDS is primarily concerned with a core set of geospatial information, including geometry, to support the need for an accurate and current representation of the extent and connectivity of Oregon’s traveled road infrastructure. Diverse applications to be supported initially include the route-milepost and address range methods of linear referencing and the digital interaction of the road centerline data set with the hydrography data set(s). Network connectivity solutions to support oversize vehicle routing, emergency response (computer aided dispatch, or CAD), and planning for intelligent transportation system deployments are anticipated as future applications that this data standard and data structure will support.

1.4 Applicability and Intended Use of Standard

For Oregon geospatial data, this standard is applicable to the feature set(s) that represent(s) the centerline of the travel way of (hereinafter referred to as road centerline or centerline) a road (with “road” being defined by the contributing road authority, see Appendix B).

The intended use of this standard has three key components. First, it will enable data users to understand how road centerline data sets were produced locally, how the locally produced and maintained data sets can be assembled into regional and statewide data collections, and which uses the producers deemed appropriate for the data set. Second, it will guide accurate documentation of road centerline data sets that are produced for and in Oregon. And third, it will facilitate the discussion of additional geospatial data standards surrounding the attributes that the centerline road data standard optionally provides for linear referencing (e.g., standards for capturing route-milepost information, address ranges, address points, etc.).

1.5 Standard Development Procedures

The Oregon Framework Implementation Team Transportation Subcommittee (T-FIT) is comprised of representatives from federal, state, regional, and local governmental agencies. This team created the first draft of a minimal roads centerline data structure, and published the draft standard via email lists, open meetings, and through the Oregon Geospatial Data Clearinghouse website, at: (http://www.oregon.gov/ODOT/TD/TDATA/pages/gis/TransFIT.aspx). The prototype data structure was included as a component of all of the T-FIT data development pilot


November 2013

projects authorized by the Oregon Geographic Information Council during the 2001-2003 biennium (Appendix A).

Beginning in the mid-1990’s, the Oregon Road Base Information Team Subcommittee (ORBITS) met to discuss developing a shared data model for transportation data in Oregon. This effort brought the appropriate road data “players” to the table, but a lack of committed resources led to its gradual decline. In 2002, using the data development funding provided by OGIC and the priorities assigned by the Framework Implementation Team, T-FIT committed to the creation of a centralized database (hosted by the Oregon Department of Transportation) and several pilot projects to test the viability of the prototype data structure.

1.6 Maintenance of Standard

The Oregon Road Centerline Data Standard will be revised on an as-needed basis, initiated by members of the standards process or through a logical expansion based on further attainment of broad participation in the creation of the Road Centerline Dataset. It is anticipated that as road centerline data are collected at higher spatial accuracies, as geospatial applications mature, and as technology for capturing that higher resolution data improves, the standard will need to be updated. The update process could explore the range of attributes considered to be minimal or the refinement of attribute quality in the existing standard.

2.0 Body of the Standard

2.1 Scope and Content of the Standard

The scope of the ORCDS is for publicly available vector data in Oregon with a horizontal spatial accuracy of +/- forty feet or better at a 95% confidence level, which is the USGS National Map Accuracy Standard for their 7.5 minute quadrangle map series.The unique identification of transportation line features is also within the scope of this standard (as identified and discussed in the prototype data structure in Appendix A). The content is focused on the essential data and metadata elements required for individual (locally maintained) data sets as well as the centralized (regional and/or statewide) data sets.

2.2 Need for the Standard

The Oregon Transportation community has for some time discussed the need for a straightforward means by which to share road centerline attribution between road authorities and jurisdictions. The exchange of this valuable information (including the geometry of a given jurisdiction’s line work and the many operational and descriptive attributes routinely collected and related to those geometries) will be greatly simplified through the adoption of a minimal data specification and the focus of effort brought by focusing on a single business application – addressing in support of the emergency planning and response.


November 2013

2.3 Participation in Standards Development

The development of standards for transportation-related geospatial data has been underway at many levels for many years. For planning purposes, federal road authorities have compiled several “standard” centerline data sets, including the National Highway Planning Network (NHPN) developed at Oakridge National labs for interstate transportation planning and the Highway Performance Monitoring System (HPMS) developed by the Federal Highway Administration to track performance of the ground transportation network. For addressing attributes along centerline representations of roads, the US Census Bureau has created a “standard” data set, known most recently as TIGER (Topologically Integrated Geographic Encoding and Referencing), to support the collection of the decennial census. Currently, there are several federal initiatives underway to create broad transportation standard documents (the FGDC/NDSI Framework, which is focused on the local, distributed data model for data and data standard development, as well as the Geospatial One-Stop’s Modeling Advisory Team-Roads’ effort to create a data content standard, which is focused on the Internet and the Extensible Markup Language (xml) as a means of data exchange).

Oregon’s Road Centerline Data Standard, and the process by which it will be updated/enhanced is open to all agencies concerned with the development, maintenance, and application of road centerline data to the resolution of transportation-related business functions. As with all Oregon framework standards, public review of and comments on the Oregon Road Centerline Data Standard is encouraged. An outline of Oregon’s process for the development and extension of geospatial data standard can be found at: (http://www.oregon.gov/DAS/CIO/GEO/standards/docs/fit_standard_development_process-v1.1.pdf).Participation in the T-FIT spans the spectrum of governmental agencies in Oregon. Currently, T-FIT is led by the Oregon Department of Transportation, with important time and resource commitments from the Oregon Department of Administrative Services, , the Oregon Office of Emergency Management, METRO, LCOG, various county GIS shops and county PSAPs, the US Bureau of Land Management, the US Forest Service, the US Geological Survey. and various other private industries and other non-governmental groups.

2.4 Integration with Other Standards

The Oregon Road Centerline Data Standard follows the same format as other Oregon Framework layers. The specifics of the ORCDS are related to the Hydrography and Metadata standards, mainly in relation to the position of crossing points (bridges and culverts) and in the type and extent of data source specifications, respectively. The ANSI Geographic Information Framework Data Content Standards for Transportation Roads (draft) can provide guidance on the feature-level relationships between point and vector representations of road features and the metadata schema required to share them through the Geospatial One-Stop portal. The Inter-governmental Resource Information Coordinating Council’s draft for Transportation data standards located at: http://www.reo.gov/gis/projects/Roads/index.htm provide important linkages to the transportation data requirements for federal road authorities under the influence of the Northwest Forest Plan. And the data standards development efforts of our colleagues in Washington (led by the Washington State Department of Transportation) continue to inform and


http://www.reo.gov/gis/projects/Roads/index.htm%20

http://www.oregon.gov/DAS/CIO/GEO/standards/docs/fit_standard_development_process-v1.1.pdf

November 2013

influence this standard. The relationship with other non-transportation data standards is primarily geo-referencing for spatial analysis.

2.5 Technical and Operation Context

2.5.1 Data EnvironmentThe data environment for ORCDS is a vector model, comprised of topological linework representing road centerlines. The exchange medium for road centerline data files is the, ESRI personal geodatabase, ESRI file geodatabase, Intergraph warehouse or ESRI shapefile, which is a public domain data structure relating lines and feature attribution (including shape geometry). This exchange medium is supported by all known GIS software suites in use in Oregon. Information about the technical specification for the ESRI shapefile can be found at: http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf.

2.5.2 Reference SystemsThe data is re-projected from the various source reference systems to the Oregon Lambert Conformal Conic (OGIC) projection and NAD83 data and is distributed as such (http://www.oregon.gov/DAS/CIO/GEO/pages/coordination/projections/projections.aspx).

2.5.3 Global Positioning Systems (GPS)Many different tools are available for capture of road centerline data. The choice of the appropriate tool is to be determined by the individual capturing the data. Of equal importance, are the qualifications of the individual performing the data capture. ORS 672 has established the qualifications to perform the data capture. If the data captured is to be used in an authoritative manner, it must be gathered by a licensed practitioner or under the direct supervision of a licensed practitioner. If the data captured will be used in a non-authoritative manner, licensing is not required. Regardless of the use of the captured data, it is imperative that the appropriate metadata be associated such that future use of the data is not used inappropriately or miss-understood.

2.5.4 Integration of ThemesThe primary Framework data theme required by the ORCDS is Administrative Boundaries. Many information resource technologies and funding authorities rely on state, county, region, district, and municipal boundaries to determine the appropriate distribution of road construction and maintenance funds. It is essential that the boundaries used to determine fund availability can be integrated with the road centerline data set. Similarly, the Hydrography Framework theme must integrate spatially at key crossing points referring to bridge and culvert locations (as noted above).

2.5.5 EncodingTo date, no specific encoding scheme for ORCDS has been adopted. However, it is the intent of the Oregon standards process that this standard is in alignment with the encoding schema(s) being developed through the Geospatial One-Stop’s Modeling Advisory Team-Roads effort.


http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf

November 2013

2.5.6 ResolutionThe resolution of the ORCDS data set will vary according to local data capture methods and the business applications that those data must support. It is the intention of the centerline data standard to allow regional, county, and municipal data sets to nest within the data collected at a statewide scale. Resolution will be tracked as a metadata element, and it is intended to reflect the best available attribution related to centerline road data (including geometry).

2.5.7 AccuracyAs with resolution, the intention of the ORCDS is to support varying levels of positional and attribute accuracy. However, it is essential to the success of the data standard that all aspects of centerline roads data be completely documented (either at the feature or data set level). Minimal positional accuracy is to reflect National Map Accuracy Standards for the 1:24000 USGS quadrangle series (+/- 40 feet for 95% of well-known features).

2.5.8 Edge MatchingThe ORCDS is intended to be seamless across Oregon. Similar data sets from adjacent states using the same projection and horizontal/vertical datum should merge with the ORCDS data without gaps. Edge matching between jurisdictional submissions to the data steward managed and determined by the data steward to create a seamless network between dataset by modifying the minimum number of records necessary to accomplish a seamless network. This data will be flagged in the database that it has been modified and at a time where data submitted provides a seamless continuity, data modified by the steward will be replaced with original, unmodified data.

2.5.9 Feature Identification CodeFollowing Federal Geographic Data Committee guidelines for the transportation data content, the feature identification code will be the concatenation of three separate fields: an agency identifier, line identifier, and a road identification number. The agency identifier – 5 characters in the form NNCCC (e.g., “41A22”) – will be specified for each road authority in Oregon. The “41” represents the Oregon FIPS state code. “CCC” will be an assigned alphanumeric code for each individual road agency that has authority to create and maintain road features somewhere in the state. The agency identification table will be created and maintained by the data steward for this theme (currently ODOT). The line identifier – “S”will indicate a two-dimensional segment. Finally, the road identification number is currently specified to be a 9-digit number that is locally created and maintained. As a concatenated field with these three components, the feature identification code should uniquely identify transportation features and related attributes for the Oregon Road Centerline Data Standard.

2.5.10 AttributesAttributes are categorized as: lines.

2.5.10.1LinesLines are geospatial objects that represent the centerline of the road that is being digitally captured in compliance with this standard. Lines can be uniquely identified using the Feature Identification Code described in Section 2.5.9. These are the primary features to which road characteristics will be attributed.


November 2013

2.5.11 Transactional UpdatingTransactional updating processes are being explored as a functional component of the Oregon Road Centerline Database. This database is the manifestation of the ORCDS and will be hosted at the Oregon Department of Transportation.

2.5.12 Records ManagementPast versions of the Oregon road centerline data set will be traceable through the relational database management system hosted by the data steward, since this functionality is essential to the business applications that Oregon DOT requires this database to support. At this time, discussions continue around the time period needed for archival copies of the database, but archiving is mandated under Oregon Rules and Statutes and through Oregon Administrative Rules. At the minimum, those mandates will be satisfied. Archived datasets may be made available through the Oregon University System.

2.5.13 MetadataThe ORCDS standard follows the Oregon Core Metadata Standard for geospatial data. Metadata detailing the characteristics and quality of submitted road centerline data must be provided. Metadata should make every effort to meet the more rigorous standards set forth in the Federal Metadata Content Standard, where feasible. Metadata must provide sufficient information to allow the user to determine if that geodata set will meet the intended purpose, as well as telling the user how to access the data.

3.0 Data Characteristics

The data characteristics specified below are subject to revision based on the documented experiences of the T-FIT Pilot Projects. Several related standards (e.g., an Oregon Addressing Standard, an Oregon Structural Footprint Standard, and others) may be required in order to systematically support the emergency planning and routing applications mentioned earlier.

3.1 Minimum Graphic Data Elements

3.11 LinesITEM NAME TYPE WIDTH DescriptionSHAPE Shapeline Ordered string of coordinate pairs representing road segment

shape/geometry (generated internally by GIS software)

3.2 Minimum Attribute or Non-graphic Data Elements (If available)

3.2.1 LinesITEM NAME TYPE WIDTH DescriptionUNIQUE_ID Number 9 Framework unique identifier (generated by Framework data steward)LENGTH Number 16 Calculated length in International Feet (to 3 decimal places)LOCAL_ID Number 9 Local road centerline segment feature identifier, unique and permanent

to the segment at the local level (generated by road authority/data custodian)


November 2013

RDOWNER String 25 Entity that owns the segmentRDMANAGER String 25 Entity responsible for maintenance of segmentFEDIRP String 15 Prefix directional component of segment nameFENAME String 50 Road name component of segment nameFETYPE String 15 Road type component of segment name (eg. ST, AVE, CT etc.)FEDIRS String 15 Suffix directional component of segment nameALIASDIRP String 15 Prefix directional component of segment alias nameALIASNAME String 50 Road name component of segment alias nameALIASTYPE String 15 Road type component of segment alias name (eg. ST, AVE, CT etc.)ALIASDIRS String 15 Suffix directional component of segment alias nameRDNUMBER String 15 Number assigned to a collection of segments LLOWADD Number 10 Left low address rangeLHIGHADD Number 10 Left high address rangeRLOWADD Number 10 Right low address rangeRHIGHADD Number 10 Right high address rangeLEFTZIP String 10 Area descriptor to aid geocoding, left side of centerline (could be ZIP)RIGHTZIP String 10 Area descriptor to aid geocoding, right side of centerline (could be ZIP)LOCL LRS String 50 RDOWNER identifier for linear referencingBEGMP Decimal 5.3 Beginning RDOWNER mile measure (to 3 decimal places)ENDMP Decimal 5.3 Ending RDOWNER mile measure (to 3 decimal places)FIPS_LCITY String 5 City FIPS code of left side of segmentFIPS_RCITY String 5 City FIPS code of right side of segmentFIPS_LCNTY String 3 County FIPS code of left side of segmentFIPS_RCNTY String 3 County FIPS code of right side of segmentFIPS_STATE String 2 State FIPS code for segmentFUNC_CLASS Number 2 Functional Class assigned by road ownerMODE CD String 2 Code identifying type of transportation feature (road, rail, foot path ect)CREATE_DT Date 8 Date that segment geometry/attribution first created (MMDDYYYY)UPDATE_DT Date 8 Date that segment geometry/attribution last modified (MMDDYYYY)RETIRE_DT Date 8 Date that segment geometry/attribution retired (MMDDYYYY)STATUS_CD String 1 Code indicating operational condition of road segmentMOD_FLG Boolean 1 Flag indicating spatial modification was made for connectivitySTATUS String 1 Accessibility of road segment to vehicular travel

3.3 Optional Graphic Data ElementsNone specified at this time

3.4 Optional Attribute or Non-graphic Data Elements

3.2.1 LinesITEM NAME TYPE WIDTH DescriptionNone specified at this time


November 2013

Data Dictionary

SHAPE: This field represents the collection of vertices that comprise the linear feature. It is considered an “internal” field, since it is captured by proprietary digitizing software in a manner consistent with its topological algorithms. This topology generally takes the form of Cartesian coordinates (matched x-y-z pairs) in the projection units specified. For T-FIT pilot projects, the OGIC exchange standard projection (a customized Lambert conical projection) is required for the final implementation.

LOCAL_ID: This field represents the local segment identifier for the transportation framework theme. This identifier is a permanent and persistent identifier that is assigned to a segment feature and does not change over time. This field will serve as one means by which to crosswalk between locally maintained feature attribution that is not part of the transportation minimal data structure.

UNIQUE-ID: This field represents the unique segment identifier for the transportation framework theme. Following Federal Geographic Data Committee guidelines for the transportation data content, this identifier will be the concatenation of three separate fields: an agency identifier, a line identifier, and a road ID number. The agency identifier – 5 characters in the form NNCCC (e.g., “41A22”) – will be specified for each road authority in Oregon. The “41” represents the Oregon FIPS state code. “CCC” will be an assigned alphanumeric code for each individual road agency that has authority to create and maintain road features somewhere in the state. The agency identification table will be created and maintained by the data steward for this theme (currently ODOT). The line identifier – 1 character ( “S”) – will indicate the record is a two-dimensional segment. And the road ID number is currently specified to be a 9-digit number that is locally created and maintained As a concatenated field with these three components, we should have a unique way to identify and relate attributes to the transportation theme.

LONGITUDE: “Longitudinal” planar component of point location on earth’s surface, in a known projection system (documented in metadata) - for Oregon Lambert projected data sets, a field width of 10.6 is sufficient to capture this variable

LATITUDE: “Latitudinal” planar component of point location on earth’s surface, in a known projection system (documented in metadata) - for Oregon Lambert projected data sets, a field width of 10.6 is sufficient to capture this variable.

LENGTH: Calculated length of transportation segment features (in map units, to three decimal places).

RDOWNER: For transportation linear segments, this is the AGENCY identification code that owns the road facility

RDMANAGER: For transportation linear segments, this is the AGENCY identification code that manages the road facility FEDIRP: Primary feature directional prefix as defined by the


November 2013

RDOWNER. This should be the directional designator as seen in the common road name (i.e. NE Lombard Ave.).

FENAME: Primary feature name as defined by the RDOWNER. This should be a complete text representation of the common road name (not including directional prefix or suffix or feature type (Rd, St, Ave, etc), rather than a reference to internal AGENCY or RDOWNER naming conventions, and will provide (combined with FEDIRP, FETYPE AND FEDIRS, one of the linear referencing methodologies for georeferencing other (non-framework) road attributes).

FETYPE: Primary feature type as defined by the RDOWNER. This should be the feature type designator as seen in the common road name (i.e. NE Lombard Ave.).

FEDIRS: Primary feature directional suffix as defined by the RDOWNER. This should be the directional suffix designator as seen in the common road name.

ALIASDIRP: Secondary feature directional prefix as defined by the RDOWNER. This should be the directional designator as seen in the common road name (i.e. NE Lombard Ave.).

ALIASNAME: Secondary feature name as defined by the RDOWNER. This should be a complete text representation of the common road name alias(not including directional prefix or suffix or feature type (Rd, St, Ave, etc), rather than a reference to internal AGENCY or RDOWNER naming conventions, and will provide (combined with FEDIRP, FETYPE AND FEDIRS, one of the linear referencing methodologies for georeferencing other (non-framework) road attributes).

ALIASTYPE: Secondary feature type as defined by the RDOWNER. This should be the feature type designator as seen in the common road name (i.e. NE Lombartd Ave.).

ALIASDIRS: Secondary feature directional suffix as defined by the RDOWNER. This should be the directional suffix designator as seen in the common road name.

RDNUMBER: An identifier assigned to a segment that indicates the business designation of the segment or segments that relate them (i.e. county road number, state highway number) as designated by the RDOWNER.

LLOWADD: Low address range on the left side of the transportation linear segment (as one moves from the F_NODE to the T_NODE).

LHIGHADD: High address range on the left side of the transportation linear segment (as one moves from the F_NODE to the T_NODE).

RLOWADD: Low address range on the right side of the transportation linear segment (as one moves from the F_NODE to the T_NODE).

LHIGHADD: High address range on the right side of the transportation linear segment (as one moves from the F_NODE to the T_NODE).


November 2013

LEFTZIP: Zip code that is on the left side of the transportation linear segment (as one moves from the F_NODE to the T_NODE).

RIGHTZIP: Zip code that is on the right side of the transportation linear segment (as one moves from the F_NODE to the T_NODE).

LOCL_LRS: Linear referencing system identifier as designated by RDOWNER.

BEGMP: Beginning mile measure (to three decimal places) for the transportation linear segment, as designated by RDOWNER.

ENDMP: Ending mile measure (to three decimal places) for the transportation linear segment, as designated by RDOWNER.

FIPS_LCITY: City identified as containing transportation linear segment, as designated by RDOWNER.

FIPS_RCITY: City identified as containing transportation linear segment, as designated by RDOWNER.

FIPS_LCNTY: County FIPS code for the left side of the transportation linear segment, as designated by RDOWNER.

FIPS_RCNTY: County FIPS code for the right side of the transportation linear segment, as designated by RDOWNER.

FIPS_STATE: State FIPS code for transportation linear segment, as designated by RDOWNER.

FUNC_CLASS: Roadway functional class for transportation linear segment, as designated by RDOWNER.

CREATE_DT: Date the road segment was created or came into operation in the data as designated by the RDOWNER.

UPDATE_DT: Date the road segment was updated or modified in the data as designated by the RDOWNER.

RETIRE_DT: Date the road segment was retired or taken out of operation in the data as designated by the RDOWNER.

MODE_CD: Code indicating the type of transportation facility the line is representing (road, rail, foot path etc.) as designated by the RDOWNER.

MOD_FLG: Flag indicating that a segment’s geometry has been modified by the steward to facilitate a seamless network between different jurisdiction’s data.


November 2013

STATUS_CD: Status code indicating whether the road segment is operational, retired, proposed or closed as designated by the RDOWNER.


November 2013

Appendix B: Definitions of Terms

Term Definition

Accuracy Absolute - A measure of the location of features on a map compared to their true position on the face of the earth.Relative - A measure of the accuracy of individual features on a map when compared to other features on the same map.

Address Actual or Real - The simple, everyday element that designates a specific, situs location, such as a house number or an office suite.Range - Numbers associated with segments of a digital street centerline file that represent the actual high and low addresses at either end of each segment.Situs - The proper or original position of a specific location. An element that designates a fixed site, such as the address of a property or building.Theoretical - A location that can be interpolated along a street centerline file through geocoding software.Vanity - A special address that is inconsistent with or an exception to the standard addressing schema.

Address matching See Geocoding.

Attribute Attributes are the properties and characteristics of entities.

Custodian Agency responsible for developing and/or maintaining the data.

Entity A data entity is any object about which an organization chooses to collect data.

FGDC Federal Geographic Data Committee.

FTSeg Framework Transportation Segment, specified as a fundamental object in the Federal Geographic Data Committee’s NSDI Framework Transportation Identification Standard. The segments represent the


November 2013

underlying digital road structure for the NSDI identification standard.

Geocoding A mechanism for building a database relationship between addresses and geospatial features. When an address is matched to the geospatial features, geographic coordinates are assigned to the address.

Geospatial feature A point, line or polygon stored within geospatial software.

Geospatial software Mapping software with analytical capabilities.

Line A feature built of vectors connecting at least two vertices.

Normalize The decomposition of data structures into new data structures that exhibit simpler properties.

NSDI National Spatial Data Infrastructure. This effort of the FGDC to create and implement a shared data collection and maintenance resource for geospatial data sets.

Parcel In land ownership mapping, a parcel is a tract of land under one ownership. It may be a combination of two or more tracts acquired by separate deeds.

Parity A characteristic of a set of addresses or address ranges in which the numbers are either odd or even.

Polygon A plane surface that is circumscribed by three or more intersecting lines.

RDBMS Relational database management system.

Road Generally, this is the physical real-world feature that can be used for vehicular travel. However, this general definition is subject to the road owner’s authority to define its accessibility (thus, while navigable by a vehicle, some linear features may be “trails” and thus excluded from the ORCDS). The federal definition used by ODOT for their purposes is appended below.


November 2013

Steward The agency or entity responsible for integrating like datasets into a single dataset.

Unique identification number Every element is assigned an identification number within the computer software that is unique to it.

Code of Federal Regulations23 CFR 460Sec. 460.2 Definitions.

As used in this part:

(a) “Public road” means any road under the jurisdiction of and maintained by a public authority and open to public travel.

(b) “Public authority” means a Federal, State, county, town, or township, Indian tribe, municipal or other local government or instrumentality thereof, with authority to finance, build, operate or maintain toll or toll-free highway facilities.

(c) “Open to public travel” means that the road section is available, except during scheduled periods, extreme weather or emergency conditions, passable by four-wheel standard passenger cars, and open to the general public for use without restrictive gates, prohibitive signs, or regulation other than restrictions based on size, weight, or class of registration. Toll plazas of public toll roads are not considered restrictive gates.

(d) “Maintenance” means the preservation of the entire highway, including surfaces, shoulders, roadsides, structures, and such traffic control devices as are necessary for its safe and efficient utilization.

(e) “State” means any one of the 50 States, the District of Columbia, Puerto Rico, the Virgin Islands, Guam, and American Samoa. For the purpose of the application of 23 U.S.C. 402 on Indian reservations, “State” and Governor of the State” include the Secretary of the Interior.


November 2013

Appendix C: Referenced Documents and Web links

Federal Geographic Data Committee: NSDI Framework Transportation Identification Standard - http://www.bts.gov/gis/fgdc/web_intr.html

Geospatial One-Stop Modeling Advisory Team for Roads’ Geographic Information Framework Data Content Standards for Transportation: Roads -……….. http://www.geo-one-stop.gov/Standards/Transportation/roads.pdf

Inter-governmental Resource Information Coordinating Council’s (IRICC): draft Transportation data standards - http://www.reo.gov/gis/projects/Roads/index.htm

US Geological Survey: National Map Accuracy Standard - http://rockyweb.cr.usgs.gov/nmpstds/acrodocs/nmas/NMAS647.PDF


http://rockyweb.cr.usgs.gov/nmpstds/acrodocs/nmas/NMAS647.PDF

http://www.geo-one-stop.gov/Standards/Transportation/roads.pdf

http://www.bts.gov/gis/fgdc/web_intr.html