# Presentation: 877157

## TheSpatial Data Transfer Standard

**What’s It All About?**

## Topics

**What is SDTS?**
**      ****Why do we need it?**
**            ****How does it work?**
**                  ****How does it affect me?**

**Notes:**
The topics that will be covered in this presentation:
A brief introduction to what SDTS is
A look at why it is needed
A brief explanation of how  the standard works
A look at how  it can be used in different situations

## What is SDTS?

**Spatial Data Transfer Standard**
**A way to package information so it can be moved without loss**
**For spatial data sets that are referenced to the Earth’s surface**
**Raster, Vector, Point**
**Useful for data distribution and archive**

**Notes:**
Think of an SDTS Transfer as a Package.  A package that contains a georeferenced spatial data set plus all the information you need to understand the data and how to properly reuse it. The Data plus a Users Guide.

SDTS Transfer Data Model is configurable to support a wide variety of spatial data models and documentation:
Vector: Topo, Non-topo, Planar, Non-planar
Raster: Gridded, Image, 2-D, N-dimensional
Attributes: user-defined relational tables
Metadata: Data Dictionary, Data Quality Report, etc.

General data distribution where the data consumer’s system of choice is not known. For Internet distribution, where data consumer can be anyone. For archive, where software being used at some future point in time is not known.  The package needs to be independent of any hardware and software systems.
Intended use of the standard is for georeferenced digital spatial datasets, either vector, point, or raster spatial data model. Intended for data exchange between hardware/software systems.  Not intended to be a native processing format internal to a system. (i.e. not efficient processing structures, as these are very application dependent.)

## SDTS Philosophy

**Promotes ****self-documenting**** transfers**
**Contains everything you need to be an informed data user**
**Not just spatial objects and attributes**
**Includes reference system, data dictionary, data quality, and other supporting metadata**
**Information for software to read and for YOU to read.**

**Notes:**
Fundamental principle behind the design of SDTS is that a spatial data transfer should be self-documenting.
This is evident at the conceptual level---where the taxonomy of data quality information is presented. And at the logical level, where there are many ways to organize and encode the “documentation.”
 SDTS Transfers are especially suited for archival and blind exchange (receiver unknown at the time the data is produced) because the information content requirements promote self-contained/self-describing datasets. 
A transfer data set includes spatial data, attributes, and metadata---like spatial referencing, data quality, and a data dictionary.  
A transfer data set includes structured information meant to be automatically process by software. But, it also contains free form textual information which is meant to be read by a data consumer.

## SDTS: Many aspects.

**Spatial Object Glossary**
**Data Quality Report**
**Data Dictionary**
**Spatial Referencing System**
**Transfer Structures**
**Entity and Attribute List**
**File Implementation**

**Notes:**
The term SDTS is very broad. There are many aspects or components to the standard.

From the Conceptual,
spatial object characteristics and definitions
taxonomy of data quality information
feature and attribute definitions (non-application specific)

To the Logical,
transfer data structures (Module, record, field, subfield)

To the Implementation,
File Format (uses ISO 8211)
Required information (like DQ Report and Data Dictionary)

## SDTS as a Standard

**Formal standard**
**ratified by a standard defining organization**
**SDTS ratified as FIPS PUB 173**
**Natl Institute Standards & Technology (NIST)**
**Seeking ANSI approval**
**American National Standards Institute **
**GIS Standard (NCITS L1)**
**Proposed as unifying model**
**ISO/TC211 Geographic info/Geomatics**

**Notes:**
The standard was developed by a wide cross-section of the spatial data community: government, private industry, and academia.

SDTS was ratified as a Federal Information Processing Standard (FIPSPUB) 173 in August 1992.  US Geological Survey is the maintenance agency for the standard as delegated by NIST (agency in charge of FIPS program.)
Currently the standard has been submitted to ANSI as a GIS Standard to be ratified in 1997/98.  GIS Standards fall under the National Committee on Information Technology Standards, technical committee L1.
US delegation to ISO has proposed that the component-based design of SDTS makes it suitable as a unifying model for an international standards effort.

## What SDTS is NOT.

**Product Specification**
**Doesn’t dictate content**
**File Format**
**Uses another standard for this**
**Processing Structure**
**Not optimum or efficient for direct use**
**Services or Interface Specification**

**Notes:**
Not a product specification. It doesn’t dictate positional accuracy thresholds, or scale, or data extraction rules, or symbology, or theme to be collected.
Not a file format standard. It describes a set of information in terms of logical data structures. One part of the standard then takes these structures and describes how to implement these in a file format standard.
Not a set of structures intended to support processing, other than simple viewing and browsing.
No explicit specification of any services or interfaces in this standard. The standard is data-centric.

## Why do we need SDTS?

