As long as consumers require the ability to transfer earth-referenced spatial data between dissimilar computer systems, the need for a transfer standard exists. In concert with the vision of the National Spatial Data Infrastructure (NSDI), the Spatial Data Transfer Standard (SDTS) (FIPSPUB 173-1 & ANSI) provides for the transfer of self-documenting datasets. Increased use of transfer standards will ultimately have an impact on all geospatial data users. SDTS is implemented through profiles which are subsets and/or extension of SDTS for particular data models. The Topological Vector Profile (TVP) was the first profile approved as a Federal Geographic Data Committee (FGDC) standard. The Raster Profile with Extensions is currently under review by FGDC. The US Geological Survey (USGS) has taken the lead in complying with FIPSPUB 173-1 by initiating a mass conversion of all of its vector and raster digital cartographic data stores to SDTS format. The USGS has made available all current holdings of their Digital Line Graphs in SDTS format. Currently, these datasets are being offered free by way of FTP over the Internet. One drawback to using SDTS formatted files is that the process of using commercial SDTS-TVP translators for decoding these files can be daunting; profile descriptions and conversion instructions are complex. This project was designed to build a user-friendly interface to allow download and import of SDTS formatted data using popular commercial translation packages. With the help of behind-the-scenes computer programs, accessing and applying SDTS data over the Internet will be as easy as "point and click."

Any use of trade, product, or firm names is for descriptive purposes only and does not imply endorsement by the U.S. Government.

The growing popularity of Geographic Information Systems (GIS) brings problems with incompatibility to the forefront. Geospatial or georeferenced data has been discovered by all facets of business, government, and the academic community. Not only is GIS the tool of cartographers and geographers, but it is rapidly growing in popularity with professionals in the fields of agriculture, law enforcement, and city administration to name a few. With this number of new data users comes the critical requirement to share and reuse spatial data. Issues that create problems persist when sharing data between dissimilar computer systems such as: data loss, missing data quality information, attribute definitions, guidelines for use of the data, information about georeferencing. The advent of the variety of data users, diverse uses of data, and the diversity of computer systems, the need for a transfer standard became apparent. A transfer standard might be thought of as a transparent way to share data between different computer hardware and software systems so that it appears they are speaking the "same language".

Government agencies, namely the U.S. Geological Survey (USGS), the National Imagery and Mapping Agency (NIMA), and the National Oceanic and Atmospheric Administration - National Geophysical Data Center (NOAA-NGDC), have invested years in data collection, distribution, and storage. Under the direction of an executive order, all federal agencies are charged with developing more cost effective ways to avoid duplication of spatial data management activities. The FGDC has taken the lead in this endeavor, and is responsible for the NSDI, a federal crackdown on this type of waste. Federal and private individuals and organizations comprise the NSDI. The National Institute of Standards and Technology (NIST) approved the SDTS making it a Federal Information Processing Standard (FIPS). USGS is anticipating approval from the American National Standard's Institute (ANSI) this fall for the SDTS. The USGS SDTS Task Force, located at the Mid-Continent Mapping Center in Rolla, Missouri, maintains the standard, and provides limited technical support to customer and software vendors providing SDTS translators.

SDTS is not a new product. It is a guideline that preserves the features of a database design and the underlying data model. The standard also provides a means to document and transfer data dictionaries and metadata. SDTS is implemented through the use of profiles. Since the standard is designed to support all types of spatial data, implementing all of the standard's options at one time would be a monumental task. Profiles balance two objectives of SDTS, first to allow both encoding and decoding to be feasible, and second to ensure that all meaningful information is transferred.

