Spatial Data Transfer Standard - Transportation Network Profile

Thursday, September 6, 2012

DRAFT
Version 1.1
February 1, 1996

Prepared By:
Service Assessment Division
John A. Volpe National Transportation Systems Center
Research and Special Programs Administration

U.S. Department of Transportation
Cambridge, MA 02142-1093

Prepared For:
Federal Geographic Data Committee
Ground Transportation Data Subcommittee

in Support of:
U.S. Department of Transportation
Bureau of Transportation Statistics

The Topological Vector Profile was used as a guide in the development of this draft Transportation Network Profile

1 Introduction

2 Spatial Data Concepts

3 Spatial Data Quality

4 General Specification (The Transfer Model)

5 Transfer Module Specification

6 ISO 8211 Specific Decisions

ANNEXES

A: The Data Dictionary Transfer

B: Encoding Multi-valued Attributes

C: An Example of Attributing Feature Objects with Entity Labels

D: Arc Option

F: Graphic Representation Option

1 Introduction

An SDTS profile, in general terms, is defined as a limited subset of the Spatial Data Transfer Standard, designed for use with a specific type of data. Specific choices are made for encoding possibilities not addressed, left optional, or left with numerous choices within Parts 1, 2, and 3 of SDTS.

An SDTS profile shall provide for the transfer of files, records, fields and subfields with the following objectives:

(a) to encode in a standard format;
(b) to provide for machine and media independence;
(c) to accompany the data with their description;
(d) to preserve all meaning and relationships of the data; and
(e) to keep both fields and records to an appropriate maximum length.

1.1 Scope and Definition

The Transportation Network Profile (TNP) contains specifications for an SDTS profile for use with geographic vector data with network topology.

1.1.1 Geographic Data

"Geographic" relates to "real-world" features, rather than a symbolized map graphic. The data may be derived from a cartographic product (map), but the purpose of the data is not to convey the map graphic, but rather information about the geographic features displayed on the map.

1.1.2 Vector Data with Network Topology

The data are represented by vector objects which comprise a network or planar graph (see Part 1 definitions 2.3.4.5.1 and 2.3.4.5.3). Excluded are raster data and geometry-only vector data.

This draft profile is organized using the same major headings found in Part 1. Specific discussions regarding encoding possibilities in Part 1 are grouped under each major heading and will include specific references to Parts 1, 2, or 3 where necessary for clarification.

1.1.3 Profile Annex Options

Annexes D (Arc Option) and F (Graphic Representation Option) contain permitted options to this profile. These options implement additional features of the SDTS which may be useful in some transfers. Encoders and decoders are not required to implement these options to be conforming to this profile. However, the presence of these options shall be tolerated by decoders.

1.2 Conformance

(see also Part 1, Section 1.2, Conformance)

There are three types of products which can be tested for conformance to this profile:

1.2.1 Transfer Conformance

In order to conform to this Transportation Network Profile, an SDTS transfer shall:

1.2.2 Encoder Conformance

In order to conform to this Transportation Network Profile, an SDTS encoder shall:

1.2.3 Decoder Conformance

In order to conform to this Transportation Network Profile, an SDTS decoder shall:

2 Spatial Data Concepts

(see also Part 1, Section 2, Spatial Data Concepts)

2.1 Spatial Objects

(see also Part 1, Section 2.3, Definition of Spatial Objects)

The following table indicates which spatial objects are required, optional, or not permitted for this profile.

Object Representation Code	Require	Optional	Not Permitted
NP¹, NL, NE - Point, Label Point, Entity Point		X
NA - Area point		X
NO - Node, planar NN - Node, network	X (one of)
LS - String ²			X
LE - Complete chain		X
LL - Area chain		X
LQ - Link LW - Network chain, planar graph LY - Network chain, non-planar graph	X (one of)
AC,AE,AU,AB - All arcs ²			X
RA, RM, RS, RU - All Rings			X
PG - G-polygon			X
PR - GT-polygon (of rings)			X
PC - GT-polygon (of chains)		X
PU - Universe polygon (of rings)			X
PW - Universe polygon (of chains)		X
PV - Void polygon (of rings)			X
PX - Void polygon (of chains)		X
GI,GJ,GK,GM - Raster objects			X
FF - Composite		X

2.2 Layers and (or) Partitions

Data are to be represented by one or more networks or planar graphs (see Part 1 definition 2.3.4.5.1 or 2.3.4.5.3). A single network shall be used to transfer:

