The Topological Vector Profile (TVP) is the most mature profile with approval as an FGDC standard and as a Federal Information Processing Standard (FIPS), and it is now used for large volumes of on-line USGS data. FGDC approval of the Point Profile is expected in 1997 through the sponsorship of the Federal Geodetic Control Subcommittee. FGDC approval of the Raster Profile with Basic Image Interchange File (BIIF) Extension should begin in 1997 under the joint sponsorship of the National Imagery and Mapping Agency (NIMA) and USGS. Development of the object-base profile is just beginning. It may support a reduction in the number of SDTS profiles via dynamic schema capabilities, and this should help the overall goal of easier data exchange.

DISCLAIMER

Use of specific vendor and product names is for illustrative purposes only and is not an endorsement or a criticism by the author or the U.S. Geological Survey. Recommendations and opinions expressed in this document are those of the author as a representative of the U.S. Geological Survey; however, they should not be considered official USGS positions, or official positions of other Federal agencies.

Updated versions of this document should be posted to the SDTS home page at http://mcmcweb.er.usgs.gov/sdts

INTRODUCTION

The Spatial Data Transfer Standard (SDTS) is a Federal Information Processing Standard (FIPS 173) and Federal Geographic Data Committee (FGDC) standard for the nonproprietary, vendor-neutral distribution and archive of geospatial data and for the exchange of geospatial data between dissimilar digital geographic information systems (NIST, 1992). The organizers and designers of SDTS represent more than just the federal sector and include individuals from academic, commercial, and research organizations. The implementation, acceptance, and use of a common exchange and archive standard such as SDTS is one component of the National Spatial Data Infrastructure.

Parts 1, 2, and 3 of the SDTS document constitute the base specification of SDTS. This base specification provides data standards at conceptual, logical, and physical or format levels. The SDTS base specification is intentionally very flexible so that it can accommodate all models of geospatial data. This flexibility is possible because SDTS has so many options. At the conceptual level there are several dozen types of zero-, one-, two-, and three-dimensional spatial objects to accommodate raster, vector, topological, planar, spaghetti, and other models of geospatial data. There are also options for projections, coordinate systems, datums, quality information, attribute structure, and feature content. At the logical level there are many possibilities for structuring, naming, and placing information into modules and fields. At the physical or format level, using ISO 8211, there are additional options which can be restricted if required.

PURPOSE OF PROFILES

Profiles of SDTS currently have three primary purposes. The main purpose is to be a clearly defined subset of SDTS, related to just one data model, and thus limit the available options so that translation software is much less complicated. The second purpose is to allow extensions and profile-specific changes to the base standard. The third purpose for an SDTS profile is as a mechanism for the harmonization of SDTS with other spatial data exchange and archive standards. Any single profile can serve more than one of these purposes.

The development of translation software that accommodates all of the possible spatial objects and options in the SDTS base standard would be very difficult. For example, the developers of software to translate or decode from all-encompassing SDTS to a specific planar-vector-topological GIS format would need software that could detect and react to all possible SDTS objects including objects from raster and nontopological vector data models. This "full SDTS to topological GIS" decoder would also need the capability to do raster-to-vector conversions, to enforce planar graph structure, and to derive correct topological relationships, because the incoming SDTS data could be of any type. The translation software needed to accomplish all this would be very complicated.

To make the development of translation and application software feasible, SDTS options are grouped into a limited number of subsets based on specific data models. For example, a raster profile is limited to only elements of a raster model (i.e., pixels or grid cells) and does not allow vector chains or strings or polygons. In general, a profile identifies types of SDTS spatial objects and related SDTS modules that are (1) always required, (2) allowed, and (3) prohibited in the profile. A profile can also restrict options by specifying module and file naming and ordering conventions, by specifying ISO 8211 encoding methods, and by specifying feature and attribute content requirements. These restrictions further reduce the complexity of SDTS decoder software, while not going to the extreme of being limited for use with just one product. For example, the Raster Profile is not so restrictive as to be used just for the USGS DEM product, but it can be used for a variety of raster and image products from USGS, NIMA, NASA, and others.