A profile is intended to provide specific rules for applying SDTS base specifications to a particular type of spatial data. A profile can be considered a subset of the SDTS specification. This project deals with the first profile approved as a FIPS, Part 4 - the Topological Vector Profile (TVP). The TVP supports geographic vector data with geometry and planar graph topology that describe "real-world" features rather than a symbolized map graphic. Another profile is the Raster Profile and Extensions (SRPE) - Part 5, which supports two-dimensional spatial datasets in which features or images are represented in raster or gridded form. The Transportation Network Profile (TNP) is in draft form and will accommodate geographic vector data with network topology. NOAA-NGDC and the USGS prepared the Point Profile, and SDTS Part 6. This profile is designed to support a major release of geodetic control point data from NOAA's National Geodetic Survey (NGS), as well as point-only data from other agencies. Additional profiles will be added as they become available.
 
 

SDTS Information Site

Web sites are in place for accessing SDTS datasets. First time data users should begin by visiting the information web site at: http://mcmcweb.er.usgs.gov/sdts. This web site contains an extensive amount of reading material, links to public domain software tools, a link to the SDTS datasets, and related web sites. Some important highlights are the following.

SDTS++ Home Page: Link to a C++ toolkit that developers can use to write applications that read and write SDTS datasets.

Data Problems?: Page for data consumers to check for known software bugs and data problems.

What is SDTS?: Definition, purpose, components, history, and more information about SDTS.

Implementing SDTS through Profiles: Informative look and additional links concerning profiles.

See who is implementing SDTS: Links to the USGS, other Federal agencies, and Private companies using SDTS. Each link gives a brief synopsis of the work being accomplished with the SDTS. Also provides a list of all commercial vendors currently offering SDTS translation software, along with a brief description of that software.

SDTS Public Domain software: Provides not only an information web site for public domain software but also an SDTS support software for programmers link.

View the SDTS Standard: Download the SDTS Document. This is not light reading as it is an in-depth look at the Standard. Also available are links to some very important general textual manuals. (download to read) Recommended reading: "The Spatial Data Transfer Standard - Handbook for Technical Staff" and "DLG-3 SDTS Transfer Description".

SDTS Frequently Asked Questions - FAQ: Last updated March 17, 1998. Highly recommend reading. (Available for on-line reading)

SDTS Information FTP Site: A variety of downloadable articles, software tools, sample datasets, etc.

USGS pricing policy for SDTS data: Currently SDTS data are FREE!

Related Web Sites: Links to web sites such as ANSI, FGDC, NIST, NSDI, and others.

USGS data is available on-line: Short description of data available from the USGS. Also included is a link to the US GeoData web site at EROS Data Center.

US GeoData Site

This web site is located at http://edcwww.cr.usgs.gov/doc/edchome/ndcdb/ndcdb.html. This web site contains a list of all USGS digital data sets, links to data examples, a hyperlink to user guide information and a list of the methods available for transferring the data using FTP. One important thing to note about these data files is that they are for use in geographic information systems for analysis and integration with other geospatial data. THEY ARE NOT DIRECTLY VIEWABLE using a WWW browser.

While this web site gives links to a variety of USGS digital data sets, the information reviewed for this project only deals with the large scale Digital Line Graphs (DLG) - SDTS format only (1:24,000-scale). Links for this dataset included:

Example: A graphic display of the West Rapid City, SD quadrangle was given at this web site.

Data User Guide: A downloadable file about the USGS DLG product is available in postscript, text, or WordPerfect format.

Condensed User Guide: A viewable document about the USGS DLG product. Recommend reading this guide versus the Data User Guide.

README: This document needs to be read to understand downloading the SDTS dataset and the master data dictionary. Naming conventions, document locations, and uncompression techniques are just a few of the instructions given.

Master Data Dictionary (masterdd)

The SDTS allows the use of a set of external data dictionary files common to spatial data of any origin. A masterdd provides the flexible capability to create, as needed, one or more external data dictionary modules to accompany data transfers. Usage of external data dictionary modules will reduce the time required to convert data between one spatial data format and SDTS, and will reduce the space requirements of multiple transfers.

Single Tar File OR Uncompressed Small Files: A masterdd is necessary for all SDTS TVP datasets. Each scale has its own unique masterdd that must be located in a directory structure that is level with the directory of the data. This dictionary is necessary to make the SDTS transfer fully compliant with the SDTS/TVP.

SDTS DLGs