More than one network and/or more than one horizontal partition may be included within a single transfer.

3 Spatial Data Quality

(see also Part 1, Section 3, Spatial Data Quality)

3.1 Lineage

Separate processing histories pertaining to, for example, separate data layers, shall be documented.

3.2 Positional Accuracy

If data are collected from a graphic map, then a statement explaining that the data may contain cartographic offsets shall be included in the positional accuracy portion of the data quality report.

3.3 Attribute Consistency

Specifies the accuracy of individual entity object values.

3.4 Logical Consistency

The technique used to verify topology shall be documented.

3.5 Completeness and (or) Logical Consistency

Report and explain data encoding practices, especially in object records, which might seem contrary to, or to deviate from, normal, standard or preferred practices.

4 General Specification (The Transfer Model)

(see also Part 1, Section 4.1.3, The Transfer Model)

4.1 Standard Module Names

SDTS Transportation Network Profile module names (the unique name of each individual module) shall be standardized, and consist of four characters. All letters in module names shall be upper case. For modules carrying spatial objects, the module name shall begin with the same two characters as the object representation code for the objects. The other valid two character Object Representation codes are shown in Section 2.1 of this profile, Spatial Data Concepts, Spatial Objects. The last two characters of the module name are free to distinguish different modules/files.

Non-object modules shall be named the same as the primary module field mnemonic (ISO 8211 Tag) (see Part 1, Sections 5.2 and 5.3, Global Information and Data Quality Modules, and Part 3 Table 1):

More than one module of the following types may exist:

The last character shall change to reflect more than one module of the same type.

4.2 Order of Records, Fields, and Subfields within Modules

³¹

4.3 Coordinate Frame of Reference

(see also Part 1, Section 4.1.3.5, Spatial Registration)

There shall be only one external coordinate frame of reference within a transfer. The external spatial reference system shall be one of the systems which make up conformance level 1: latitude-longitude (geographic), Universal Transverse Mercator/Universal Polar Stereographic (UTM/UPS), or State Plane Coordinate Systems (SPCS.) If different horizontal partitions are included within the transfer, each may have its own internal coordinate system (referenced to the external spatial reference system by translation and scaling parameters in an Internal Spatial Reference module record).

4.4 Spatial Address (Coordinate) Format

(see also Part 1, Section 4.1.3.5, Spatial Registration, and Section 5.2.4, Spatial Reference)

4.4.1 External Spatial Reference

Transportation Network Profile transfers shall be restricted to the use of conformance level 1 for horizontal external coordinates. To explicitly state this restriction,

Note that Part 1 restricts the unit of measurement in the external reference system to meters for all Z coordinates and X and Y coordinates when using the State Plane Coordinate System. However, coordinates can be stored in the internal reference system in feet as long as the appropriate scaling factors are used in the Internal Spatial Reference module.

4.4.2 Internal Representation of Spatial Addresses

No restriction is placed on the data type format of internal spatial addresses. (The Topological Vector Profile (SDTS, Part 4) requires that internal representation of X, Y and Z coordinates shall be as 32-bit signed implicit fixed point binary numbers ("BI32" SDTS data type).)

4.4.3 Restrictions on X and Y Subfields

The X subfield of spatial addresses shall only be used to transfer longitude and easting values. The Y subfield shall only be used to transfer latitude or northing.

4.5 Null (and Like) Values

(see also Part 1, Section 4.1.3.3.9, Nulls and Defaults)

When a transfer uses fixed length subfields (e.g. to carry attribute data linked to the various objects), then special consideration must be given to handling Null values. The SDTS default option for implementing nulls is not feasible in this case. When appropriate, the following text shall be encoded in the Comment subfield of a Logical Consistency module record, and implemented:

When a subfield, either user-defined in Attribute Primary and Attribute Secondary module records, or in other SDTS module records, is implemented as fixed-length, the following null scheme is used: (a) when information to be encoded in the subfield is known to be not applicable (undefined, not relevant), then the subfield is valued by a string of spaces; and (b) when the information to be encoded is relevant but unknown (or missing), then the subfield is valued by a string of question marks "?".

The Logical Consistency module with the above text shall be associated to applicable modules through the Catalog/Cross Reference module.

4.6 Attribute Usage

(see also Part 1, Annex B Section B.6 Suggested Code Sets)

