WPC 2BJ Courier#|sRomanTimes Roman BoldkCXPHelveticaHelveticaTimes RomanTimes Roman BoldTimes Roman ItalicCourierhhh[X@2 ,. Z>,x#|~ NEC Silentwriter LC-890NESILC89.PRSXl2PQhhhh[XPHelveticaTimes RomanTimes (Scalable)CG Times Bold (Scalable)CG Times Italic (Scalable)Courier 10cpi23cT c4"m^88Goo,CCNu8C88oooooooooo88uuuo˅z8dozz888^o,oodoo8oo,,d,ooooCd8oddddC4CuC8CC!CCCCCCCCCCz8oooooȲdoooo88888888ooooooooodoozodoooooddddooooooooooooo88888,88ddo,o,o,o,o,ooooooȽCCCddddz8z8z8oooooodzdzdzdoo,oCdz8ddoooNF8koCzoooooJIoCoC&CCoCCoodd,CCLt1sC8/:s2PkCXP7oC2 bo\  PCXP7tC2vt4  p(ACX<5nC2'n*f9 xCXXT?xxx:x6X@KX@~1sC8B':s2x(CXX/xC8T :x2p}wCXHelveticaTimes RomanTimes Roman BoldTimes Roman ItalicCourierHelvetica ObliqueHelvetica BoldwwwwwwwwwwCzs8dYCx"m^2CRddCCCdq2C28dddddddddd88qqqYzoCNzoozzC8C^dCYdYdYCdd88d8ddddCN8ddddY`(`lC2CC!CCCCCCCCCCd8YYYYYYzYzYzYzYC8C8C8C8ddddddddddYdddddodYYYYYYYdzYzYzYzYddddddddC8C8C8C8Ndz8z8z8z8z8ddddddCCCoNoNoNoNz8z8z8dddddddzYzYzYdz8dCoNz8dddddNF2[dCYddddd7>d<d<$YYdCCddooCYN6uC;,@/3Xu&_ x$&7XX?xxx,[gx6X@87X@2ccJZ"m^2CTddCCCd2C28ddddddddddCCdzzzzCYozzdozzooN8NTdCddYdY8dd88Y8ddddNN8dYYYNP7PlC2CC!CCCCCCCCCCd8zdzdzdzdzdYzYzYzYzYC8C8C8C8dddddddddoYzddddoYdzdzdzdzdYYYYdzYzYzYzYddddddddC8C8C8C8YYo8o8o8o8o8ddddddzNzNzNdNdNdNdNo8o8o8ddddddoYoNoNoNdo8dzNdNo8oYoYdddNF2idNdddddd7>d<d<+oodCCddddCo<чnn8!BBnnnyyP7c1RyyXyycnnnѐ~nyRzczXzcyhCBnndhcnnonvyXzXshn~XyBBnss~|y~~~~~~~~~~~~~~~~~~~XXXXXXXyyyyyyyyyyyyyyyyyyyyBBBBBBBBBBBBnnnnnnnsssssssssssszCCn221"m^88Goo,CCNu8C88oooooooooo88uuuo˅z8dozz888^o,oodoo8oo,,d,ooooCd8oddddC4CuC8CC!CCCCCCCCCCz8oooooȲdoooo88888888ooooooooodoozodoooooddddooooooooooooo88888,88ddo,o,o,o,o,ooooooȽCCCddddz8z8z8oooooodzdzdzdoo,oCdz8ddoooNF8koCzoooooJIoCoC&CCoCCoodd,CC"m^8C_oo8CCNu8C88ooooooooooCCuuuzÐz8ozzzC8Cuo8ozozoCzz88o8zzzzNoCzooodN8NuC8CC!CCCCCCCCCCz8oooooȲooooo88888888zzzzzzzzzoozzzozzooooooozoooozzzzzzzz88888888ooz8z8z8z8z8zzzzzzȽNNNoooozCzCzCzzzzzzozdzdzdzz8zNozCoozzzNF8ooCzoooooJIoCoC0ddoCCoozz8dC V #Xt\  PZQbXP#Paper to be presented at GIS/LIS,  V November 24, 1993, Minneapolis, Minnesota  Xv '8  A SPATIAL FEATURES REGISTER: TOWARD STANDARDIZATION OF $SPATIAL FEATURES , '%xJanette Cascio ! U.S. Geological Survey #~526 National Center $Reston, VA 22092 '8  (ABSTRACT  As the need to share spatial data increases, more than agreement on a common format is needed to ensure that the data is meaningful to both the importer and the exporter. Effective data transfer also requires common definitions of spatial features. To achieve this, part 2 of the Spatial Data Transfer Standard (SDTS) provides a model for a spatial features data content specification and a glossary of features and attributes that fit this model. The model provides a foundation for standardizing spatial features. The glossary now contains only a limited subset of hydrographic and topographic features. For it to be useful, terms and definitions must be included for other categories, such as transportation, bathymetric, cultural, demographic, boundary, soil, wetland, vegetation, cadastral, geodetic, and geologic data, and the set of hydrographic and topographic features must be expanded. The National Institute of Standards and Technology has authorized the U.S. Geological Survey (USGS) to expand the present glossary into a Federal Information Processing Standard (FIPS) Spatial Features Register. The SDTS Task Force at the USGS is establishing procedures for developing and maintaining this register, which will serve as the next update for part 2 of the SDTS.  X  & INTRODUCTION '8  The Spatial Data Transfer Standard (SDTS), also known as Federal Information Processing Standard (FIPS) 173, provides a mechanism for transferring the full range of spatial (geographic and cartographic) data. The SDTS consists of three related but relatively independent parts, each of which solves some aspect of the spatial data transfer problem. Part 1 addresses the logical specifications required for spatial data transfer, part 2 addresses data content by providing a model for the definition of entities, attributes, and included terms, and part 3 specifies the implementation of the logical specifications by using a general data exchange standard. Agreement on a common format is not sufficient to ensure that the information transferred is meaningful to both the importer and the exporter. Part 2 is a formal attempt to develop a standardized list of entities and attributes. This paper will briefly explain part 2 and the standardization of thematic data content specifications, but the major focus is on the development of a spatial features register. (0*0*0*Ԍ  X ) PART 2 ă To understand how part 2 fits into SDTS, one must first understand the conceptual model, which consists of three parts: spatial phenomena, spatial objects, and spatial features. Respectively, these parts describe (1) the real world through entities, attributes, and attribute values, (2) a set of spatial objects (points, lines, polygons, etc.), and (3) the relationship between the two (spatial objects are used to digitally represent realworld entities). A complete explanation of the conceptual model can be found in part 1 of FIPS 173 (NIST 1992). Data Model Part 2 was developed by using an entityattributeattribute value model that is common to many feature schemas (Hogan 1993). The SDTS defines the following terms: "` ` Entity type a set into which similar entity instances are classified (example bridge)(#` "` ` Entity instance a spatial phenomenon of a defined type that is embedded in one or more phenomena of a different type, or that has at least one key attribute value different from the corresponding attribute values of the surrounding phenomena (example the 10th Street Bridge)(#` "` ` Attribute a defined characteristic of an entity type (example composition)(#` "` ` Attribute value a specific quality or quantity assigned to an attribute (example steel) for a specific entity instance(#` "` ` Standard term primary label of an entity type or attribute (example bridge)(#` "` ` Included term a synonym or specialization that is crossreferenced to an SDTSdefined entity type or attribute (example overpass)(#` Although data content transferred in the SDTS must comply with this model, there are different levels of conformance to part 2, taking into consideration the variety of features and definitions that exist. Level 1 indicates that the transfer consists only of standard entity and attribute terms listed and defined in part 2. Level 2 indicates use of standard entity and attribute terms and other userdefined terms which can be found in the list of included terms and are then converted to standard terms. Like level 2, level 3 indicates use of a mixture of standard and userdefined terms, but nonSDTS terms may overlap with standard and(or) included terms. Level 4 indicates that all terms are userdefined. Data Dictionary Modules To comply with the SDTS format for transferring data content, the data dictionary modules are used. A module is a logical collection of records. The data dictionary modules specify information unique to individual entity and attribute terms and attribute modules. The data dictionary consists of three module types Data Dictionary/ Definition, Data Dictionary/Domain, and Data Dictionary/Schema. These modules combined describe the(0*0*0* meaning and structure of entity and attribute data. Specifically, the Data Dictionary/Definition module defines entities and attributes and cites the authority for these definitions. If entity and attribute terms from part 2 are used as in conformance levels 13, this module is not necessary. The Data Dictionary/Domain module defines domain values associated with each attribute. The Data Dictionary/Schema module describes attribute modules and provides the linkage between entities and attributes (Fegeas 1992).  X_   THEMATIC DATA CONTENT SPECIFICATIONS ă As mentioned earlier, it is important that the information in a data transfer be meaningful to both the importer and the exporter. Creating thematic data content specifications helps achieve this because it standardizes terms that are important to a group using data for a particular theme. Currently, the Federal Geographic Data Committee (FGDC) identifies 12 themes base cartographic, cadastral, cultural and demographic, geodetic, geologic, ground transportation, international boundaries, soils, vegetation, water, and wetlands. The SDTS Task Force has been working with the FGDC to help the data category subcommittees establish specifications for these themes. The SDTS Task Force will identify other sponsoring groups for themes not supported by the FGDC. Although the model in part 2 is nonhierarchical, most classification schemes that result from this effort will be hierarchical. These hierarchies must be collapsable to the part 2 model. Some of the subcommittees, such as that for base cartographic data, have spent years developing a data content specification. Other subcommittees have lists of entities and attributes in rough form and simply need guidance in adapting these lists to the model. The Cadastral Subcommittee, chaired by the Bureau of Land Management (BLM), has developed a draft standard "to provide a framework for transferring current and past federal rights, interests, and restrictions and the spatial extent of those rights, interests, and restrictions among automated systems". (FGDC Cadastral Subcommittee 1993). This draft includes goals, objectives, and timelines for developing their data content specification, as well as a full explanation of cadastral entities and attributes and the relationships between them. The SDTS Task Force, with the assistance of the Cadastral Subcommittee, will finalize the relationship of the cadastral draft to fit the SDTS part 2 data model. The developers of SDTS part 2 used the following procedures to take that first step toward standardization of terms within the larger spatial data community (Rugg 1993): "` ` Identify candidate entity terms(#` "` ` Assemble definitions from various sources(#` "` ` Find common criteria embedded in each definition(#` "` ` Identify related terms defined by similar criteria(#` "` ` Check for overlap with existing standard terms and (or) definitions (Rugg 1987)(#` (0*0*0*Ԍ"` ` Select, modify, or improvise a standard definition(#` "` ` Record term, definition, source of definition, and alternate definitions(#` "` ` Prepare list of included terms and their definitions(#` "` ` Identify attributes needed to distinguish included entity types(#` "` ` Prepare list of associated attributes and their definitions(#` "` ` Check for overlap with existing standard attribute terms and (or) definitions(#` "` ` Revise standard entity type list with standard definition and associated alternate definitions, included terms, included term definitions, and attributes(#` "` ` Revise standard attribute list with standard definition and associated alternate definitions, included terms, included term definitions, and entity types(#` The developers of part 2 also debated the issues of scale and symbology independence, the use of an entityattributeattribute value model, and the absence of hierarchy (Rugg 1987).  X   SPATIAL FEATURES REGISTER ă Definition The Spatial Features Register is, in part, an online data base consisting of separate thematic data content specifications for each data category subcommittee of the FGDC or other sponsoring group identified by the SDTS Task Force. The content specifications must define entities and attributes within each theme. However, the organization of the content specifications is left to the discretion of each sponsoring group. The register also contains the mapping of entities and attributes submitted by the groups to the data model defined in part 2 of the SDTS. This mapping will be provided by the SDTS Task Force with the approval of the appropriate sponsoring group. The current version of part 2 of the SDTS will also be included as the initial set of feature and attribute terms and definitions in the register.  Relationship to SDTS Part 2 The register and SDTS part 2 are the same as far as content. The difference is that the register is online and may be updated at any time while part 2 is part of the SDTS and must adhere to the FIPS 5year review cycle process. At the time of the FIPS 5year review, the contents of the register will become the update to part 2. Updates are outlined in the next section. Procedures The SDTS Task Force has identified the FGDC data category subcommittees as initial(0*0*0* sponsoring groups for the register. These and other sponsoring groups act as agents for the maintenance authority in expanding part 2. The SDTS Maintenance Board, a board to advise the task force and oversee future changes to FIPS 173, will provide a representative in charge of part 2 to establish and coordinate ad hoc technical review boards (TRB) for modifying the register. The sponsoring groups will provide membership to the TRB when required to do so. Membership on the TRB is not exclusive to the Federal sector. Anyone may serve on the boards as approved by the SDTS Maintenance Board. Anyone may make a recommendation to any thematic data content specification. Proposals must be submitted in writing to the SDTS Task Force; proposals will then be forwarded to the SDTS Maintenance Board. The board has 3 months to accept or deny the proposal and must submit this decision in writing to the SDTS Task Force. The SDTS Task Force is the maintenance authority for the Spatial Features Register and will maintain and manage the register, making sure recommendations are in accordance with part 2 guidelines, but will not make decisions regarding specific content. Changes to the register will become the next update to part 2 of the SDTS. Interim updates to the register will be performed on a quarterly basis if needed. Interim updates will receive version numbers based on the FIPS 5year cycle. For example, the first register will be version 0.0 and the next version 0.1. After the FIPS 5year review the next version will be 1.0, then 1.1, 1.2, etc. Due to crosslingual complexities (Mark 1993), the international community will need to reference separate specifications or registers. For example, Australia, which has adopted SDTS as their national spatial data transfer standard, has begun development of thematic data content specifications to meet their data content requirements (Hume, Miller 1993). The country code must be specified in the Data Dictionary modules. The Entity Authority and Attribute Authority subfields shall contain "SDTS" followed by the threecharacter ISO 3166 country code. The Spatial Features Register will be accessible via the Internet. A data base will be developed using ORACLE software, which will be transparent to the browser. A user guide is being developed and will be published in 1994. Hardcopies of the register will be available upon request with change pages being issued quarterly. There will be a "cost recovery" charge for hardcopies. Responsibilities With regard to the initial establishment of thematic data content specifications and subsequent modifications to the register, the responsibilities of the SDTS Task Force are to: I(#(#N "` ` receive specifications from sponsoring groups(#` "` ` provide mapping of lists to the part 2 model(#` "` ` receive proposals for modifications from all parties(#` "` ` record and then forward proposals to the TRB(#` "` ` inform sponsoring groups of ruling options(#` "` ` inform sponsoring groups of deadlines for providing rulings(#` "` ` inform party making proposal of decision(#` (0*0*0*Ԍ"` ` make appropriate changes to register(#` "` ` provide copies of the register upon request(#` With regard to initial establishment of thematic data content specifications, the responsibilities of the sponsoring groups are to: "` ` develop entity and attribute lists for the SDTS Task Force for inclusion in the register(#` "` ` provide assistance if needed in the mapping of lists to part 2 model(#` With regard to proposals for additions, deletions, and modifications to the register, the responsibilities of the SDTS Maintenance Board are to: "` ` evaluate proposals forwarded by the SDTS Task Force(#` X"X` ` organize ad hoc TRBs for proposal evaluations(#` "` ` ensure that each proposal is accepted, accepted with modifications, or rejected. Criteria for rejection of a proposal may include:(#` ` ` 1. incomplete or incomprehensible definition(# ` ` 2. incorrect application(# ` ` 3. existence of identical term in register(# ` ` 4. nonapplicable to theme(# ` ` 5. inadequate justification for inclusion in register(# The following information must be provided in writing for all proposals to the Register: 1.` ` Date of proposal(#` 2.` ` Name/Organization(#` 3.` ` Address(#` 4.` ` Telephone number 5.` ` Theme 6.` ` Description of proposal (see below) 7.` ` Justification for inclusion 8.` ` Additional comments There currently is not a form or template for proposal descriptions. The upcoming user guide will explain this procedure. Preliminary thinking is that proposal descriptions must correspond to the Data Dictionary/Definition module explained on page 89 of FIPS 173. The following four subfields must be included: "Entity or Attribute," "Entity/Attribute Label," "Source," and "Definition." Conformance As mentioned earlier, the register will contain both the thematic data content specifications submitted by the FGDC subcommittees and other sponsoring groups as well as the conversions to the SDTS entity/attribute lists. Conformance levels explained previously apply(0*0*0* only to the SDTS conversion, not to the original content specifications.  X G' CONCLUSION ă The procedures outlined in this paper are a first step toward developing a Spatial Features Register. Understanding how and why the register will work depends upon the need to understand classification schemes and their standardization. The goal of part 2 of the SDTS is a single list containing standard entity and attribute terms and definitions for spatial data without specifying theme. This is clearly an optimistic goal considering the time and effort needed to standardize within thematic confinements coupled with the lack of a widely accepted general theory of classification. This development and education process is a longterm effort that can only come to fruition with the help of the spatial data community.  X N' REFERENCES ă Federal Geographic Data Committee Cadastral Subcommittee 1993. Draft Report: Cadastral Data Exchange Standards. Fegeas, R. G., Cascio, J.L. and Lazar, R.A. 1992. "An Overview of FIPS 173, the Spatial  X4 Data Transfer Standard." Cartography and Geographic Information Systems, Special Issue: Implementing the Spatial Data Transfer Standard, vol. 19, no.5. Hogan, R. 1993. "Developing a Spatial Feature Register", Urban and Regional Information Systems Association Conference, Proceedings. Hume, R.G. and Miller, D.R. 1993. "Guidelines for Creating a Spatial Feature Data Dictionary Suitable for the Spatial Data Transfer Standard", Technical Report No. 3. Mark, D. 1993. "Toward a Theoretical Framework for Geographic Entity Types", Conference of Spatial Information Systems, Proceedings.  X" National Institute of Standards and Technology, 1992. Federal Information Processing  X  Standard Publication 173 (Spatial Data Transfer Standard), U.S. Department of Commerce. Rugg, R. 1987. "Feature Definition: Methodology Used by Working Group III of the National Committee for Digital Cartographic Data Standards", U.S. Geological Survey. Rugg, R. 1993. "Feature Definitions for Planners", Fifth International Conference on Geographic Information Systems. #x6X@8;X@#