FTP via Alphabetical List: The consumer can choose this method if the name of the 1:24,000-scale quadrangle is already known.

FTP via State: The consumer can also choose this method if the name of the 1:24,000-scale quadrangle is already known.

FTP via Graphics: The consumer can choose this method if the name of the 1:24,000-scale quadrangle is not known. Maps of the conterminous 48 state, Alaska, and Hawaii are available for point and click.
 
 

Uncompress Files

All SDTS transfers contain a complete set of files which are combined with the UNIX 'tar' command and compressed using the GNU 'gzip' utility. (As noted above, links are provided on the SDTS Information Site to download these uncompression utilities.) Each transfer contains a complete set of files for a specific layer and version that covers a quadrangle. For example: D3909454_hy0s.1.sdts.tar.gz is broken down to mean:

'D3909454' is a unique quadrangle identifier which contains the quadrangle's SE coordinates,

'hy0s' identifies this as the hydrography data layer ('bd' for boundary, etc.) followed by 0 (zero) and 's' for 7.5-minute or 'f' for 15-minute quadrangle,

'1' is the file version (1 - current, 2 - historical),

'sdts' denotes the data is in SDTS format,

'tar' represents a tar (compression) file, and

'gz' represents a gzip compression file.

After these files are uncompressed, the result is a set of files that have the same four-character alphanumeric prefix with a .DDF extension. Information about the transfer, identification of the dataset, and specific metadata information are but a few of the mandatory files found in each transfer. Along with these mandatory files are the files containing the spatial objects and attributes. For a more detailed look at the .DDF files, a more thorough description can be found in the 'DLG-3 SDTS Transfer Description' document, available for downloading from the SDTS Information Site.

Download masterdd

Before the SDTS TVP dataset can be imported, the appropriate masterdd must be downloaded and uncompressed into the correct directory structure. This external data dictionary is meant to be used in conjunction with the SDTS transfer data to form a fully compliant SDTS transfer. Because of the different masterdd versions, it is critical to the SDTS transfer that the correct version number is downloaded. (NOTE: During testing for this project, a bug was discovered in the Environmental Systems Research Institute (ESRI) ARC/INFO sdtsimport command for the Windows-NT platform. During execution of this command, the masterdd cannot be found. Because the masterdd should always be located in a directory level that is equal to the dataset, the datasets imported on this platform will not have any textual information attached to the spatial objects. ESRI reported the problem will be taken care of during the next major version release.) The masterdd also follows the same format as the SDTS transfers in its uncompression procedures. The masterdd contains six modules (.DDF extensions), which include shared data dictionary information, identification, catalog, and data quality information. For a more detailed look at the masterdd, a more comprehensive discussion can be found in the "Spatial Data Transfer Standard - Handbook for Technical Staff", available for downloading from the SDTS Information Site.

SDTS datasets are not directly viewable using a WWW browser, so the USGS offers free software for viewing a variety of digital cartographic products. The viewers, written for Windows 95/NT, can be found at: http://mcmcweb.er.usgs.gov/viewers/dlg_view.html. At this time, the only version that will support SDTS viewing is the DLGV32 version 3.0 beta. Even though the viewer is not a robust GIS tool, an enormous amount of information can be gathered before the actual importing of the dataset. Identification, transfer stats, and data quality can be found by merely pointing and clicking on the Overlay Control Center. DLGV32 is an extremely user-friendly tool. Consumers are able to point to a spatial object and bring element information such as name, category, id, type and attribute information as well as a textual description of the feature into view. This quick check will ensure, before extensive processing has occurred, that the desired geo-dataset has been obtained.

Applications Software Technologies, Inc., Avenza, ERDAS, ESRI, Intergraph, and UNISYS have all written SDTS translators. Due to time constraints, software availability, and familiarity with ESRI's ARC/INFO software, a decision was made to deal with ESRI's translator for this joint USGS/University of Missouri at Rolla project. The following instructions will be dependent on that software package and address only the conversion of USGS vector datasets.