All agencies shall use established FIPS codes where applicable, such as FIPS PUB 6-4 (31 August 1990) Counties and Equivalent Entities Codes or FIPS PUB 10-3 (9 February 1984) Countries, Dependencies, Areas of Special Sovereignty and their Principal Administrative Division.

4.7 Relationships Between Modules and Networks

4.8 Multi-valued Attributes

Attributes that can be multi-valued shall be in their own tables, along with any other attributes that are functionally dependent. An attribute's cardinality and functional dependence is solely determined by the data encoder's data model. As an example of multi-valued consider an entity "road" with the attribute "name" that has the two values "10th Street" and "Highway BB". Attributes are functionally dependent when the value of one attribute determines the value of another attribute. For example, say attribute "route_number" is dependent on "name", which means the value of "name" determines the value for "route_number". (See Annex B for an example of encoding multi-valued attributes.)

4.9 Attributing Feature Objects with Entity Labels

The SDTS implementation of the entity-attribute-attribute value feature model provides a means of directly assigning attribute values to specific feature objects. The type of entity which the object represents is specified indirectly through Data Dictionary/Schema module records. The assumption is that each entity type represented is characterized by attributes. In some cases, however, all that may be encoded about a feature is its entity type with no other attributes.

For use with features with entity labels but no attributes (and optionally in cases where different features share the same attributes), two generic attribute labels are defined by this profile: "ENTITY_LABEL" and "ENTITY_AUTHORITY" (an entity label may only be unique when coupled with the authority for its definition). The authority for the definition of these two attribute labels is this profile, designated in Data Dictionary/Schema records (Attribute Authority subfield) as "SDTS/TNP". (No Data Dictionary/Definition or Data Dictionary/Domain records are necessary for these two attribute labels.) The domain of attribute values for these attributes shall be any entity label and its authority as defined in either SDTS Part 2 or Data Dictionary/Definition records included with the transfer (either internally or externally). When all entity labels in a single transfer are defined by the same authority, the ENTITY_AUTHORITY attribute may be omitted in the attribute records.

Annex C contains an example of attributing feature objects with entity labels.

5 Transfer Module Specification

This section addresses the module level restrictions as they apply to a transfer. Certain requirements of Part 1 are repeated here for clarity. Following the module level restric tions/requirements, any restrictions on field/subfield values are noted for each module. The order of coverage follows that of Part 1, Section 5.

The following table contains the inclusion/exclusion, and cardinality rules for each module. The standardized modules names are included, along with the minimum number and the maximum number of occurrences of the module type. A lowercase "n" indicates that the upper limit is user defined. Any lowercase letters or dots in the module name has the meaning explained in Section 4, Standard Module Names.