**Standards are fun!**
**Standards are easy!**

**Notes:**
Why work on standards?

Standards are fun to write and easy to learn and use....

and you get to travel to a lot of meetings  : )

## Why do we need SDTS?

**Standards are fun!**
**Standards are easy!**
**Standards are necessary!**

**Notes:**
GIS standards are necessary.

Adoption and use of standards is a sign of maturity in a field.

Once commonality is standardized, permits growth in new directions; stop getting bogged down in ‘reinventing the wheel’.

Standards are the launch pad for new technologies and research in an industry.

## Problems with Geospatial Data Exchange

**Computer Media**
**Physical Format**
**Logical Format, Data Model**
**Data Content, Classification System**
**Data Completeness**
**Data Coverage**
**Data Resolution, Accuracy**
**Attribution Model**
**Quality Assurance**

## Why do we need SDTS?

**To help solve THESE problems!**
**Computer media - encourages widely accepted ones**
**Physical Format - requires existing media standards**
**Logical Format - defines modules and uses ISO 8211 to encode files**
**Content - “Tell what you have and where you got it”**
**Completeness - “Tell us your rules”**
**Coverage - “Tell us the spatial domain”**
**Resolution - “Tell us the resolution and accuracy”**
**Attribution - simple model; use our terms or your own**
**Quality - “Tell us what tests you did and the results”**

**Notes:**
The Spatial Data Transfer Standard was proposed to address many of the current problems with spatial data transfer. However, you must realize that data producers produce data specific to their applications. So incompatibility caused by this fact will always be a barrier to exchange.

The SDTS guiding principle was that a transfer should be self-documenting. There should be enough information directly in the transfer to answer these questions.

## Why do we need SDTS?

**Advances in GIS and digital cartography have increased demands**
**Diversity in hardware, software, data specifications, and the lack of standards inhibit the transfer of data between producers and users**
**Diversity and lack of standards result in duplication of effort and incompatible data sets**
**SDTS can facilitate data reuse.**

**Notes:**
Numbers increasing---situation is getting worse.
GIS software is now more powerful and less expensive than ever.  It seems that everyone is using a GIS for their work.  With the explosion of GIS systems comes the need for spatial data by large communities of GIS users. The impact of the Internet being used for data delivery is causing tremendous growth in demand for spatial data.
Because many GIS systems have proprietary native data formats, sharing data means that the parties have to correspond and agree on mutual formats, if they exist.  Sharing data with formats not designed for spatial data transfer can mean that editing the received data may require more effort than re-digitizing the data from the source materials.

Some of the benefits of using SDTS include:
If we all support the same format, we can share data within larger communities of users.
SDTS is specifically designed for spatial data transfer and can accommodate complex data structures.
With SDTS, sharing data is easier than creating it from source materials.
Complete, meaningful data sets can be transferred, enabling the receiving system to use the data to the software’s fullest capability.
SDTS transfers require documentation about the data being transferred.  These data quality items include positional accuracy, attribute accuracy, and other metadata so that the person receiving the data can make a decision about the data’s usefulness to their particular application.

## Why do we need SDTS?

**X**

**Y**

**X**

**Y**

**SDTS**

**Switchboard Approach**

**SDTS Approach**

**Notes:**
SDTS is a solution to the problem of data sharing and exchange in a continually expanding market place of  GIS-related software systems. 
   In this diagram the outer circles represent GIS systems.  The lines represent “connections” between the systems.  These “connections” are one or more external formats that each system supports.  If one party has System X and another party has System Y, there must be a link between the two systems for them to share data.  To be competitive in today’s market, systems must support many formats to connect to the other systems out there. 
   The “Switchboard Approach” is how people share data today. Now, as in the past, it is difficult to transfer data between GIS systems that do not share the same native data format.  To share data the parties on both ends of the transfer have to arrive at a common format that each system can read.  In most cases these formats are ones that have become ad-hoc standards for the transfer of spatial data.  Rarely is one of these formats designed exclusively for the transfer of spatial data.  They are usually widely used formats that vendors have developed for data import or export into their particular system.  They were then picked up and implemented by other systems, and so on, until they have a large community that supports the format.  However, this gives rise to partial transfers because the format could not handle the complexity, or the sending or receiving systems did not have full implementations of the format.
    In the “SDTS Approach” all GIS systems would be able to use the SDTS for transferring data.  If System X wanted to share data with System Y, write it in SDTS format.  That same format would be readable by every other system that supports SDTS.  Instead of maintaining many formats to be compatible with other systems, a system would need only support SDTS.  This has the additional benefit that because software vendors have less code to maintain for import/export functions, more software resources can be dedicated to increased GIS capability and even lower per license costs---the end user benefits by getting more value for their dollar.