AML is the language used in the ARC/INFO environment to program and tailor applications. It allows the means to automate frequently performed commands, create new commands, and provides utilities that help new or inexperienced users. An AML routine seemed to be the best solution to ease the apparent repetitious nature of preparing SDTS datasets for use. AN AML ROUTINE THAT WILL UNZIP, UNTAR, IMPORT, BUILD, AND JOIN ATTRIBUTES TO THEIR SPATIALS, WAS DEVELOPED AS PART OF THIS PROJECT AND CAN BE FOUND AT THE SDTS INFORMATION SITE. This AML routine will work with ARC/INFO Version 7.1.1, on UNIX and Windows_NT platforms. A README file that accompanies the AML routine should be read for specific instructions as to usage or the following command can be used:

Arc: &r sdtshelp.aml <sdts_transfer> <out_cover_name>
 
 

Now that the preliminary work has been finished, i.e. each dataset is in its own directory and the masterdd is in a directory at the same level,
 
 

                   ____________________________|_____________________________

                            |                      |                          |                        |                      |

                    masterdd          mo_hydro          mo_hypso          mo_bdy          mo_roads

we need to unzip and untar the dataset. On a UNIX platform the commands are as follows:

gunzip <infile_name>

tar xvf <infile_name>,

and on a Windows-NT platform the commands are as follows:

gunzip <infile_name>

tar-nt xvf <infile_name>.

An example of an untar command for a hydro file could reveal the following .ddf files:

HY01ACOI.DDF     HY01AHDR.DDF    HY01AHYF.DDF     HY01CATD.DDF    HY01CATS.DDF      HY01CATX.DDF         HY01DDSH.DDF    HY01DQAA.DDF     HY01DQCG.DDF    HY01DQHL.DDF     HY01DQLC.DDF     HY01DQPA.DDF HY01FF01.DDF       HY01IDEN.DDF      HY01IREF.DDF       HY01LE01.DDF      HY01NA01.DDF      HY01NO01.DDF   HY01NP01.DDF       HY01PC01.DDF      HY01STAT.DDF      HY01XREF.DDF

For a complete understanding and description of these .ddf files, a review of the 'DLG-3 SDTS Transfer Description' document would be necessary.

Like the ARC/INFO commands LIST and ITEMS, ARC/INFO provides two commands to get more information about these .ddf files. The first one, SDTSINFO, is generated by typing the following: SDTSINFO <in_transfer_prefix>. The in_transfer_prefix is the common 4-character prefix of the .ddf files. HY01 would be used from the above example. The command will display information about the SDTS transfer:

Standard Identification . : SPATIAL DATA TRANSFER STANDARD

Standard Version. . . . . : 1994 JUNE 10

Standard Documentation Ref: FIPS PUB 173-1

Profile Identification. . : SDTS TOPOLOGICAL VECTOR PROFILE

Profile Version . . . . . : VERSION 1.0 JUNE 10, 1994

Profile Documentation Ref : FIPS 173-1 PART 4

Title . . . . . . . . . . : SAINT CHARLES, MO / HYDROGRAPHY

Data Structure. . . . . . : DLG-3

Map Date. . . . . . . . . : 1994

Date Set Creation Date. . : 19960711

Scale . . . . . . . . . . : 24000

Comment . . . . . . . . . : This transfer requires an external data dictionary

from the U.S. Geological Survey, National Mapping

Division, with a 4-character code of DLG3, version

number 3.00

CONFORMANCE::

Composites. . . . . . . . : Y

Vector Geometry . . . . . : Y

Vector Topology . . . . . : Y

Raster. . . . . . . . . . : N

External Spatial Ref. . . : Yes

Features Level. . . . . . : All non-SDTS
 

INTERNAL SPATIAL REFERENCE::

Spatial Address Type. . . . : 2-TUPLE

Spa. Add. X Component Label : EASTING

Spa. Add. Y Component Label : NORTHING

Horizontal Component Format : BI32

Scale Factor X. . . . . . . : 0.01

Scale Factor Y. . . . . . . : 0.01