Module Type	Name	Min. No.	Max. No.
Global Information Modules (see also Part 1, Section 5.2, Global Information Modules)
Identification	IDEN	1	1
Catalog/Directory	CATD	1	1
Catalog/Cross Reference	CATX	??	1
Catalog/Spatial Domain	CATS	1	1
Security	SCUr	??	n
Internal Spatial Reference	IREf	1	n
External Spatial Reference	XREF	1	1
Registration	--	??	??
Spatial Domain	SPDm	??	n
Data Dictionary/Definition	DDDf	??	n³
Data Dictionary/Domain	DDOm	1⁴	n⁴
Data Dictionary/Schema	DDSh	1	n⁴
Transfer Statistics	STAT	1	1
Data Quality Modules (see also Part 1, Section 5.3, Data Quality Modules)
Lineage	DQHl	1	n
Positional Accuracy	DQPa	1	n
Attribute Accuracy	DQAa	1	n
Logical Consistency	DQLc	1	n
Completeness	DQCg	1	n
Attribute Modules (see also Part 1, Section 5.4, Attribute Modules)
Attribute Primary	A...	1	n
Attribute Secondary	B...	??	n
Composite Modules (see also Part 1, Section 5.5, Composite Modules
Composite Module	FF..	??	n
Vector Modules (see also Part 1, Section 5.6, Vector Modules)
Point-Node	NE.., NL.., NP.., NA..	??	n
Planar Node or Network Node	NO.., NN..	1	n
Link or Network Chain	LQ.., LY.., LW..	1	n
Complete Chain or Area Chain	LE.., LL..	??	n
String ⁶	LS..	??	??
Arc ⁵	AC.., AE.., AU.., AB..	??	??
Ring	??	??	??
Polygon (comprised of chains)	PC.., PW.., PX..	??	n
Polygon (comprised of rings)	??	??	??
Raster Modules	??	??	??
Graphic Representation Modules⁶	??	??	??

5.1 Global Information Modules

(see also Part 1, Section 5.2, Global Information Modules)

5.2 Data Quality Modules

(see also Part 1, Section 5.3, Data Quality Modules)

5.3 Attribute Modules

(see also Part 1, Section 5.4, Attribute Modules)

There is no restriction on the relationships between objects and Attribute Primary module records: the relationship may be one-to-one, one-to-many, many-to-one, or many-to-many. If the relationship is not one-to-one or one-to-many, the encoder is required to alert decoders to this fact in the Catalog/Cross Reference module record for the modules involved. This shall be done by placing the characters "JJ" into the first two characters of the Comment subfield.

5.4 Composite Module

(see also Part 1, Section 5.5, Composite Module)

not

5.5 Vector Modules

(see also Part 1, Section 5.6, Vector Modules)

5.5.1 Topological Pointers

5.5.2 Attribute Primary References

Object records may reference zero, one or more attribute primary records.

5.5.3 Number of Object Types Within a Single Module

A single module shall contain only records of a single object type (indicated by appropriate object representation code).

5.5.4 Use of "NP" Points

Points with the "NP" object representation code are allowed only for use in data quality reports. An example use is to transfer control points used for transformations which might be part of the Lineage Data Quality report.

5.5.5 Label Points

The Attribute Primary Foreign ID (PAID) field is mandatory for the "NL" object representation code. This field references the record and the label of the attribute to be annotated. This field shall reference an attribute record in either an Attribute Primary module or an Attribute Secondary module.

5.6 Raster Modules

These modules shall not be included in a transfer conforming to this profile.

5.7 Graphic Representation Modules

These modules shall not be included in a transfer conforming to this profile unless the options described in Annex F are implemented. Encoders and decoders are not required to support these module types to be conforming to this profile.

5.8 Module Restrictions/Requirements: Identification Module

(see also Part 1, Section 5.2.1, Table 10 Identification)

5.8.1 External Spatial Reference

(see also Part 1, Section 5.2.1.2.2, External Spatial Reference Subfield)

The External Spatial Reference subfield of the Conformance field of the Identification module shall have the value of "1" indicating that, YES, one of three recommended systems is used.

5.8.2 Profile Identification

Each transfer encoded per these specifications shall have

"SDTS TRANSPORTATION NETWORK PROFILE"

as the value of the Profile Identification subfield of the Identification module primary field.

Each transfer shall have

"VERSION 1.0 OCTOBER 1, 1996"

as the value of the Profile Version subfield of the Identification module primary field.

Each transfer shall have

"FIPS 173-1 TNP"

as the value of the Profile Document Reference subfield of the Identification module primary field.

5.8.3 Feature Level Conformance

(see also Part 1, Section 5.2.1.2.3, Features Level Subfield)

Any level of SDTS Features Conformance is allowed (the value in the Features Level subfield of the Conformance field of the Identification module record shall be either "1", "2", "3" or "4"). Note that if SDTS is not the authority for any entity and attribute terms, then the Features Level subfield must be valued as "4".

5.8.4 Global Attributes

The Attribute ID field is used to reference global information that applies to the entire transfer (e.g. Census TIGER/LINE min and max ID numbers).

5.9 Module Restrictions/Requirements: Internal Spatial Reference

The X subfield of spatial addresses shall be used only for longitude and easting values. The Y subfield shall be used only for latitude and northing. Therefore, the Spatial Address X Component Label subfield is restricted to "LONGITUDE" when the external spatial reference system is geographic and "EASTING" when the external spatial reference system is UTM/UPS or SPCS. The Spatial Address Y Component Label subfield is restricted to "LATITUDE" when the external spatial reference system is geographic and "NORTHING" when the external spatial reference system is UTM/UPS or SPCS.

The Scale Factor X, Scale Factor Y, X Origin, and Y Origin subfields in the Internal Spatial Reference field are required. If spatial addresses include Z values, the Scale Factor Z and Z Origin subfields are required. These subfields specify the scaling and translation required to transform spatial addresses from the internal spatial reference to the external spatial reference (see Part 1, 5.2.4.1). The use of the Registration module to specify this transformation is not allowed.

5.10 Module Restrictions/Requirements: External Spatial Reference

The Reference System Name subfield in the External Spatial Reference Module primary field shall have the value "GEO", "SPCS", "UTM", or "UPS" depending upon the external spatial reference system being used.

5.11 Module Restrictions/Requirements: Catalog/Spatial Domain

The following requirements apply to the Catalog/Spatial Domain field in the Catalog/Spatial Domain module:

5.12 Module Restrictions/Requirements: Catalog/Directory

So that the contents of a transfer are independent of the transfer media, the following restrictions are placed on the primary field of the Catalog/Directory module:

5.13 Module Restrictions/Requirements: Data Dictionary/Schema

The Entity Authority and Attribute Authority subfields shall contain "SDTS-USA" when Part 2 of FIPS 173 is the authority for the definition. When a standard register of entities and attributes of a country other than the United States is the authority, these subfields shall contain "SDTS-" followed by the three-character ISO 3166 country code. Entity Authority and Attribute Authority may have a maximum length of 8 graphics characters.

5.14 Module Restrictions/Requirements: Data Dictionary/Domain

The Attribute Authority subfield may have a maximum length of 8 graphics characters.

5.15 Module Restrictions/Requirements: Data Dictionary/Definition

The Attribute Authority subfield may have a maximum length of 8 graphics characters.

6 ISO 8211 Specific Decisions

(see also ANSI/ISO 8211-1985 a.k.a. FIPS PUB 123 Specifications for a Data Descriptive File for Information Interchange, and Part 3, ISO 8211 Encoding)

6.1 Objective

(see also Part 3, Sections 1.1 and 1.2, Purpose and Objectives):

SDTS/ISO 8211 is optimized for retrieval and storage (versus interactive decoding); non- SDTS directories/indices may be added to allow such interactive decoding (e.g. on a CD-ROM media).

6.2 Relationship of Modules to ISO 8211 Files

(see also Part 1, Section 4.1.3, Tables 3a & 3b,

and Part 3, Section 7, Assignment of Fields to Records and Files)

6.3 Media

(see also Part 3, Section 10, Media Requirements)

When only a single SDTS transfer is on a media volume, then the volume name shall begin with the same four characters as the first four characters of file names for that transfer (see section 6.5.) When multiple transfers are contained on a volume, then the first four characters of the volume name shall be "SDTS".

For multi-volume transfers, the first four characters shall be the transfer base characters as described above, and the remainder of the name shall indicate the volume sequence.

6.4 Organization of Files on Media

In general, the files comprising a single transfer shall be kept separate from any other transfer files.

6.5 File Names

SDTS Transportation Network Profile file names, to be consistent from the various agencies shall consist of eight characters of base name. A single transfer data set shall use the same first four characters in the file name of each SDTS ISO 8211 file in the entire transfer. The next four characters in the file name shall be the unique name of the module transferred in that file (see naming convention for modules in Section 4.1 of Part 4). When allowed, the extension should be ".DDF" to indicate the type of file transferred; but the last character of this extension or an optional ninth character on the base name may be used in the case of modules that span files. Thus the extension could become ".DDG", ".DDH", ".DDI", ... for multi-volume modules. Such file extenders are optional. Any file that is not ISO 8211 compliant (e.g. adjunct files) shall not have the ".DDx" extension. All letters in file names shall be upper case.

6.6 Taking Advantage of Dropped Leader and Directory

(see also Part 3, Section 6.4, Repeating Fields and Records)

This profile encourages taking advantage of ISO 8211 mechanisms to reduce file size. All modules shall use fixed size fields whenever practical to allow for the dropping of leader and directory information from the data records in ISO 8211. In the case where there are a few records that exceed the fixed size fields' size, records shall be ordered within a file to maximize the use of dropped leaders and directories. This means that exceptional data records (DRs) shall be placed first in the DDF. All records that can share a common leader and directory shall be grouped at the end of the file. (This is necessary because once the leader and directory are dropped, they cannot be re-specified later in the file.)

Maximizing the use of dropped leaders and directories needs to be taken into consideration when designing attribute modules. If there are attributes that can have a wide range in the size of their value (e.g. place names), then considering separating these attributes into their own module.

6.7 ISO 8211 DDR Contents

6.8 Use of Binary Data Type for Spatial Addresses

A binary data type may be used in the subfields of a spatial address field, but binary formats are not required by this profile. If used, the binary subfields shall be a fixed width of 32 bits.

6.9 Use of Character Data Type for Dates

(see also Part 3, Section 9.2, Dates)

Dates in the form YYYYMMDD are to be encoded as ISO 8211 data type = A.

6.10 README File

(see also Part 3, Section 11, Conformance)

The README file shall contain volume name, date, a list of SDTS transfers (if more than one), and then for each SDTS transfer: a list of subdirectories and non-SDTS files, if appropriate, the file name of the Catalog/Directory module, where it can be found, and an explanation that this file and all other SDTS files are in ISO 8211 format, and that the Catalog/Directory module carries a complete directory to all other SDTS ISO 8211 files comprising the SDTS transfer, notes about any non-SDTS adjunct/auxiliary files, a brief explanation of the spatial domain, the purpose, authority (FIPS 173), source (e.g. agency name) and contacts within the source organization. If there are any issues about the transfer, use of optional profile annexes, special purposes (i.e. private agreement transfer), non- standard uses of modules, etc., this shall be described.

ANNEXES

Normative Annex

A: The Data Dictionary Transfer

A.1 Introduction

This annex describes the method by which master data dictionary transfer will be accomplished. The first section addresses the requirements of the dictionary transfer itself, the next section addresses the requirements of a spatial transfer that will use a dictionary transfer.

A.2 Requirements for Master Data Dictionary Transfer

A.2.1 Required Modules

One each of the following modules is required:

No other types of modules shall be included.

A.2.2 Required Contents Per Module

These are requirements in addition to those specified by Parts 1, 2, and 3. This information aids in precisely identifying transfer contents.

Identification Module:

Catalog/Directory:

Module Version - this subfield shall include the version number of this release of the master data dictionary.

Lineage:

Comment - this subfield shall include a change log summarizing the differences between all versions. It should also recommend which old versions would best be replaced by this version.

Completeness:

Comment - this subfield shall describe the product (transfer) series to which this dictionary applies. If applicable, it shall also note what subset of definitions this transfer contains.

A.2.3 Version Numbering

Version numbers shall have the following form:

d.nn

where d = a positive integer, with no leading zeroes, and nn = two-digit non-negative integer. Valid version numbers are 1.01, 1.12, and 2.13. Invalid version numbers are 01.1 and 2.1.

Version numbers shall be incremented according to the following rules. The first released version of a master data dictionary transfer shall be 1.00.

The number "nn" shall be incremented when

The number "d" shall be incremented when

Note: When "d" is incremented, "nn" shall restart from "00". A valid sequence of version numbers would be: 1.00, 1.01, 1.02, 2.00, 2.01, 2.02, 2.03, 3.00. Invalid sequence would be 1.0, 1.10, 1.20. Another invalid sequence would be 1.00, 1.01, 1.02, 2.03.

The numbering scheme is intended to help the receiver of a transfer decide which version of a data dictionary is required. The changes in "nn" indicate that changes of a corrective nature have been made, whereas the changes in "d" indicate that something new and different has been added.

A.2.4 Module Naming Conventions

The modules must be named in such a way as to not cause module name conflicts with any module in a Topological Vector Profile transfer. The modules shall be named in the following manner:

A.2.5 File Restrictions and Naming Conventions

Each file (ISO 8211 DDF) shall contain information from a single module. Files shall be named using the following convention:

When allowed, the extension should be ".DDF" to indicate the type of file transferred; but the last character of this extension or an optional ninth character on the base name may be used in the case of modules that span files. Thus the extension could become ".DDG", ".DDH", ".DDI", ... for multi-volume modules. Such file extenders are optional. Any file that is not ISO 8211 compliant (e.g. adjunct files) shall not have the ".DDx" extension.

A.2.6 Requirements for Transfer Using a Master Data Dictionary

The following restrictions apply to any spatial data transfer that requires the use of a master data dictionary.

To indicate that this transfer requires a master data dictionary, the following modules shall include the following information.

Identification:

Comment - this subfield shall include a statement to the effect "This transfer requires an external data dictionary from <agency>, with 4-character code of ..., Version number d.nn".

Catalog/Directory:

A.2.7 Creating a Complete Transfer

When external transfer modules are merged with a spatial transfer, the appropriate fields in the Catalog/Directory module must be updated - External set to "N", and Volume, file, and record filled if information is present. It is recommended that the Module Version subfield remain as is, so version information is not lost.

Informative Annex

B: Encoding Multi-valued Attributes

Attributes that can be multi-valued shall be in their own tables, along with any other attributes that are functionally dependent. For example, say entity "road" has attributes "num_lanes", "name", "oper_status", and "route_number." "Name" can have many values for a single entity instance. Further, every value of "name" may have its own route number. Since the value of attribute "route_number" is dependent on "name" then both of these are put in their own table. The modules that follow illustrate the proper way to handle multi-valued attributes.

The line module LE01 references the attribute records in the Attribute Primary modules that describe the entity instance being represented. The attribute module AP12 contains the attributes that are not multi-valued for entity "road". The attribute module AP13 contains the multi-valued attribute "name" along with its functionally dependent attribute "route_number".

Module Type: Line
LINE			ATID		...
MODN	RCID	OBRP	MODN	RCID
LE01	??	??	AP12 AP13 AP13	18 01 02
LE01	??	??	AP12 AP13 AP13	19 03 04

Module Type: Attribute Primary
ATPR		ATTP
MODN	RCID	NUM_LANES	OPER_STATUS
AP12	??	2	IN USE
AP12	??	4	CONSTRUCTION

Module Type: Attribute Primary
ATPR		ATTP
MODN	RCID	NAME	ROUTE_NUMBER
AP13	??	Main Street	n/a
AP13	??	Highway J	J
AP13	??	I-70 N Bypass	470
AP13	??	Memorial Expy	155

Repeating the row, as shown in the following modules, is an undesirable solution. Attributes that do not repeat are duplicated in subsequent rows. It is not clear whether the two attributes with changing values are related or not.

Module Type: Line
LINE			ATID		...
MODN	RCID	OBRP	MODN	RCID
LE01	??	??	AP11 AP11	23 24
LE01	??	??	AP11 AP11	25 26

Module Type: Attribute Primary
ATPR		ATTP
MODN	RCID	NUM_LANES	NAME	OPER_STATUS	ROUTE_DESIGNATOR
AP11	??	2	Main Street	IN USE	n/a
AP11	??	2	Highway J	IN USE	J
AP11	??	4	I-70 N Bypass	CONSTRUCTION	470
AP11	??	4	Memorial Expy	CONSTRUCTION	155

NOT the proper way of handling multi-valued attributes.

Informative Annex

C: An Example of Attributing Feature Objects with Entity Labels

Module Type: Composite
COMP			ATID		FRID		CPID
MODN	RCID	OBRP	MODN	RCID	MODN	RCID	MODN	RCID
FF01	??	??	AP01	??	LE02 LE02	67 35	n/a	n/a
FF01	??	??	AP01	??	PC02	??	n/a	n/a
FF01	??	??	AP01	??	LE02	??	n/a	n/a
FF01	??	??	AP01	??	LE02	??	n/a	n/a

Module Type: Attribute Primary
ATPR		ATTP
MODN	RCID	ENTITY_LABEL	NAME
AP01	??	SHORELINE
AP01	??	STREAM/RIVER	JONES CREEK
AP01	??	STREAM/RIVER	RED RIVER
AP01	??	LAKE	SCHUMAN

Note that in this example, the ENTITY_AUTHORITY attribute label is not used. The authority for the definition of all entity labels in this transfer is "USGS/NMD." This example also shows a case where entity types share a common attribute (NAME).

Module Type: Data Dictionary/Schema
MODN	RCID	NAME	TYPE	ETLB	EUTH	ATLB	AUTH	FMT	MXLN	KEY
DDSH	201	AP01	ATPR	n/a	n/a	ENTITY_LABEL	SDTS/TVP	A	??	n/a
DDSH	202	AP01	ATPR	n/a	n/a	NAME	USGS/NMD	A	127	n/a

Module Type: Data Dictionary/Definition
MODN	RCID	EORA	EALB	SRCE	DFIN	AUTH	ADSC
DDDF	??	ENT	LAKE	...	...	USGS/NMD	USGS/NMD TI...
DDDF	??	ENT	SHORELINE	...	...	USGS/NMD	USGS/NMD TI...
DDDF	??	ENT	STREAM/RIVER	...	...	USGS/NMD	USGS/NMD TI...
DDDF	??	ATT	NAME	...	...	USGS/NMD	USGS/NMD TI...

Normative Annex

D: Arc Option

D.1 Introduction

This annex contains an option which allows complete chains to be composed of arc and string spatial objects. Unless stated otherwise in this annex, all requirements of the body of this part also apply when using this option.

D.2 Spatial Objects

The following table indicates spatial object requirements which differ from that of section 2.1 of this profile.

Object Representation Code	Required	Optional	Not Permitted
LS - String		x
AC - Circular Arc		x
AE - Elliptical Arc		x
AU - Uniform B-spline		x
AB - Piecewise Bezier		x

At least one of the four arc objects (AC, AE, AU, AB) is required.

All arc and string objects must be components of complete chain objects which are components of 2-D manifolds.

D.3 Relationship Between Modules and 2-D Manifolds

In addition to the requirements of section 4.7 (a), for objects particular to one 2-D manifold there shall be:

zero or one Line module for optional simple object type LS;
zero or one Arc module for optional simple object type AC;
zero or one Arc module for optional simple object type AE;
zero or one Arc module for optional simple object type AU;
and zero or one Arc module for optional simple object type AB.

There shall be at least one Arc module for a particular 2-D manifold in a transfer using this option.

D.4 Transfer Module Specification

The following table contains inclusion/exclusion, and cardinality rules for additional modules permitted by this annex. The standardized modules names are included, along with the minimum number and the maximum number of occurrences of the module type. A lowercase "n" indicates that the upper limit is user defined. Any lowercase letters or dots in the module name has the meaning explained in Section 4, Standard Module Names.

Module Type	Name	Min. No.	Max. No.
Line⁷	LS..	0	n
Arc	AC.. AE.. AU.. AB..	0 0 0 0	n n n n

D.5 Module Restrictions/Requirements: Identification Module

To indicate that this annex is being used, the Profile Identification subfield shall include "/D" in the manner described in section 5.8.2 of Part 4.

D.6 Module Restrictions/Requirements: Line Modules

D.6.1 Chain Component ID

Complete chains (LE object type) in transfers using this annex shall use this field to reference arcs and strings which are components of the chain. All arcs and strings in the transfer referenced by complete chains with this field.

D.6.2 Spatial Address

Complete chains (LE object type) shall always include the Spatial Address field, even if the chain is composed of strings or arcs referenced by the Chain Component ID. If a chain is composed of strings and (or) arcs, an encoder shall convert these strings and arcs into a series of vertices which shall be transferred in the Spatial Address field.

D.6.3 Object Representation Codes

Complete chains (LE object type) and strings (LS object type) shall not be included in the same module.

D.7 Module Restrictions/Requirements: Arc Modules

D.7.1 Object Representation Codes

Arc objects with different object representation codes shall not be included in the same module.

D.7.2 ISO 8211 Tag

The ISO 8211 tag for the Primary Field of the Arc module shall be ARCC. This is because all tags in an ISO 8211 file must be the same length (all other tags in the Arc module are four characters.)

Normative Annex

F: Graphic Representation Option

F.1 Introduction

This annex contains an option which allows the use of Graphic Representation modules. Unless stated otherwise in this annex, all requirements of the body of this part also apply when using this option.

F.2 Spatial Objects

This option does not add any additional permitted spatial object types.

F.3 Transfer Module Specification

Module Type	Name	Min. No.	Max. No.
Text Representation	TEXt	0	n
Line Representation	LNRp	0	n
Symbol Representation	SYRp	0	n
Area Fill Representation	AFIl	0	n
Color Index	CLRx	0	n
Font Index	FONt	0	n

F.4 Module Restrictions/Requirements: Identification Module

To indicate that this annex is being used, the Profile Identification subfield shall include "/F" in the manner described in section 5.8.2 of Part 4.

F.5 Module Restrictions/Requirements: Catalog/Cross Reference Module

If there is more than one Font Index or Color Index module, entries in the Catalog/Cross Reference module shall be used to indicate which Font Index module is referenced by each Text Representation module and which Color Index module is referenced by each Line Representation, Symbol Representation, and Area Fill Representation module. A module may not reference more than one Font Index or Color Index module.

Footnotes

¹ Points with the "NP" object representation code are allowed only for use in data quality reports.
² Allowed only as an option as described in Annex D.
³ A maximum of one module is recommended.
⁴ The module may be contained in an external SDTS data dictionary as described in Annex A.
⁵ Allowed only as an option as described in Annex D.
⁶ Allowed only as an option as described in Annex F.
⁷ This Line module is in addition to the Line module required for Complete Chain (LE) objects as described in section 5.

USA Banner

Spatial Data Transfer Standard - Transportation Network Profile