This strategy also allows vendors and users to implement only those portions of SDTS that are applicable to their system and data structure. By using profiles of SDTS, the software for encoding and decoding can be designed to handle just the options needed by the specific system or data type.

A second purpose for profiles to SDTS is to allow profile-specific extensions and changes to the base SDTS standard (Parts 1 - 3) which may or may not become permanent changes to the base standard. For example, the newest version of the Raster Profile includes an extension to the SDTS base standard that accommodates multi-dimensional data necessary for some National Aeronautics and Space Administration (NASA) products.

The third identified purpose for a profile to SDTS is to serve as a mechanism for the harmonization of another data exchange standard with SDTS. As noted earlier, SDTS has many options that support a variety of spatial data models. Because of this, SDTS is a very configurable standard, and a profile of SDTS can be designed to match all or part of another standard such as the Digital Geographic Exchange Standard (DIGEST), the Vector Product Format (VPF), the Graphic Data File (GDF) standard, or the Basic Image Interchange Format (BIIF).

Additional information on the purpose and development of SDTS profiles is found in articles by Szemraj, Fegeas, and Tolar (1994) and by Szemraj and Tolar (1993) (ftp://sdts.er.usgs.gov/pub/sdts/articles/).

DEVELOPMENT OF PROFILES

Because of the large variety of options within SDTS, some number of profiles are needed to make the implementation of translators easier. However, a large number of uncoordinated and unrelated SDTS profiles would defeat the goal of having a common exchange standard that improves overall data sharing. The wish to keep the number of SDTS profiles to a minimum must be balanced against the need to accommodate required data characteristics that are not supported in existing profiles.

The development of a potential new profile to SDTS begins with a group of geospatial data producers or users who act as the sponsors or "champions" for the new profile. This group may be one of the FGDC's thematic subcommittees or working groups as was the case with the Transportation Network Profile from the FGDC Ground Transportation Subcommittee, or it could be a group of agencies such as USGS and Census for the Topological Vector Profile, or some combination such as the National Oceanic and Atmospheric Administration and the FGDC Federal Geodetic Control Subcommittee for the Point Profile.

The FGDC Standards Working Group (http://www.fgdc.gov/SWG/swg.html) provides SDTS profile development assistance and coordination as part of their "FGDC Standards Reference Model" for all types of standards development. The model defines the expectations of FGDC standards, describes different types of geospatial standards, and documents the FGDC's 12-step standards development and approval process.

Typically, the data associated with this sponsoring group has some characteristics that do not appear to be supported by current profiles. Before this sponsoring group begins the development of a new profile, other SDTS options for supporting the desired data characteristics should be explored. A group who is seeking to use SDTS and who is considering a new profile should go through the following steps.

(1) Study existing profiles in an effort to find one that will accommodate their requirements.

(2) If no current profiles can be used "as is," then consider modifications, additions, or clarifications to the most similar current profile. Additions may be in the form of an annex which specifies extra options that are allowed in profile. A valid profile data set (called a "transfer") is allowed to accommodate these annex options, but valid profile translators are not required to decode this information. Clarification about the use of a profile may be provided by a product-to-profile mapping document as described later.

(3) If a new profile is indeed required, then the developers of the new profile document should follow the example of the most similar existing profile. This allows similar profiles to be grouped into families that share many common elements and that can lead to easier implementations based on using functions and software designed for earlier profiles.

(4) As a further effort to keep the number of profiles low, developers of a new profile should try to identify and include other groups of data users and producers that may have requirements for a similar new profile.

(5) Ultimate implementation and success of a profile will then include the creation of product mapping documents, the production of lots of data using the profile, the development of translation software by GIS vendors, the approval of the profile to be an FGDC, ANSI, ISO, or similar standard, and the availability of official tools to test both data and software for compliance to the profile.

As noted earlier, the development of new SDTS profiles can be justified for several reasons. The primary reasons are a need to support a different spatial data model or variation of a model that is not supported by any current profiles, the need to harmonize with other geospatial data transfer standards, and the need to provide an extension to the SDTS base standard. The Transportation Network Profile was developed in large part because the other vector profiles did not adequately support the data model needed for the direct representation of overpassing roadway segments using primitive nonplanar graph elements.

There are also a number of less valid reasons for new profile development that should be mentioned. Differences in application area or feature content, by themselves, should not justify different profiles. For example, the justification for a railway profile, a pipeline profile, and transmission line profile because of different content is questionable. The Transportation Network Profile is designed for transportation content, but its justification is due to a data model difference and not specific content. The DIGEST Vector Profile does mandate the use of the Feature and Attribute Coding Catalog (FACC) content specification, but this content requirement by itself does not accomplish harmonization between SDTS and DIGEST and would not justify a separate profile. The transfer of specific content is not primarily an issue for profiles, but should be addressed through possible volumes of SDTS Part 2, feature registers, or master data dictionaries related to thematic areas and guided by the Thematic Subcommittees of FGDC. The Army, Corps of Engineers, Tri-Service CADD/GIS Technology Center (http://mr2.wes.army.mil/) is currently working with FGDC on the development of a common thematic feature registry which is based on the SDTS model of features, attributes, and value domains.

Differences in data products and GIS formats are also not good reasons to develop new profiles. For example, the need for a DLG-3 profile, a TIGER profile, an Arc/INFO profile, an MGE profile, a SmallWorld profile, a MapInfo profile, a wetland profile, an elevation profile, an EPA River Reach profile, a GDT profile, and an ETAK profile is doubtful. This type of profile proliferation defeats the goal of SDTS to make data exchange easier, and should be avoided.

FAMILIES OF PROFILES

The grouping of profiles into families is one way to help organize and emphasize the relationships between profiles. Once a new profile is justified, developers should seek to maximize the similarities with other profiles, particularly with similar profiles in the same family.

A family of profiles is an informal set of profiles that have many common characteristics and that have translators with many identical functions, usually because they are based on similar high-level data models. For example, the Topological Vector Profile, the DIGEST Vector Profile, the Transportation Network Profile, the AUSLIG Vector Profile, and the NonTopological Vector Profile may be in the same family of vector profiles. The translators for profiles within the vector family of profiles should have more functions in common than functions which are different. In general, the grouping of profiles into families can foster software reusability, and in particular, will increase the reuse of translator functions and testing functions.

There may also be a type of multiple inheritance among profile families. For example, the DIGEST Vector Profile may be a member of the large vector family, the smaller topological vector family, and the DIGEST family which could include possible DIGEST Raster and DIGEST Spaghetti profiles.

MULTIPLE DATA PRODUCTS SHARING ONE PROFILE

As noted earlier, a profile should not be so specific that it is related to just one native format, one product, or one theme. A profile should be flexible enough to be shared by multiple data formats and data structures that have a similar data model. The relationship, or mapping, between a specific product and an SDTS profile should be clearly described in a product mapping document. There can be several product mapping documents for each profile, e.g., DLG-3 to TVP, TIGER to TVP, National Hydrography Data to TVP. Figure 1 shows the relationships between the SDTS base standard, profiles of SDTS, and specific products that are mapped to profiles. Some product mapping documents are available on-line through the SDTS site as noted below in the specific profile status descriptions.

STATUS OF PROFILES

The following is a list of the profiles discussed in this section. Many of these are only suggestions and may not become actual profiles. Additional profiles may also be planned by other groups but are not know to the author at this time. Information in this section is subject to additions and corrections.

1. Topological Vector Profile, SDTS Part 4

2. Raster Profile with BIIF Extensions, SDTS Part 5

3. Point Profile, SDTS Part 6

4. CADD Profile

5. Transportation Profiles

6. Cadastral Data Transfer Standard (Profile)

7. Primitive, NonTopological Vector Profile

8. Non-US Profiles and Versions of SDTS

9. DIGEST and VPF Profiles

10. Harmonized ISO/DIGEST/S-57/GDF/NTF/SDTS/IHO Profile

11. Object-Based Profile for Transactions, Multiple Representations, Dynamic Content, etc.

12. Other Profiles: Graphic, Local Government, Mining, Utility, S-57, Boundaries, etc.

REFERENCES