X Origin. . . . . . . . . . : 0.0

Y Origin. . . . . . . . . . : 0.0

X Comp. of Horiz. Resolution: 0.61

Y Comp. of Horiz. Resolution: 0.61
 

EXTERNAL SPATIAL REFERENCE::

Reference System Name . . . : UTM

Horizontal Datum. . . . . . : North American 1927

Zone Number . . . . . . . . : 15

GLOBAL AND DATA QUALITY MODULES::

Module No. Recs Description External

------ -------- -------------------------- --------

IDEN 1 Identification

CATD 24 Catalog/Directory

CATX 2 Catalog/Cross-Reference

CATS 24 Catalog/Spatial Domain

IREF 1 Internal Spatial Reference

XREF 1 External Spatial Reference

MDEF Data Dictionary/Definition XX

MDOM Data Dictionary/Domain XX

DDSH 48 Data Dictionary/Schema

STAT 22 Transfer Statistics

DQHL 1 Lineage

DQPA 1 Positional Accuracy

DQAA 1 Attribute Accuracy

DQLC 1 Logical Consistency

DQCG 1 Completeness
 

Number of data layers: 1

(blank)
 

Layer: (blank)

Theme: HYDROGRAPHY
 

Module No. Objs Object Type

------ -------- ------------------------------

NP01 4 Point

NE01 15 Entity point

NA01 156 Area point

NO01 326 Node, planar graph

LE01 360 Complete chain

PC01 157 GT-polygon composed of chains

FF01 1 Composite
 

ATTRIBUTE PRIMARY MODULES:: 2

Module No. Recs Theme

------ -------- --------------------

AHDR   1      HYDROGRAPHY

AHYF   581  HYDROGRAPHY

This information becomes important during the import process. Some of the information found during this process is the number of data layers, number and type of primary modules (determines if there is a 1:N or 1:1 relationship), object types, horizontal datum, zone number, and reference system to name a few.

For a more detailed look at the contents of individual .ddf files, the SDTSLIST command has been provided by ARC/INFO. This command is executed by: SDTSLIST <SDTS_module>. An example of this command is as follows:

Arc: sdtslist HY01AHDR.DDF

Processing /tmp_mnt/prod_data/ssilch/sdts/hydro/HY01AHDR.DDF . . .

Module name : AHDR

Module type : ATTRIBUTE PRIMARY
 

Field Subfield        Format                        Description

--------------------------------------------------------------

0001                                                          DDF RECORD IDENTIFIER

ATPR                                                          ATTRIBUTE PRIMARY

                            MODN                            A Module Name

                            RCID                             I     Record ID

ATTP                                                          PRIMARY ATTRIBUTES

                            BANNER                          A(72) BANNER

                            SOURCE_DATE              A(4) SOURCE_DATE

                            DATE_QUALIFIER         A(1) DATE_QUALIFIER

                            QUAD_NUMBER            A(3) QUAD_NUMBER

                            L_PRIM_INTERVAL       R(5) L_PRIM_INTERVAL

                            L_PB_INTERVAL            R(5) L_PB_INTERVAL

                            S_PRIM_INTERVAL       R(5) S_PRIM_INTERVAL

                            S_PB_INTERVAL            R(5) S_PB_INTERVAL

                            CODED_FLAG                A(1) CODED_FLAG

                            EDGEWS                         A(1) EDGEWS

                            EDGEWR                        A(1) EDGEWR

                            EDGENS                         A(1) EDGENS

                            EDGENR                        A(1) EDGENR

                            EDGEES                         A(1) EDGEES

                            EDGEER                        A(1) EDGEER

                            EDGESS                        A(1) EDGESS

                            EDGESR                       A(1) EDGESR

                            VERTICAL_DATUM   A(20) VERTICAL_DATUM

                            SW_LATITUDE           R(12) SW_LATITUDE

                            SW_LONGITUDE        R(12) SW_LONGITUDE

                            NW_LATITUDE           R(12) NW_LATITUDE

                            NW_LONGITUDE        R(12) NW_LONGITUDE

                            NE_LATITUDE            R(12) NE_LATITUDE

                            NE_LONGITUDE         R(12) NE_LONGITUDE

                            SE_LATITUDE             R(12) SE_LATITUDE

                            SE_LONGITUDE         R(12) SE_LONGITUDE