## Why SDTS now?

**National Spatial Data Infrastructure**
**Federal Geographic Data Committee**
**Framework Concept**
***The “new vision” has helped put SDTS into context. Its time has come.***

**Notes:**
SDTS has been around for a long time. It was started by a forerunner of the FGDC in the early 1980’s.

The National Information Infrastructure concept was proposed in the early 1990’s. One component of that is for spatial data, which has come to be called the National Spatial Data Infrastructure.

FGDC - chaired by USGS Director formerly; now chaired by the Secretary of  the Interior, Bruce Babbit. Increased visibility, and increased priority and emphasis.

Framework Concept - Data sharing, clearinghouse to increase data reuse by increasing awareness of what is available among the GIS community.
Budget reductions, so we need to spend our spatial dollars more wisely.

Although SDTS was started some time ago, it is more relevant now.

## How does SDTS work?

**Concept->structures->format**
**Example: Chain spatial object**
**CONCEPT: Defn: 1-d, topological, sequence of line segments bounded by nodes**
**STRUCTURE: Line Module Record with Fields with Subfields**
**FORMAT: ISO 8211 file, Data Record**

**Notes:**
In a nutshell, SDTS defines a geospatial data concept, and then gives it an information structure, and then specifies how to put the information into files.
Example: Chain Spatial Object
Concept: chain spatial object is a 1-dimensional spatial object with topological relationships; it is a sequence of line segments bounded by nodes
Structure: Line Module Record with Fields for polygon left, polygon right, start node, end node, list of spatial addresses, reference to any attributes
Format: ISO 8211 Files; This is a general purpose data exchange standard that is used by  SDTS
Module - represents a “concept”; it contains information structures for a set of conceptually related information; Modules types are Identification, Spatial Domain, External Reference System, Line, Point-Node, Polygon, Raster Definition, Cell Values, etc. (36 types in all)
Module Records are composed of Fields. Some types of fields are listed in the Chain structures above; and in Identification Module, there are fields for Title, Dataset Date, Profile Id, etc; and for Reference System Modules, there are fields for Datum, Reference System Name, Zone, Scale and Offsets, Resolution, etc.
Fields are composed of Subfields which hold the atomic data.

## Conceptual

- SDTS Concept to Module to File

- _Chain:_ nonbranching sequence of non-intersecting line segments or arcs, bounded by nodes at each end

