FGDC SDTS Workshop, Tues. Sept. 16, University of Missouri - Rolla SDTS PROFILES Charles Hickman U.S. Geological Survey Rolla, Missouri chickman@usgs.gov ABSTRACT The Spatial Data Transfer Standard (SDTS) is a Federal Geographic Data Committee (FGDC) standard for the vendor-neutral distribution, exchange, and archive of geospatial information. SDTS has many options to support various models of geospatial data. The development of a single translator that can accommodate all of the options and models supported by SDTS is not currently practical. Using a subset, or profile, of SDTS is a way to reduce the number of options. A limited number of complementary profiles, grouped into families, will support more feasible implementations of SDTS translators and tools within the GIS industry. SDTS profiles are differentiated primarily by their geospatial data models. The types of existing or proposed SDTS profiles include topological vector, raster, transportation, computer-aided drafting and design (CADD), nontopological vector, object- based, cadastral, graphic, geodetic point, and Digital Geographic Exchange Standard / Vector Product Format (DIGEST/VPF). These profiles are in varying states of use, approval., development, and discussion within the geospatial data community. 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). 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. Additional information is sought by the SDTS task force (sdts@usgs.gov). 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. 1. Topological Vector Profile (TVP), SDTS Part 4 Intended Use -- The TVP is designed to transfer digital geospatial vector data that conforms to a planar graph and has both "chain to node" and "chain to area" topological relationships. Chains, nodes, points, areas, and composite objects are the primary components. Census TIGER data and USGS DLG data can use the TVP. The TVP can accommodate both feature-based and non-feature-based data. Feature-based information, using SDTS composite objects, can be nonplanar even though the spatial primitives are planar, and can support many-to-many relationships between features and location primitives. Primary Sponsors, Interested Groups, and Contacts -- USGS is now using the TVP for on-line distribution of all DLG data. FWS has sample National Wetland Inventory data in TVP. Census has sample TIGER data in TVP and may use the TVP for Framework boundary data. FEMA plans to put flood boundary data into the TVP. BLM plans to put land management data into the TVP as one option within the new Cadastral Data Standard. Other federal and state agencies are investigating use of this profile for their vector data. Contact the SDTS task force via e-mail at sdts@usgs.gov Additional information is available on-line at the SDTS web site http://mcmcweb.er.usgs.gov/sdts Documents -- The TVP exists as a documented part (Part 4) of FIPS 173-1 (SDTS). Version 1.0 of the TVP dated June 10, 1994 is now out of print. A draft ANSI version of the TVP, dated December 13, 1995, with minor editorial changes is available at the SDTS web site http://mcmcweb.er.usgs.gov/sdts Preparation of TVP and other SDTS documents for ANSI review and approval is now underway by private contract. Additional documents, that describe the specific product mappings to SDTS- TVP from TIGER, DLG-3, and DLG-F, are also available at the SDTS web site. Several articles on SDTS and the TVP have been in GIS-related journals including "Understanding SDTS Topological Vector Profile Implementation" by Bob Lazar in the June 1996 issue of Geo Info Systems. The ESRI White Paper "SDTS-Supporting the Spatial Data Transfer Standard in ARC/INFO" is available at http://www.esri.com/resources/papers/papers.html Software -- Software that supports the TVP is part of the suite of SDTS++ public-domain tools for access and interface to SDTS. Contact the SDTS task force (sdts@usgs.gov) or check the SDTS web site for details. Translators -- TVP translators are supported by ESRI (Arc/INFO 7.04 and above), Intergraph (MGE), GRASS, ERDAS (using ESRI translator), and AST GeoMorph; are planned by MapInfo, UNISYS, SAFE FME, Laser-Scan (for South Korea), and LAS GrassLand; and are being considered by Applied Geographics, Autodesk, and SmallWorld based on customer demand. Data -- Sample TIGER, DLG, and NWI data is available in SDTS-TVP. Nationwide USGS 2-million, 100K, and 24K DLG-3 transportation, hydrography, PLSS, and boundaries data is now available in the TVP. Conformance Testing -- A beta series of conformance testing involving NIST, USGS, Intergraph, and ADC was conducted in 1996. Official conformance testing will begin in the near future through private contractors. With the large volume of DLG-3 data now in SDTS, the temptation may be to develop SDTS-TVP translators that are based on DLG-3 content specifications. This limits the utility of the translator and should be discouraged. Conformance testing of translators should help avoid this problem. A good SDTS-TVP translator should be content independent and product independent so that it accommodate SDTS-TVP data not just from USGS, but from Census, BLM, and others. Future Plans -- ANSI and ISO approval for the TVP (SDTS Part 4), along with Parts 1, 2, 3, 5, & 6 of SDTS, will be sought. Development and approval of conformance testing tools and procedures will soon be moved to the private sector. More USGS data in SDTS-TVP will become available as a regular part of the production process. SDTS will be the standard distribution format for USGS- NMD digital geospatial data products. An on-line help desk at sdts@usgs.gov is now in place, and better tools and experience with TVP translators are being investigated. 2. SDTS Raster Profile with Basic Image Interchange Format (BIIF) Extension (SRPBE), SDTS Part 5 Intended Use -- SDTS Part 5 is designed for the transfer and archive of digital geospatial raster, grid, and image data. The primary SDTS objects are grids and grid cells. USGS is now using Part 5 for the distribution of DEM's. Future use of the SRPBE for USGS DOQ's and DRG's is also being considered. The BIIF extension supports image data and provides a connection with image standards used in the military and intelligence communities. Part 5 can also reference separate files which use standard compression methods. Part 5 takes advantage of the capabilities of both SDTS and BIIF. SDTS has a geographic information focus and provides the capability of encoding raster grid and image data, georeferenced information, simple color look-up tables, data quality reports, data dictionary information, and other such metadata. ISO/IEC 12087-5 Basic Image Interchange Format (BIIF) has an image transmission focus and provides an efficient image file format, image compression, image blocking or tiling, variety of color models, and visualization controls. The portion of BIIF that is common with SDTS Part 5 is also within the scope of the National Imagery Transmission Format / NATO Secondary Imagery Format (NITF/NSIF) profile to BIIF. The integration of SDTS and BIIF provides a foundation for interoperability in the interchange of raster and imagery data among applications. Once Part 5 is approved by FGDC, DOD will begin planning the distribution of raster products (e.g., NITF-based products) using SRPBE. Primary Sponsors, Interested Groups, and Contacts -- USGS will use Part 5 for raster and image data distribution, beginning with DEM data in 1997. The primary developers of Part 5 are the National Imagery and Mapping Agency (NIMA) and USGS. Other contributors include the Joint Interoperability Test Command (JITC), the BIIF editorship, Geomatics Canada, NOAA, and the Digital Geographic Information Exchange Standard (DIGEST) team under NATO. Representatives from these agencies formed the Raster Standards Convergence Working Group (RSCWG). The RSCWG, through the FGDC's Subcommittee for Base Cartographic Data (SBCD) has submitted SDTS Part 5 for FGDC approval in 1997 or early 1998.. Contact the SDTS task force at sdts@usgs.gov Additional information is available on-line at the SDTS web site http://mcmcweb.er.usgs.gov/sdts Documents -- The SRPBE exists as a documented part (Part 5) of SDTS. A working draft is dated July 1997. A public-review version of the document should be available in September 1997 from the FGDC Standards Working Group site at http://www.fgdc.gov/SWG/ or from the SDTS site at http://mcmcweb.er.usgs.gov/sdts An additional document that describes the product mapping to the Raster Profile from USGS DEM is also available at the SDTS web site. The article "Developing a Raster Profile for the Spatial Data Transfer Standard" by Dave Greenlee is in the December 1992 issue of Cartography and Geographic Information Systems. Software -- The Common Software Platform and the SDTS++ toolkit provide access tools that can be used for Part 5. Translators -- Raster profile translators have been developed for ERDAS and MicroDEM. Data -- Sample raster profile DEM data for Mt. St. Helens is available at the SDTS web site. The SDTS site also has sample multispectral image and thematic data from ERDAS. Nationwide DEM data is being mass converted to the SRPBE and will be available in 1998. Conformance Testing -- Arrangements for conformance testing of Part 5 are not yet defined, but may be done through DOD facilities. Future Plans -- The review period for the "proposal" for FGDC approval of SDTS Part 5 closed September 1, 1997 (http://www.fgdc.gov/SWG/sub4_1.html). FGDC will now prepare for the review of the actual profile document as one of the next steps to gain FGDC approval. ANSI and ISO approval for SDTS Part 5, along with Parts 1, 2, 3, & 4 of SDTS, will also be sought. Development and approval of conformance testing tools and procedures is planned. Additional Part 5 translators are anticipated. More data (USGS DEM's) in SRPBE will become available in 1998. Use of Part 5 for USGS DOQ's and DRG's is being considered. The Naval Research Laboratory and the National Ice Center have plans for an Arctic ice climatology CD using the Raster Profile of SDTS. NOAA is converting raster sea ice data from SIGRID format to SDTS. EarthWatch, Inc. is investigating SDTS and Part 5 as a possible output format for images from its EarlyBird satellite. Bechtel Nevada and DOE are also investigating Part 5 for airborne multispectral scanner data at the DOE Remote Sensing Laboratory. There is a need to identify and explore common interests with the GeoTIFF effort (Ritter & Ruth, 1997). Developers of GeoTIFF indicate that there may not be new versions of GeoTIFF and there may be an effort to define an implementation relationship between GeoTIFF and SDTS, much like the SDTS relationship to BIIF. See also "Re: Relationship between GeoTIFF and SDTS" (1996) from Niles Ritter at http://www.pci.on.ca/~warmerda/geotiff/msg00277.html and the GeoTIFF page at http://home.earthlink.net/~ritter/geotiff/geotiff.html The OGC OpenGIS activity, through their Earth Imaging Working Group (EIWG), is interested in strengthening the imagery portion of the OpenGIS specification's Open Geodata Model. Common requirements should also be explored with the hydrographic, maritime, and bathymetric communities, including IHO, IMO, NOAA, NIMA, Coast Guard, and FGDC Bathymetric Subcommittee. These groups have some standards for raster (and hybrid raster-vector) nautical charts related to Electronic Chart Display & Information Systems (ECDIS) and Raster Chart Display Systems (RCDS). These standards include HCRF format for the Admiralty Raster Chart Service (ARCS), DIGEST raster form, and BSB format for Raster Nautical Charts (RNC's). Support for raster-based transactional (change-only) updates to small, indexed areas or tiles, and "print on demand capabilities" are important developments in this community. The SRPBE may be related to recommendations from the 1992 IDON report on a DIGEST Vector Profile to SDTS that also suggested a DIGEST Matrix Profile and a DIGEST Raster Profile to SDTS. The Raster Product Format (RPF), used for a number of NIMA products (e.g., ADRG), should also be included in the scope of this continuing harmonization activity. The USGS reached agreement with the National Aeronautics and Space Administration (NASA) in 1993 to harmonize SDTS with the Hierarchical Data Format (HDF) proposed as the distribution format for all Earth Observation System (EOS) data collected by NASA in the future. This harmonization is challenging because HDF and SDTS have differing goals and perspectives, but they also share common raster data structures. The differences preclude complete definition of one in terms of the other. However, the two agencies have agreed to develop a strategy to bring the two standards into alignment. The National Center for Supercomputing Applications (NCSA) was recommended to lead the harmonization study. See the HDF page at http://hdf.ncsa.uiuc.edu/ "This harmonization study would not propose eliminating either one of these standards, but would focus on overlapping structures and data elements common to both, and would identify ways of bringing the two standards closer together." (Szemraj, 1994). The current goal is to have the appropriate level of SDTS capability available in version 1.0 of the EOS Data Information System (EOSDIS), but no work is presently underway. The proposed FGDC "Content Standard for Remote Sensing Swath Data" should also be studied for potential relationships to SDTS Part 5. This new swath data model for remote sensing "supports the development of the NSDI by providing a common framework for the organization of a wide range of remotely sensed data. The model will be particularly useful for data from scanning, profiling, staring, or push-broom type remote sensing instruments, whether they be ground based, shipboard, airborne, or space borne." This model will provide "a solid basis from which to develop interoperable data formats for this common form of remote sensing data. The data model shall define the minimal content requirements for a swath and the relationships among its individual components. It shall also discuss the treatment of optional supporting information within the swath model." [text from proposal on FGDC Standards Working Group web pages]. 3. Point Profile, SDTS Part 6 Intended Use -- The Point Profile is designed to transfer and archive digital geospatial point data that can have very precise locations. Points are the primary components. Chains, areas, grid cells, and topological relationships are not supported in this profile. High precision National Geodetic Survey (NGS) geodetic network control point data and Bureau of Land Management (BLM) survey point data can use this profile. Primary Sponsors, Interested Groups, and Contacts -- The FGDC Federal Geodetic Control Subcommittee (FGCS), National Oceanic and Atomospheric Administration (NOAA) National Geophysical Data Center (NGDC), and NOAA NGS are the primary sponsors and coordinators for this profile. NGS plans to distribute data for more than one- million control points using the SDTS Point Profile. Additional interest in the point profile has come from BLM, the Software Information Systems Council of Ag Electronics Association (AEA) (precision agriculture), and from the Survey Data Management System (SDMS) task force of the American Association of State Highway Transportation Officials (AASHTO). Information about the Point Profile is available at the FGCS home page http://www.ngs.noaa.gov/FGCS/fgcs.html and click on "FGCS Technical Publications." Documents -- NOAA and USGS have worked to develop a draft document for the Point Profile that uses the TVP document as a guide. The December 1996 draft version of the Point Profile (SDTS Part 6) is available at http://www.ngs.noaa.gov/FGCS/sdtsp.html or http://www.fgdc.gov/pub/standards/SDTS_pt_profile/ The Point Profile has passed 11 of the 12 steps for formal FGDC approval. All that remains is final endorsement by the FGDC Steering Committee, which should occur in the second half of 1997. Information on the status the Point Profile is available from the FGDC Standards Working Group site at http://www.fgdc.gov/SWG/swgstat.html Software -- Software that supports the Point Profile will be part of the Common Software Platform (CSP) and the SDTS++ toolkit for access and interface to SDTS. Contact the SDTS task force (sdts@usgs.gov) for details. NOAA-NGDC is also building Point Profile encoders and decoders using their "FreeForm" software. Translators -- NOAA NGDC has been in contact with GIS vendors relative to Point Profile translators. A Point Profile translator may be available in version 8.x of Arc/INFO. Data -- NOAA NGS plans to distribute data for more than one-million control points using the SDTS Point Profile. Conformance Testing -- Conformance testing may be arranged after FGDC approval. Future Plans -- ANSI approval may be sought after FGDC approval. The use of the Point Profile for PLSS corners and for bathymetric soundings may be considered. The relationship of SDTS and the Point Profile to other point, geodetic, and surveying formats should also be investigated. These formats include: SDMS from AASHTO, IDEX from Lieca, the GPS format from the National Marine electronics Association (NMEA), the Receiver Independent Exchange (RINEX-2) format from NOAA-NGS, the Open Navigation Format, the WM102 format, the commercial .SSF format, and the WISCON coordinate format from Wisconsin DOT. 4. Computer-Aided Design and Drafting (CADD) Profile Intended Use -- The purpose of a generic CADD profile to SDTS is to support the exchange, transfer, and archive of CADD spatial data. It is intended for CADD users who are doing GIS-type activities. It is not needed for CADD data which does not have geospatial data requirements. The CADD profile may require the use of SDTS arcs (i.e., mathematically defined curves such as circles and splines) in addition to other vector elements. Topological relationships may not be required. 3-D volume elements and other unique CADD elements may be required. Primary Sponsors, Interested Groups, and Contacts -- The FGDC Facilities Working Group and the U.S. Army Corps of Engineers through the DOD Tri-Service CADD/GIS Technology Center are the primary sponsors of the CADD Profile. The Tri-Service Center is working with Cordant, Application Software Technologies (AST), and Intergraph on initial investigations of a CADD Profile. Additional interest in a CADD profile has come from AutoDesk. Documents -- "Scope of Work" contracts for the SDTS CADD Profile were awarded by the Tri-Service group to Cordant and to Intergraph in late 1995. The 1996 reports "Development of a Spatial Data Transfer Standard (SDTS) Profile for the Translation of MicroStation CADD Elements" from Intergraph and "Development of a Spatial Data Transfer Standard (SDTS) Profile for Translation of AutoCAD CADD Elements" from AST are available on the FGDC Facilities Working Group data standards site at http://corps_geo1.usace.army.mil/FGDC/data_standards.html The October 1996 proposal for a CADD profile is available at http://www.fgdc.gov/pub/standards/CADD/procadd.txt The CADD Profile has passed the first 3 of the 12 steps for formal FGDC approval, and a project to develop the profile has been endorsed by the FGDC Standards Working Group (SWG). Information on the status the CADD Profile is available from the FGDC SWG site at http://www.fgdc.gov/SWG/ The document "SDTS CADD Profile: for Tri-Service CADD/GIS Center" from Aztech Corp. became available in August 1997. This document will be sent to the FGDC Standards Working Group from the FGDC Facilities Working Group to begin the review process. Future Plans -- ANSI approval will be considered after FGDC approval. The role of an SDTS CADD Profile in relationship to ANSI IGES, PDES/STEP, and ISO 10303 should be investigated. A CADD profile to SDTS should have an easy translation to PDES-STEP/CADD. The extension of PDES to accommodate GIS through an ISO 10303 application protocol for GIS has been mentioned. The DWG graphics file format has also been mentioned as a possible industry standard for geospatial and CAD data. A January 1996 A/E/C Systems article indicates that an object-based model is recommended for CAD data exchange. Additional investigation is needed to determine how the proposed CADD profile may be similar to the proposed SDTS object-based profile and nontopological vector profile. 5. Transportation Profile(s) Including: (1) current Transportation Network Profile (TNP), (2) proposed complete transportation transfer profile, (3) proposed ITS profile with subprofiles. Intended Use -- The current and proposed transportation profiles to SDTS are all designed to transfer and archive digital geospatial data about transportation networks (e.g., roadways, railways, navigable waterways, transit systems), transportation facilities, and related events and features. (1) TNP -- The TNP is designed to allow the seamless representation of overpassing roadways using spatial primitives that need not be broken at overpasses and underpasses. To accommodate this, TNP data is not limited to a planar graph at the basic geometry element level. "Chain to node" relationships are the only required topological relationships between spatial primitives. Areas are not required. The primary SDTS objects are network chains, nodes, and composite objects (used for routes). Some sample railway data in SDTS-TNP is available. Future use of the TNP by the US DOT for data distribution and data exchange will be considered after reconciliation of the TNP with the proposed SDTS ITS (GDF) profile, and reconciliation with the a proposed transportation profile to SDTS that supports linear referencing and is based on a complete enterprise GIS-T data model. (2) Complete Transportation Profile -- The proposed, more complete, transportation transfer profile to SDTS will be based on an enterprise GIS-T data model from the recent work of Ken Dueker and Al Butler (1997). One aspect of this profile is more support for the linear location referencing of both tangible objects and characteristics from the earlier LRS data model research coordinated by Alan Vonderohe and refined in the ISTEA Pooled Fund work of David Fletcher and associates. For transportation data, SDTS needs to "provide an attribute-centric way to transfer transportation system characteristics independently of cartography" [from Dueker & Butler, 1997]. The enterprise GIS-T model supports multiple, independent cartographic representations, e.g., bridge geometry as points or point events at low resolution and as strings or linear events at high resolution. It supports variable linear feature segmentation as an alternative to rigid segmentation. New or modified SDTS terms are included, with a greater distinction between (i) geographic or real-world references and locations and (ii) cartographic references and locations for map related CAD and GIS graphic elements. New linear datum objects include anchor points, anchor sections, and reference points. The use of a "transportation feature" with a permanent, unique identifier within a jurisdiction is included. There is advanced support for names. Junctions can be subtyped as intersections, interchanges, overpasses, intermodal connections, and intersections with boundaries; and they can be related to points at small scales and strings or interchange drawings at large scales. These junctions can be linked to information for traffic control, turn possibilities, overpass loads, and underpass clearances. The Dueker/Butler model also provides support street addresses as a for of linear referencing. (3) ITS Profile -- An Intelligent Transportation Systems (ITS) profile to SDTS, or a Graphic Data Files (GDF) profile to SDTS, has been proposed by the ITS community in the U.S. (ITS America, NavTech, ETAK, AAA, Ford, Oak Ridge, SAE, etc.). The ITS profile to SDTS will probably be based on GDF, but there is a small chance that it could be non-GDF. "What is GDF? "GDF Geographic Data Files is a European [CEN] standard, that is used to describe and transfer road networks and road related data. It is much more than a generic GIS standard, because GDF gives rules how to capture the data, how the features, attributes, and relations have been defined. "... It's primary use will be for car navigation systems (Bosch, Philps, Volvo, etc.), but it is very usable for many other transport and traffic applications..." [From http://www.ingr.com/ehq/gdf] GDF (CEN, 1995) uses a feature-based model, similar to DIGEST/VPF and USGS DLG-F (Hickman, 1995). This allows use of a topologically structured planar graph at the primitive geometry level, while supporting nonplanar transportation network components (seamless, overpassing road segments) at the simple feature level. GDF also supports multi-scale feature representations, and explicit relationships between features. ISO TC 204 WG 3 subgroup 3.1 is working on an international map database transfer standard for ITS based on an ISO update of GDF from CEN TC 278. The ISO version of GDF should be available in 1998. GDF uses ISO 8211 at the physical implementation level, similar to SDTS and DIGEST. GDF provides some basic support for linear location referencing. Attributes in GDF are associated with a "feature in such a way that they reference a certain part of it. These attributes are called 'Segmented Attributes.' With line features, the part which is referenced by the segmented attributed is defined by a 'position from' and a 'position to' value. These positions represent the curvimetric distance" [from 1992 GDF Attribute Catalogue]. Curvimetric distance is based on the representational geometry, which may not be as robust as the linear location referencing used in the other transportation profile proposed by Dueker and Butler. Version 3.0 of GDF (CEN, 1995) accommodates addresses in section 5.2.10 (Address Area). In a 1994 meeting, the IVHS America (now ITS America) Standards and Protocols Subcommittee on Map Databases and Information Systems developed requirements for a GDF profile to SDTS. These requirements included possible specific subprofiles based on ITS business areas, including Advanced Public Transportation Systems (APTS) (Watje & Okunieff, 1995), Commercial Vehicle Operations (CVO), and Advanced Vehicle Control Systems (AVCS). The APTS subprofile to SDTS was also suggested as a transit subprofile to the TNP. Primary Sponsors, Interested Groups, and Contacts -- (1) The FGDC Ground Transportation Subcommittee (GTS) and the US DOT Bureau of Transportation Statistics (BTS) were the primary sponsors of the TNP, with development work done at the Volpe National Transportation Systems Center. Additional information is available on-line at the BTS web site http://www.bts.gov/ or the FGDC Ground Transportation Subcommittee (GTS) web site http://www.bts.gov/fgdc/fgdc.html The FGDC GTS is also very interested in GDF-based transfer standard with more linear location referencing support. (2) Prof. Ken Dueker at Portland State University and Al Butler from Florida have recommended the complete transportation profile based on an enterprise GIS-T data model. E-mail for this issue can be sent to Al Butler at abutler@nettally.com (3) ITS America, Oak Ridge National Labs, and Viggen Corp. are involved with the ITS profile. Documents -- (1) Requirements for the TNP have been documented. Version 1.1 of the TNP is dated February 1, 1996 and is available at the BTS or FGDC GTS web sites (2) The 1997 document "GIS-T Enterprise Data Model with Suggested Implementation Choices" by Dueker and Butler is available at http://www.upa.pdx.edu/CUS/ and includes SDTS recommendations for transportation in Appendix 5. (3) Requirements for an ITS profile were developed by ITS America's Standards and Protocols Subcommittee for Map Database and Information Systems in 1994. More GDF-specific information is available at http://www.intergraph.com/ehq/gdf/index.htm Software -- SDTS TNP Encoding Software has been developed at the US DOT Volpe National Transportation Systems Center, Cambridge, Massachusetts. Information is available at the FGDC GTS web site. SDTS TNP, as well as SDTS TVP, are supported by the GeoMorph conversion tool developed by Application Software Technologies, Inc. Future Plans -- GDF, along with SDTS, DIGEST, and similar exchange standards have been suggested as ISO standards (see later section on ISO harmonization). Some reconciliation among standards may be required by ISO. The proposed ITS (GDF) profile to SDTS fits into this harmonization effort. SDTS is a configurable standard so it can be made to accommodate the models of other standards such as the feature-based models of GDF and DIGEST/VPF. Because of the configurable nature and model independence of SDTS, it has been recommended as a "harmonizing agent" or "umbrella" for other standards. DIGEST should also be considered in this transportation discussion because it is now designated as a civilian transportation standard in Canada and as a general standard by the defense communities of many nations. The requirements and possibilities for one or two new transportation profiles to SDTS need to be clarified and documented. Some of the overlapping possibilities may include the following. (a) Wait for several possible developments. Wait, watch, and react to further standards developments at the ISO level among SDTS, GDF, and DIGEST/VPF (discussed later). Wait for further SDTS developments, e.g., a more inclusive object-based profile (discussed later) which may be related to an archive standard for OpenGIS. Wait for further momentum or requirements from FGDC, e.g., for framework distribution and archive. Wait for further requirements and demand from major data producers and GIS vendors. Wait for sufficient user dissatisfaction with current use of format translators for spatial data exchange. Use SDTS-TVP (see D. Schmidt 1997 thesis) for transportation data exchange while waiting. (b) Replace or modify the TNP into two transportation standards; a GDF profile to SDTS to accommodate the ITS community and an enterprise GIS-T profile. Doing GDF, GIS-T, and SDTS all at once may (or may not) be too large an initial task. An ITS profile may be a first step, with the intention to include GIS-T and LRS requirements as a second step after learning from the first step. (c) Define an overall architecture or approach (Butler, 1997 correspondence), then develop a single, combined GIS-T and GDF-based ITS profile to SDTS as "THE Transportation Profile to SDTS." This will help avoid rendering any initial components obsolete. (d) Work with developers of a proposed object-based profile to SDTS and with the new OGC (OpenGIS) Transportation Domain Technical Working Group to include complete transportation and GDF requirements in the object- based profile. There are various pros and cons for each of these possibilities. Some transportation specific presentations and discussions are planned for an SDTS workshop in September, 1997. This document should be updated after those meetings. 6. Cadastral Data Transfer Profile Utilizing SDTS Intended Use -- The Cadastral Data Transfer Profile will support the vendor-neutral transfer of cadastral data that complies with the FGDC Cadastral Data Content Standard. This profile will accommodate survey data from the Bureau of Land Management (BLM) Automated Land and Mineral Records System (ALMRS). The Cadastral Data Transfer Profile is not strictly a new profile of SDTS, but is a mechanism for the exchange of cadastral information using a combination of SDTS and three other FGDC standards. Developers hope to take advantage of the existing Topological Vector Profile (TVP) of SDTS., with some consideration for the new Point Profile. Primary Sponsors, Interested Groups, and Contacts -- The FGDC Cadastral Subcommittee and BLM are the primary sponsors and coordinators for this profile. TRW is also involved in the activity through BLM. Information on the Cadastral Subcommittee efforts toward Cadastral standards is available through the main FGDC web site http://www.fgdc.gov Future Plans -- Work on the Cadastral Data Transfer Standard was placed on hold until completion of the Content Standard for Cadastral Data. The Content Standard for Cadastral Data now has formal FGDC endorsement. The Content Standard includes circular curves and other curves with constantly changing direction. These curves are supported in SDTS as "arcs," and are options in the current TVP but require redundant coding as lines in a TVP transfer. This means that decoders that do not support arcs would still be able to decode the information using the redundant lines. This is one of several issues for developers of the Cadastral Data Transfer Profile. More information will be available after the September 1997 SDTS workshop presentations by individuals from BLM and TRW. 7. Primitive, NonTopological Vector Profile a.k.a. Primitive SDTS Vector Profile, SDTS Lite, Clean Spaghetti Profile to SDTS, Primitive Transfer Standard, Simple Spatial Form, DIGEST Spaghetti Profile Intended Use -- A primitive, nontopological, vector profile to SDTS has been suggested as a way to transfer digital vector geospatial data that is not constrained to a planar graph and not structured using topological relationships. This type of data is sometimes referred to as "spaghetti" data and may use SDTS strings. Graphic, topological, and raster elements would not be allowed. One purpose of a "primitive" profile is to simplify SDTS for desktop systems and low end map data users, and make it work for "the little guy." All-ASCII physical encoding and limited-metadata requirements have also been mentioned as part of this primitive vector profile. The USGS considered a nontopological vector profile at one time for the distribution of a proposed, but later rejected, elevation product of tagged vector contour (TVC) data. The USFS Cartographic Feature File (CFF) data might be appropriate for a nontopological vector profile. Based on a request from Henry Tom (NIMA & ANSI), the SAIC contractors to NIMA proposed a Simple Spatial Form (Special Sub-Profile) of SDTS and DIGEST during a 1996 meeting on the harmonization of SDTS and VPF. This Simple Spatial Form would be composed of "clean" spaghetti data, which does not have explicit topological relationships but could be topologically structures quickly without needing a separate cleaning step to find and remove small gaps, overshoots, and slivers. The SAIC proposal included a one-to-one relationship between spatial primitives and basic features, thus keeping some of the feature-based flavor of VPF. Discussion of this simple, clean spaghetti, profile included suggestions for its use for NSDI Framework, for a Tri-Services CADD profile, and for OpenGIS "well known structures." Primary Sponsors, Interested Groups, and Contacts -- USGS researchers in Reston and Woods Hole, in addition to individuals from the Virginia State Geologist's Office and the Dept. of Geology at the College of William and Mary were the original advocates for this profile. Several individuals at the 1996 meeting on SDTS and DIGEST also expressed interest in this concept, including representatives from NIMA, SAIC, Tri-Services, and OGC. Information from the June 1996 Woods Hole meeting on this issue is available from Robin Fegeas of USGS. Notes from the September 1996 Reston meeting with NIMA and SAIC are available from Charles Hickman of USGS (chickman@usgs.gov).. Future Plans -- The requirements for an primitive, nontopological, vector profile to SDTS may overlap some of the requirements for a CADD profile, an object-based profile, or a DIGEST spaghetti profile. This should be investigated. One purpose for a simple, vector, all-ASCII profile is to help avoid the complexity of SDTS (or VPF). Current development by USGS and contractors of improved, windows-based tools to read, write, and view SDTS and ISO 8211 will hide much of this complexity, and may lessen the need for an ASCII implementation (rather than ISO 8211) of SDTS, and remove some of the requirements for a simple profile. Richard Hogan from the FGDC states, "What they [users] want is a complex solution that is invisible to them - powerful applications with 'point and click' interfaces - lossless transfers of complex spatial data that requires no user interaction or understanding of the underlying standards. ... Complex tools that help application developers 'hide' SDTS is [the right way to go]." Several of these new tools will be presented at the September, 1997 SDTS workshop. Keeping a single (ISO-8211) physical implementation of SDTS will also help with the overall data exchange situation. 8. Non-US Profiles and Versions of SDTS Use of SDTS has not been limited to the Unites States. Several nations have formally adopted SDTS, with modifications to the base document, such as removal of State Plane Coordinate System capabilities which are US specific. SDTS is also being used and considered in several other nations but has not yet achieved formal adoption. Current interest in SDTS seems strongest in Asia, the Pacific rim, and eastern Europe. Versions of SDTS that are modified to meet national requirements are not necessarily the same as profiles to SDTS, but there are some similarities. National versions of SDTS and profiles to SDTS can both prescribe limits and extensions to the base US SDTS standard. If a harmonized, international form of SDTS (with DIGEST, NTF, GDF, S-57, etc.) becomes an ISO standard, then nation-specific profiles to ISO SDTS may not be required, thus improving overall data exchange capabilities. Australia and New Zealand -- The combined Australia and New Zealand standards group at the Australasian Spatial Data Exchange Centre (AUSDEC) has adopted SDTS with some modifications as AS/NZS 4270 which is a voluntary national standard in both nations. A 1991 draft document for the AUSLIG "profile" to SDTS was developed. SDTS is currently being used within the land information community in Australia. Additional information on this activity is available in "Internationalizing SDTS: An Australasian Experience" by Don Miller and Richard Hume in the July 1994 issue of Cartography and Geographic Information Systems. The current version of AN/NZS 4270 is dated 1995. South Korea -- In October of 1995 the Republic of Korea selected SDTS as their primary spatial data transfer (Kim & Ryu, 1996). They will also use DIGEST-VPF when required for military purposes to match NATO standards. One or more profiles to SDTS may be part of this decision. A Korean Urban Information System initiative has adopted the Topological Vector Profile (TVP) of SDTS as their transfer standard and has contracted with Laser-Scan for the development of translation tools. The Korean Spatial Data Transfer Standard (KSDTS) is based on SDTS-FIPS 173 with proper change to Korean situations, including the Korean character set (KSC 5601). The TM coordinate system was also added to KSDTS Parts 1 and 4. A modified entity list for Korea replaced Part 2. Malaysia and southeast Asia -- A group of southeast Asian nations have invited Phyllis Altheide (technical lead of SDTS Task Force in USGS) to provide SDTS training in late September, 1997. More information for this document should be available after that time. India -- There is some use of SDTS in India, but it is not endorsed at the national level. China -- Richard Hogan of the FGDC Standards Working Group indicates that China has translated SDTS into Chinese. 9. DIGEST and VPF Profiles Including: (1) DIGEST Vector Profile (DVP) to SDTS, for Vector Product Format (VPF) or DIGEST A. (2) Relational Vector Profile (RVP) to SDTS, for Vector Relational Format (VRF) or DIGEST C. (3) possible profiles for other vector and raster varieties of DIGEST. Intended Use -- The proposed DIGEST/VPF profiles to SDTS are designed to allow transfer of digital geospatial data that conforms to both SDTS and DIGEST/VPF. In general, a VPF profile to SDTS will serve as a "bridge" between SDTS and VPF in an effort to harmonize the two standards. This profile activity is a way to clarify and reconcile information in both standards so that they are more similar and have a wider area of overlap. Past and current DIGEST/VPF profiles to SDTS will also be valuable in any future efforts by ISO to harmonize several major geospatial data exchange standards. The Digital Geographic Exchange Standard (DIGEST) (DGIWG, 1994) is the primary spatial data exchange standard for the military communities of many nations, including NATO nations. DIGEST is also now the exchange standard of the civilian transportation community in Canada. The DIGEST standard supports data models for 1. complete topology vector (type 3 topology), 2. planar graph vector (type 2 topology) 3. chain-node vector (type 1 topology) 4. spaghetti vector (type 0 topology) 5. raster (graphic, not image) data 6. matrix (elevation & thematic, not image) data VPF and VRF are the NIMA feature-based, complete topology vector implementations of DIGEST A and DIGEST C (respectively) for direct use as well as data transfer. VPF or VRF is the distribution format for Digital Chart of the World (DCW), Digital Nautical Chart (DNC), and other NIMA products. (1) The DIGEST Vector Profile (DVP) to SDTS was successfully defined and documented in 1992 by IDON under contract to DMA. DIGEST content is specified by the FACC feature catalog. The DVP requires FACC use. Implementation of the DVP has not been a high priority because of limited use of feature-oriented DIGEST A in favor of relational (and conceptually feature- based) DIGEST C. (2) The Relational Vector Profile (RVP) to SDTS was developed in 1996 by SAIC under contract to NIMA. This profile may also be considered a VPF Relational Profile to SDTS and a DIGEST C Profile to SDTS. RVP suggests VPF encapsulation rather than ISO 8211 at the physical implementation level (3) SDTS profiles for other vector and raster varieties of DIGEST have been suggested, but not yet planned or developed. Primary Sponsors, Interested Groups, and Contacts -- (1) DMA (now NIMA) through the IDON Corporation, with input from USGS, was the primary sponsor for the DVP. (2) NIMA, through SAIC, with input from USGS and LaserScan, was the primary sponsor for the RVP. Documents -- (1) The draft DVP document is dated 10-30-92. (2) The draft RVP document is dated 9-30-96. "A Look at Two Geographic Data Exchange Formats: DIGEST and SDTS" by Anthony Sani and Vincent Robinson, 1992, University of Toronto. "Harmonization of SDTS and DIGEST, Final Report" by IDON Corporation (Ottawa, CANADA) for DMA, 11/16/92. MIL-STD-600006 (VPF). DIGEST 2 was expected in late 1996. Future Plans -- The 1996 investigation by SAIC for NIMA indicates that the RVP can be implemented. NIMA, USGS, FGDC, and ANSI are interested in making this connection between SDTS and VPF. This activity can benefit the international effort to harmonize various spatial data exchange standards (DIGEST, SDTS, GDF, S-57, NTF, and others) as they move toward ISO approval. The 1992 DVP document from IDON contained recommendations for the other DIGEST profiles to SDTS including DIGEST Vector Profile Chain-Node DIGEST Vector Profile Spaghetti DIGEST Matrix Profile DIGEST Raster Profile. The DIGEST matrix standard for grid-based elevation and thematic data, and the DIGEST raster standard for scanned map graphics may be examined for possible harmonization with the new SDTS Raster Profile with BIIF Extensions which is the result of a successful effort to reconcile the civilian SDTS raster standard with imagery and raster standards (NITF and BIIF) from the military and intelligence communities. 10. Single ISO Harmonized Standard As noted earlier, use of a profile to SDTS is one method to achieve harmonization with other standards such as BIIF, DIGEST-VPF, CEN GDF, IHO S-57 (formerly DX-90), SAIF, or NTF-BS7567. Moellering and Hogan (1996) provide details on the major national and international spatial data transfer standards. As these and other standards vie for approval at the international level by the International Organization for Standardization (ISO) there may be strong effort to harmonize or reconcile competing spatial data exchange standards into a single standard. The American National Standards Institute (ANSI) National Committee for Information Technology Standards (NCITS, pronounced "insights) technical committee L1 (for GIS) is considering SDTS as an ANSI standard. ANSI NCITS L1 is also the U.S. Technical Advisory Group (TAG) to the ISO Technical Committee on Geographic Information / Geomatics (TC 211). ISO TC 211 will consider international standards for spatial data transfer. Use of SDTS as a national standard in Australia, New Zealand, South Korea, and the US insures that SDTS will receive consideration by TC 211. Because of the configurable nature of SDTS and its many options, and because it has been harmonized with several other standards through documented profiles, it may become an "umbrella" standard under which more specific standards can reside. Note also that ISO-8211 is used as the physical implementation of many of these standards, including SDTS. A single ISO standard should include the best characteristics of the current group of national and international spatial data standards. Version 3 of IHO S-57 now includes "incremental transfers" that allow the exchange of only information that has changed. Multi-scale representation capabilities are now available in CEN GDF. Sophisticated indexing, subtiling, and access capabilities are now used in VPF to support direct exploitation. Support for multiple levels of topology and multiple data models (including raster) within one data transfer is similar to current DIGEST capabilities. These characteristics will be included in the proposed object-based profile to SDTS (see next section), which should be useful as we approach ISO harmonization. Other harmonization efforts are also being investigated. One is between DIGEST and GDF. The hydrographic, bathymetric, and maritime community (IHO, IMO, NIMA, NOAA, Coast Guard, CHS, FGDC Bathymetric Subcommittee) is also interested in a reconciliation of standards for vector nautical charts for Electronic Chart Display & Information Systems (ECDIS), including S-57 (formerly DX-90), DIGEST, and VPF used for DNC. A single, harmonized ISO standard for spatial data exchange and archive, possibly using SDTS as an "umbrella," would be of great value for several reasons. It could remove much of the need for multiple SDTS profiles that are nation specific or that are used to harmonize SDTS with other standards. Use of an object-based approach or profile should also help remove the need for multiple profiles linked to data models and schemas. Data sharing will be easier if the number of profiles is small. 11. Object-Based Profile Intended Use -- An object-based profile to SDTS has been suggested as a way to improve SDTS, and other exchange standards, through the incorporation of object- oriented and feature-based concepts. An object-based profile would provide better support for exchanging and archiving geospatial data that conforms to advanced data models that are feature based, such as the data models of CEN GDF, DIGEST-VPF, NTF, IHO S-57, USGS DLG-F, SmallWorld GIS, Argus, Laser-Scan Gothic, Universal Systems CARIS++, and OGC. A feature-based data model uses a semantic feature level that is distinct from the spatial primitive level. Thus, nonplanar real-world features can be represented even while using a planar graph at the spatial primitive level (Hickman, 1995). According to Arctur (1996) - "Any given line feature such as a road or bridge can consist of one or more edge primitives (unique polyline segments). - "Any given edge primitive can be used in one or more line features or area features." The current SDTS Topological Vector Profile (TVP) can accommodate features and feature-to-feature relationships using composite objects, but some of the feature-based advantages may be lost or de-emphasized. It is possible that the geometric primitives for feature-based data could be raster as well as vector. This profile may also be used to accommodate data that is seamless, is updated incrementally and historically by transactions, has dynamic and self-defining content schema and semantics, is supported in O-O DBMS's or extended- relational DBMS's, has multiple (multi-scale) geometric representations, has immutable ID's for features, and meets FGDC Framework and OpenGIS requirements. Participants in the Open GIS effort have expressed interest in an object-based profile to SDTS. Success of interoperability through OpenGIS may compliment the use of SDTS as a bulk data exchange standard in many circumstances, and may emphasize the use of SDTS as a data archive standard. Primary Sponsors, Interested Groups, and Contacts -- USGS DLG-F developers, FGDC Framework planners, O-O GIS vendors, and several participants in the Open GIS activity are interested in a possible object-based profile to SDTS. Information from David Arctur of Laser-Scan on O-O GIS and object-based suggestions for SDTS is available at http://www.lsl.co.uk/~arctur/ The Open GIS web site is http://www.opengis.org/ See also "Just What is SDTS and What Does it Really Need?" (Arctur & Fegeas, 1997) and "OGIS: Building on SDTS" (Fegeas, 1995). Future Plans -- The USGS-NMD vector program is moving toward a flexible, feature-based data model to support FGDC Framework characteristics. Requirements from this feature-based approach will accelerate the need for an object-based profile to SDTS. A feature-based model is also used by DIGEST-VPF, S-57, and GDF. The need to harmonize with these other standards as part of ISO approval may be related to an object-based profile of SDTS. One of the recommended characteristics of this profile is support for updates by transaction, and Version 3 of IHO S-57 now includes "incremental transfers" that allow the exchange of only information that has changed. The multi-scale representation capability needed in an object-profile is now available in CEN GDF. Sophisticated indexing, subtiling, and access capabilities are suggestions for the object-based profile, and these capabilities are now used in VPF. Support for multiple levels of topology and multiple data models (including raster) within one data transfer is a suggestion for the object-based profile and is similar to current DIGEST capabilities. Support for a content schema that is dynamic and not "hard coded" to a specific product or theme is a characteristic of DLG-F that has been recommended for the object-profile. "When used to its full potential, SDTS will allow an extremely wide range of data models and user-defined geographic data to be encoded and transferred without information loss. Finally, the 'umbrella' and modular manner in which the SDTS is specified, and the methodology of defining profiles of SDTS, affords the means for the evolution of SDTS as requirements and technology change." (Arctur and Fegeas, 1997). More information from Arctur and Fegeas should be available at, and after, the SDTS workshop in September 1997. As stated by Dr. Arctur in "Spatial Data Transfer Standard (SDTS): A GIS Vendor's Perspective" 10/29/96 from http://www.lsl.co.uk/~arctur/ "[Vision for the next profile and content spec: dynamic and self-defining semantics] My impression of current R&D at USGS on DLG-F and a feature-based profile is that these could be pioneering a very smart way to approach the whole thing. They could constitute a framework for decomposing ANY data model's structure & semantics into parameter values that are stored AS DATA in the dataset, in addition to the real-world data itself. With this approach, then a single generic SDTS encoder/decoder should be able to understand ANY data model, and my concerns about reading & writing datasets for use by other GIS vendors goes away." 12. Other Profiles: Graphic, Local Government, Mining, Utility, Hydrographic Vector, ... A number of other SDTS profiles have been suggested over the past few years. Requirements for many of these may be met by the profiles mentioned earlier. The proposed object-based profile should meet most requirements related to these suggested profiles, and help future data sharing by keeping the number of profiles very low. SDTS profiles for graphics (including text and symbols), for mining data, and for utility data have been suggested in the past, but there is little documented information on each of these at this time. A mining profile may have requirements for SDTS 3-D volumetric objects, similar to the CADD profile or a possible geology profile. Requirements for a utility profile may now be met by the CADD profile or the transportation network profile. Some interest was expressed in the early 1990's by the Milwaukee County Automated Mapping and Land Information System (MCAMLIS) organization for a local government profile. Creation of an SDTS profile for local government GIS transactions was also suggested by Moyer and Niemann (1991). Census is investigating use of SDTS for the distribution of governmental units and boundaries data as part of their Framework activities. No specific profile has been mentioned. One GIS vendor is interested in a possible SDTS vector profile that allows topologically structured planar data, topologically structured non-planar (network) data, and non-topological (spaghetti) data all in the same SDTS transfer. This has been called a "mixed vector" profile. The feasibility of such a profile is currently under discussion as part of the object-based profile. A "Hydrographic Vector Profile (HVP) to SDTS" study was conducted by IDON for NOAA in 1994. The resulting HVP was a DX-90 (now S-57 edition 3) profile to SDTS, similar to the DIGEST-A profile to SDTS. The study showed that the format of S-57 is very close to the structure of SDTS; closer than it is to DIGEST or VPF. The Corps of Engineers also had some interest in HVP as a way to help reconcile nautical chart formats between VPF/DNC and S-57. Although there are no plans to implement the HVP, the results may be useful in future ISO efforts to harmonize a number of similar standards including S-57, DIGEST, GDF, and SDTS. An SDTS profile for ArcView SHAPE files was suggested but quickly discouraged, because the proliferation of SDTS profiles (especially if based on each vendor and product format) would not do much to improve data sharing and exchange. REFERENCES Arctur, D., and R. Fegeas, 1997, "Just What Is SDTS and What Does It Really Need," URISA '97 (Toronto) Proceedings, Chicago: Urban and Regional Information Systems Association. Comite Europeen de Normalisation (CEN) (European Committee for Standardisation), 1995, "Geographic Data Files" (GDF), European Standard, First Draft, Version 3.0, October 12, 1995, CEN Technical Committee 278 Road Transport and Traffic Telematics, Working Group 7.2. Digital Geographic Information Working Group (DGIWG), 1994, "The Digital Geographic Information Exchange Standard (DIGEST)," Ottawa: National Defence Headquarters. Dueker, K.J., and J.A. Butler, 1997, "GIS-T Enterprise Data Model with Suggested Implementation Choices," Center for Urban Studies, Research Project Report 101, June 11, 1997, Portland: Portland State University, 41 pp. Available at http://www.upa.pdx.edu/CUS/ ESRI, 1995, "SDTS-Supporting the Spatial Data Transfer Standard in ARC/INFO," Environmental Systems Research Institute, White Paper. Available at http://www.esri.com/resources/papers/papers.html Fegeas, Robin, 1995, "OGIS: Building on SDTS," Geo-Info Systems, January 1995, p. 59. FGDC, 1996, "FGDC Standards Reference Model," Federal Geographic Data Committee, Standards Working Group, http://www.fgdc.gov/SWG/swg.html Greenlee, David D., 1992, "Developing a Raster Profile for the Spatial Data Transfer Standard" Cartography and Geographic Information Systems, Vol. 19, No. 5, December 1992, Special Issue: Implementing the Spatial Data Transfer Standard, J. Morrison and K. Wortman, eds., pp. 300-302. Hanson, J.B., 1995, "Geographic Data Sharing Using the Spatial Data Transfer Standard," ACSM/ASPRS Technical Papers, Vol. 1, Bethesda, Maryland: ACSM, pp. 298-306. Hickman, C.E., 1995, "Feature Based Data Models and Linear Referencing Systems," Proceedings of the Geographic Information Systems for Transportation Symposium (GIS-T 95, Sparks, Nevada), D. Moyer & T. Ries, eds., Washington: AASHTO, HEEP, URISA, TRB, US DOT, NARC, pp. 89-113. IDON, 1992, "Harmonization of SDTS and DIGEST, Final Report" 11/16/92, Ottawa: IDON Corp. for HQ DMA Kim, S.R., and J.H. Ryu, 1996, "SDTS Based Korea GIS Transfer Standard," Proc. 1996 ESRI Conference, Redlands: Environmental Systems Research Institute, 12 pp. Available at http://www.esri.com/base/common/userconf/proc96/TO350/PAP315/P315.HTM Lazar, Bob, 1996, "Understanding SDTS Topological Vector Profile Implementation," Geo Info Systems, Vol. 6, No. 6, June 1996, pp. 42-45. Miller, D., and R. Hume, 1994, "Internationalizing SDTS: An Australasian Experience," Cartography and Geographic Information Systems, Vol. 21, No. 3, July 1994, Special Issue: Current Developments and Use of the Spatial Data Transfer Standard, K. Wortman and B. Buttenfield, eds., pp. 176-179. Moellering, H. (ed.), and R. Hogan (assoc.ed.), 1996, Spatial Database Transfer Standards 2: Characteristics for Assessing Standards and Full Descriptions of the National and International Standards in the World, Oxford: Elsevier (on behalf of the International Cartographic Association, ICA Commision on Standards for the Transfer of Spatial Data). Moyer, D.D., and B.J. Niemann, Jr., 1991, "The Why, What, and How of GIS Standards: Issues for Discussion," for the 10/30/91 URISA sponsored session on GIS standards in Atlanta. National Institute of Standards and Technology (NIST), 1992, Spatial Data Transfer Standard, Federal Information Processing Standard 173, Washington, DC: U.S. Department of Commerce. SDTS Parts 1 through 4 available at SDTS web site http://mcmcweb.er.usgs.gov/sdts Ritter, N., 1996, "Re: Relationship between GeoTIFF and SDTS," on-line response to J. Binder Maitra at http://www.pci.on.ca/~warmerda/geotiff/msg00277.html Ritter, N., and M. Ruth, 1997, "The GeoTIFF Data Interchange Standard for Raster Geographic Images," Int. J. Remote Sensing, v18, #7, pp. 1637-1647. Plus GeoTIFF page at http://home.earthlink.net/~ritter/geotiff/geotiff.html Sani, A., and V. Robinson, 1992, "A Look at Two Geographic Data Exchange Formats: DIGEST and SDTS", Toronto: University of Toronto. Schmidt, D.L., 1997, "An Exploration in the Exchange of Transportation Networks Between Two GIS's Via the Spatial Data Transfer Standard (SDTS)," Thesis, Knoxville: University of Tennessee. Available at http://funnelweb.utcc.utk.edu/~dschmidt/ Szemraj, J.A., 1994, "Raster Profile Development for the Spatial Data Transfer Standard," Proc. PECORA 12 Symposium, Bethesda: ASPRS, pp. 267-272. Szemraj, J.A., R.G. Fegeas, B.R. Tolar, 1994, "Profile Development for the Spatial Data Transfer Standard," Cartography and Geographic Information Systems, Vol. 21, No. 3, July 1994, Special Issue: Current Developments and Use of the Spatial Data Transfer Standard, K. Wortman & B. Buttenfield, eds., pp. 150-154. Szemraj, J.A., and B.R. Tolar, 1993, "Profile Development for the Spatial Data Transfer Standard," GIS/LIS '93 Proceedings, Vol. 2, Bethesda, Maryland: ASPRS, ACSM, AAG, URISA, AM/FM, pp. 663-670. Available at SDTS web site http://mcmcweb.er.usgs.gov/sdts Watje, J.M., and P. Okunieff, 1995, "APTS Map Database User Requirements Adapted to the Spatial Data Transfer Standard (SDTS)," Proceedings of the Geographic Information Systems for Transportation Symposium (GIS-T 95, Sparks, Nevada), D. Moyer & T. Ries, eds., Washington: AASHTO, HEEP, URISA, TRB, US DOT, NARC, pp. 195-204.