--------------------------------------------------------------

0001 = 1

ATPR MODN = AHDR

RCID = 1

ATTP BANNER = USGS-NMD DLG DATA - CHARACTER FORMAT - 09-29-87 VERSION

SOURCE_DATE = 1994

DATE_QUALIFIER =

QUAD_NUMBER =

L_PRIM_INTERVAL =

L_PB_INTERVAL =

S_PRIM_INTERVAL = 10.0

S_PB_INTERVAL =

CODED_FLAG = Z

EDGEWS = 0

EDGEWR =

EDGENS = 3

EDGENR = 6

EDGEES = 0

EDGEER =

EDGESS =

EDGESR = 5

VERTICAL_DATUM = NGVD

SW_LATITUDE = 38.750000

SW_LONGITUDE = -90.500000

NW_LATITUDE = 38.875000

NW_LONGITUDE = -90.500000

NE_LATITUDE = 38.875000

NE_LONGITUDE = -90.375000

SE_LATITUDE = 38.750000

SE_LONGITUDE = -90.375000

EOF

Since we are working with geo_datasets that have a high coordinate precision level, it will be necessary to set the precision level accordingly. This can be done by using the following command: 'PRECISION DOUBLE DOUBLE'.

The next command is SDTSIMPORT. This will create ARC/INFO coverages from the SDTS transfer. This command is executed as follows:

SDTSIMPORT <in_transfer_prefix> <out_cover> {out_point_cover} {layer_name} {DD|DROP_DD}

Polygon and line topology will now be generated. Related attribute tables will be written to the output coverage with the relate environment stored in <out_cover>.REL and/or {out_point_cover.REL} and an additional cross reference table <out_cover>.XREF will be written. These relate files will become important later in determining what items need to be joined for the 1:N relationship.

At this point we are finished with SDTS commands. We are now ready for the build command which is necessary to create the feature attribute tables needed for the coverage. The 'BUILD <cover> poly' command will define the polygon topology and create a .PAT. The 'BUILD <cover> line' command will create an .AAT for arcs. The 'BUILD <cover> node' command will create an .NAT for nodes. The 'BUILD <cover_pt> point' command will create a .PAT for points.

The 'DESCRIBE <cover>' command can now be used to reveal not only the same detailed information about the geo_dataset as the SDTSINFO command, but additional information about the spatial objects will be displayed.

Description of DOUBLE precision coverage hydrotest

FEATURE CLASSES

Number of Attribute Spatial

Feature        Number of         Attribute         Spatial

Class            Subclass          Features          data (bytes)          Index?     Topology?

______        ________         _______         _________         _______    ________

ARCS                                      360                      36

POLYGONS                            157                      28                                      Yes

NODES                                    326                      16
 

        SECONDARY FEATURES

Tics                              4

Arc Segments              6880

Polygon Labels            156
 

TOLERANCES

Fuzzy = 1.418 V Dangle = 0.000 N
 

COVERAGE BOUNDARY

Xmin = 716879.810 Xmax = 728124.230

Ymin = 4291794.710 Ymax = 4305972.740
 

STATUS

The coverage has not been Edited since the last BUILD or CLEAN.
 

COORDINATE SYSTEM DESCRIPTION

Projection UTM

Zone 15

Datum NAD27

Units METERS Spheroid CLARKE1866
 

One mistake users make with the new SDTS datasets occurs at this point. Not realizing that the attributes are not attached to the spatial elements, data users believe they have 'lost' their attributes. In reality, a JOINITEM command needs to be executed before the geo_dataset is ready for use.

Before using the JOINITEM command, the coverage info files need to be reviewed to determine if there is a 1:1 or 1:N relationship. SDTS spatial elements must use multiple pointers to their separately stored attributes. ARC/INFO cannot store these multiple pointers in the feature attribute tables. Instead, the pointers are stored in join tables.