- 004412L   0600106   2304000015000000128015LINE43043ATID42086PIDL44128PI
- DR45172SNID41217ENID39258SADR38297;0000;&HY01LE01;0100;&DDF RECORD IDENTIFIER;
- 1600;&LINE&MODN!RCID!OBRP&(A(4),I(6),A(2));2600;&ATTRIBUTE ID&*MODN!RCID&(A(4),I(6));
- 1600;&POLYGON ID LEFT&MODN!RCID&(A(4),I(6));1600;&POLYGON ID RIGHT&MODN!RCID&(A(4),I(6));
- 1600;&STARTNODE ID&MODN!RCID&(A(4),I(6));1600;&ENDNODE ID&MODN!RCID&(A(4),I(6));
- 2600;&SPATIAL ADDRESS&*X!Y&((2B(32)));
- 00162 D     00081   220400010700LINE1307PIDL1120PIDR1131SNID1142ENID115
- 3SADR1764;     1;LE01     1LE;PC01     1;  PC01    26;NO01     3;  NO01     1;
- @@@M@&@{@@&t@&@i;       (spatial addresses are binary)
- 00162 D     00081   220400010700LINE1307PIDL1120PIDR1131SNID1142ENID115
- 3SADR1764;     2;LE01     2LE;PC01     1;PC01    13;  NO01     4;NO01     3;
- @@@@@&@c@@@M@&@{;

- - Definition, Idea

- Logical
-  - Module, Field,
-      Subfield

- Format
- -ISO8211 File

- Line  Attribute  PolyLeft PolyRight StartNode EndNode Spatial Addr

- LE01#1      road                       PC01   1             PC01   26                NO01   3                NOO1    1            123,421 ...... 265,526

- LE01#2      road                       PC01   1             PC01   13                NO01   4                NO01     3             10,425 ....... 123,421

- LE01#3       .....                           .....                      ....                         .....                           .....                         .......

- CHAIN  1

- NODE  3

- NODE 1

- NODE 4

- CHAIN  2

- CHAIN  3

- POLYGON  1

- POLYGON 13

- POLYGON  26

## How does SDTS work?

**Content for self-documenting transfers:**
**Spatial data + attributes**
**spatial reference system**
**data dictionary**
**data quality report**
**Module structure for each concept**
**Transfer is a set of modules**
**Profiles - subsets or extensions**

**Notes:**
Transfers are self-documenting. The wide range of content that can be in a transfer are listed above.  These are the “concepts” that SDTS supports.
The Module is the primary SDTS information structure. Each concept can be found in one or more module types.
An SDTS Transfer is a set of modules. For example, a vector data transfer might contain Identification Module, Catalog/Directory Module, Spatial Domain Module, External Spatial Reference Module, Internal Spatial Reference Module, Line Module. Point-Node Module, Polygon Module, Attribute Module, and Data Dictionary Modules.

SDTS is implemented through Profiles. A Profile is a subset and/or extension of SDTS for a particular data model, like topological-vector, or a particular application, like transportation.

## How does SDTS work?

**System**
**X**

**Translator**
**X**

**Support**
**Software**

**Encode **
**SDTS/ISO 8211**

**Support**
**Software**

**Decode**
**SDTS/ISO 8211**

**Translator**
**Y**

**System**
**Y**

**Source**

**Target**

**SDTS**

**Notes:**
This diagram shows a typical scenario of using SDTS to exchange data between System X and System Y.
The data will be transferred from System X to System Y.
The data residing on System X will be passed through “Translator X” to change the format of the data from the native format of System X to a format that will be input into the “Support Software” section of the diagram.   The format of the SDTS files that are written is defined by Part 3 of the SDTS.   Parts 1 and 2 of the SDTS define the content and logical organization of the spatial data.  Part 3 of the SDTS specifies how files are written using ISO 8211, a general purpose data exchange standard.
Once the files have been shipped, mailed, transmitted, etc. to the receiving site, they will be read by the “Support Software” in System Y.  These files will feed the data to the “Translator Y” that will format the data into the native format of System Y.  When it is complete, the data will appear to have been created in System Y instead of having been imported from another system.

## How does SDTS affect me?

- Sdts

- export

- Sdts

- import

- Source System

- Target System

- SDTS

- Transfer

**Data Producer**

**Data Consumer**

**Software Developer(s)**

**Notes:**
SDTS Roles and Responsibilities

Generally, there are three roles people play when it comes to a transfer standard like SDTS. One can be a Data Producer, a Data Consumer, or a Software Developer. These are not mutually exclusive.

Each role has different responsibilities. The next three overheads address each of these in turn.

## Responsibilities of aData Producer

**To map their product(s) into SDTS**
**To provide data quality information**
**To use SDTS attribute structure**
**To provide data dictionary**
**To use a Profile**
**To use standard subfields as intended**
**To use tools to create SDTS transfers**

**Notes:**
Data Producer
 To map their product(s) into SDTS structures
 To provide Data Quality information (i.e. processing history, positional accuracy statements, data capture criteria, etc.)
 To map native attribute structure into the SDTS attribute structure and provide Data Dictionary Information (i.e. definitions for attribute terms, domains of allowable values, definition of special values, etc.)
 To reorganize/arrange data to be compliant to a Profile (may involve changing to standard projection, calculating standard topology, etc.)
 To populate standard subfields to the fullest extent possible (e.g. projection information belongs in certain subfields, spatial addresses and topolgy belong in standard subfields, etc.)
 To use appropriate software tools to create compliant SDTS transfer datasets

## Responsibilities of aData Consumer

**To read the documentation!**
**To read the DQ report and responsibly use the data**
**To read the DD to understand the attributes**
**To use the viewer and import tools**
**To manipulate the data to prepare it for use**

**Notes:**
Data Consumer (i.e. User, Customer)
 To read the Data Quality information (as needed to determine fitness for use)
 To read Data Dictionary and map attribute structure to native terms (ex., the term "water body" with attribute shoreline is natural, and area is less than 100 is your term "pond")
 To use the appropriate software tools to view and import SDTS transfers into GIS software.
 To reorganize/rearrange data to prepare it specific to your needs (i.e. organize data into layers differently, extract a subset of the features, generalize, panel, partition, etc.)

## Responsibilities of a Software Developer

**To provide SDTS import and export capability in GIS**
**To provide tools to aid in collecting data documentation**
**To provide tools for viewing**
**To seek certification when available**

**Notes:**
Software Developer
 To provide sdts import and export capability (ensuring that mappings to/from native data models preserve information)
 To provide tools to assist in converting native attribute structure to standard, and vice-versa
 For EXPORT, provide a mechanism for a Data Producer to include data quality and data dictionary information
 For IMPORT, provide a mechanism to search/browse the data quality, data dictionary, and other metadata that came with the transfer

 To seek certification testing if available.

GIS Software Vendors
- map to/from proprietary data models
- develop SDTS encoders/decoders for their GIS
- may need to handle more information than their system normally manages

## What’s It All About?

**What is SDTS?**
**Why do we need it?**
**How does it work?**
**How does it affect me?**