A review of the coverage info files will review a 1:1 relationship if there are no .AJOIN, .PJOIN, .NJOIN, OR .XJOIN files. In other words, multiple pointers were not used. Join the attributes to their spatials with the following command: 'JOINITEM <in_info_file> <join_info_file> <out_info_file> <relate_item> <start_item> {LINEAR|ORDERED|LINK'. A look at the <cover>.XREF and the <cover>.REF info files will provide the relate_item, start_item needed. A typical JOINITEM command might be as follows:

Arc: joinitem hydrotest.aat hydrotest.ahyf hydrotest.aat modn_id modn_id

Unfortunately joining the attributes for a 1:N relationship is not so easy. After confirming there is a 1:N relationship, the cross reference tables can be consulted to determine what joins need to be made. The following steps are necessary to make this kind of join.
 

STEP 1:

Arc: tables

Enter Command: copy flortranrd.ajoin acoi.join

Enter Command: sel acoi.join

6954 Records Selected.

Enter Command: res modn_name ne 'ACOI'

6619 Records Selected.

Enter Command: purge

Do you want to purge all selected records (Y or N)? : y

335 Records Selected.

Enter Command: q

Leaving TABLES...
 

Arc: joinitem flortranrd.aat acoi.join flortranrd.aat flortranrd-id flortranrd-id

Joining flortranrd.aat and acoi.join to create flortranrd.aat

Arc: joinitem flortranrd.aat flortranrd.acoi flortranrd.aat modn_id modn_id

Joining flortranrd.aat and flortranrd.acoi to create flortranrd.aat
 

Arc: dropitem flortranrd.aat flortranrd.aat

Enter item names (type END or a blank line when done):

======================================================

Enter the 1st item: modn_name

Enter the 2nd item: modn_id

Enter the 3rd item:

Done entering item names (Y/N)? y

Do you wish to use the above items (Y/N)? y
 

STEP 2:
 

Arc: tables

Copyright (C) 1982-1997 Environmental Systems Research Institute, Inc.

All rights reserved.

TABLES Version 7.1.1 (Thu Feb 6 23:26:50 PST 1997)

Enter Command: copy flortranrd.ajoin ardf.join

Enter Command: sel ardf.join

6954 Records Selected.

Enter Command: resel modn_name ne 'ARDF'

664 Records Selected.

Enter Command: purge

Do you want to purge all selected records (Y or N)? : y

6290 Records Selected.

Enter Command: q

Leaving TABLES...

Arc: joinitem flortranrd.aat ardf.join flortranrd.aat flortranrd-id flortranrd-id

Joining flortranrd.aat and ardf.join to create flortranrd.aat

Arc: joinitem flortranrd.aat flortranrd.ardf flortranrd.aat modn_id modn_id

Joining flortranrd.aat and flortranrd.ardf to create flortranrd.aat

Arc: dropitem flortranrd.aat flortranrd.aat

Enter item names (type END or a blank line when done):

======================================================

Enter the 1st item: modn_id

Enter the 2nd item: modn_name

Enter the 3rd item:

Done entering item names (Y/N)? y

Do you wish to use the above items (Y/N)? y
 

STEP 3:
 

Arc: tables

Enter Command: copy flortranrd.ajoin ardm.join

Enter Command: sel ardm.join

6954 Records Selected.

Enter Command: res modn_name ne 'ARDM'

6625 Records Selected.

Enter Command: purge

Do you want to purge all selected records (Y or N)? : y

329 Records Selected.

Enter Command: q

Leaving TABLES...

Arc: joinitem flortranrd.aat ardm.join flortranrd.aat flortranrd-id flortranrd-id

Joining flortranrd.aat and ardm.join to create flortranrd.aat

Arc: joinitem flortranrd.aat flortranrd.ardm flortranrd.aat modn_id modn_id

Joining flortranrd.aat and flortranrd.ardm to create flortranrd.aat

Arc: dropitem flortranrd.aat flortranrd.aat

Enter item names (type END or a blank line when done):

======================================================

Enter the 1st item: modn_name

Enter the 2nd item: modn_id

Enter the 3rd item:

Done entering item names (Y/N)? y

Do you wish to use the above items (Y/N)? y

The above steps have now successfully joined the attributes for the .AAT. The process now needs to be repeated for the .PAT and the .NAT (if they also have a 1:N relationship).

At this time, the geo_datasets are complete and fully functional in this GIS software package.

CONCLUSION

At first glance, SDTS appeared to be another "new" product being introduced by the USGS. The concept of a transfer standard was not easy to visualize. "What happened to DLG-3?" and "I just got used to DLG-3!" seemed to be the battlecry. Understanding SDTS datasets was the biggest hurdle in this project. The easiest way to picture SDTS datasets is to compare them to a box of cheesecake mix. 'Hillsbury' cooks have developed a cheesecake that tastes great and is inexpensive to make. To share this product, the crust is separated from the filling and each is put into a separate package. These two packages are placed in a box with information about the contents of the box. Directions are then given to duplicate the cheesecake in your kitchen. But it's up to the consumer to know how to use their oven to make sure the recipe turns out correctly. SDTS datasets are a lot like the 'Hillsbury' cheesecake. DLG-3 geo-datasets are well-known USGS products. To share this product, the spatial objects are separated from their attributes and each is put into a separate package--remember the cheesecake. These two packages are placed in an SDTS dataset along with their metadata. Now, no matter what GIS software that a consumer is using, he is able to utilize this geodataset with confidence. Consumers can be assured that there will be no loss of data. Data quality and georeferencing information will be available, attributes are well defined, and a host of other problems common to transfers between dissimilar computer systems will be a thing of the past.

Unfortunately, there is no cookbook or recipe for using SDTS. There is a tremendous amount of material to be read about SDTS. SDTS documentation is not light reading (What standard is?). Therefore, there is no one explanation that answers the question "How do I use it right now?!" For the ARC/INFO users who just want to start using the data and read the instructions later (don't we all?) this AML routine should help in that endeavor. Download the dataset and AML routine. Run the AML routine. Back in business.

And believe it or not--SDTS was not born because of the following statement:

"My experience in government is that when things are noncontroversial, beautifully coordinated, and all the rest, it must be that there is not much going on."

John F. Kennedy
 

REFERENCES
(Note - some of the referenced hyperlinks have moved)

Conaway, G., 1997, "Validation of USGS SDTS-TVP to ARC/INFO Transfer".

ESRI, ARC/INFO V 7.1.1 Help.

ESRI, 1995, "SDTS - Supporting the Spatial Data Transfer Standard in ARC/INFO," White Paper, Redlands; Environmental Systems Research Institute. Available at URL: http://www.esri.com/base/common/whitepapers/ai_lit.html.

SDTS Information Home Page. URL: http://mcmcweb.er.usgs.gov/sdts

USGS, 1996, "DLG-3 SDTS Transfer Description", SDTS Task Force. Available at URL: http://mcmcweb.er.usgs.gov/sdts/training.html

USGS, "Master Data Dictionary - Users Manual". Available at URL:http://mcmcweb.er.usgs.gov/sdts/training.html

USGS, 1996, "The Spatial Data Transfer Standard- Handbook for Technical Staff", Federal Systems Integration and Management Center (FEDSIM) and the SDTS Task Force. Available at URL: http://mcmcweb.er.usgs.gov/sdts/training.html

ACKNOWLEDGMENTS

Special thanks to the SDTS Task Force at the U.S. Geological Survey for providing current SDTS technical information. Also to Gladys Conaway for her previous work with SDTS datasets. Thanks are also due to Scott Whitaker and Larry (Bob) Davis at the U.S. Geological Survey for providing technical help with AML routine writing. And thanks to Dr. David J. Barr, Professor with the University of Missouri at Rolla for providing direction and guidance on this project.