# Presentation: 423822

## Using the Spatial Data Transfer Standard

**An Implementation Plan for Encoding**

## SDTS Implementation Strategy for ENCODING

**A general plan for an ENCODING implementation of the Spatial Data Transfer Standard**
**Use as a guide in formulating specific project plans for your organization**

**Notes:**
Once an organization decides to use SDTS as a means to distribute and/or receive spatial data, a plan is needed to achieve an implementation of the SDTS.  This presentation describes a general implementation plan for an SDTS Encoding activity.

This plan describes the minimum set of tasks that are needed, and should be used only as a guide in formulating specific project plans for your organization.

## Terminology

**Terminology**

**SDTS Conceptual**

**SDTS Specifications**

**ISO 8211 Encoding**

**ISO 8211**

**Media-Dependent Standards**

**CONCEPTUAL LEVEL**
**SDTS Part 1, Section 1,2,3,4.1**
**SDTS Part 2**

**LOGICAL LEVEL**
**SDTS Part 1, Section 4.2, 5**

**IMPLEMENTATION LEVEL**
**SDTS Part 3**

**“****Specification for a Data Descriptive File for Information Interchange”**

**MEDIA (Physical) LEVEL**
**Tape, Disk, CD ROM, Cartridge, etc.**

**Notes:**
User Data Model (UDM) == Conceptual and Format
Source Data Model (SDM) == UDM to be Encoded
Target Data Model (TDM) == UDM to Decode to

The above terminology is often used when discussing implementation issues.

The SDTS document contains information on three levels - conceptual (definitions of spatial objects, data quality characteristics, etc.), logical (modules, fields, inclusion rules, etc.), and implementation (i.e. format, records, files, etc.)

Note:  These same three levels also appear in profile documents, as restrictions and requirements can address any of these levels.

## Encoding in SDTS: Where do I start?

**“****Now that we have decided to use SDTS to encode our data, we are ready to start software development, right?”**
**Encoding is NOT just a software development task.**

**Notes:**
Embarking on a project to create a system to produce SDTS- compliant transfers, does not begin at the software development stage. There are many tasks that must be performed in preparation for the software development activity. Conceptual mappings from the source data model to the SDTS data model, and vice-versa, must be specified. Decisions concerning the logical (i.e., module level) and physical (i.e., file level) issues need to be addressed. Effort should be made to verify the completeness and accuracy of the mappings and decisions. Only after these tasks are done should work begin on developing a system to produce SDTS/Profile-compliant datasets.

## Encoding Implementation Plan

**Any plan should include the following set of tasks:**
**conceptual-level mapping,**
**logical-level mapping,**
**format-level mappings,**
**verification of the mappings, and**
**systems development.**

**Notes:**
There is a minimum set of tasks that must be performed to achieve an SDTS implementation. This presentation describes this set of tasks that are common to all implementations. There may be other necessary tasks that are dependent on a particular situation, and no conflicts between the unique tasks and the minimum set are expected. This minimum set of tasks should be used as a guide in formulating your organizations' specific project plans.

## Implementation Plan:  Task Overview

**Task A:  Learning**
**Learn about the SDTS, Profiles, and ISO 8211**
**Task B:  Conceptual Mapping**
**Map the source data model (SDM) constructs onto the SDTS conceptual model constructs**
**Task C:  Module-level and Data-element mapping**
**Account for all data required by SDTS content rules**
**Task D:  Build Sample Modules**
**Verify the conceptual and module-level mapping**

**Notes:**
More specifically there are 7 (3 on the next overhead) tasks that have been identified that are common to all encoding implementations.

Tasks B and C deal with making decisions, and Task D verifies the completeness and accuracy of these decisions.

Note: Each of these tasks is at a high level. Depending on the particular situation, any of these tasks could be a project in itself.  

## Implementation Plan:  Task Overview (continued)

**Task E:  Format-level Mapping**
**Specify how the modules will be encoded in ISO 8211**
**Task F:  Encode Sample Dataset**
**Create ISO 8211 files**
**Task G:  Systems Development**
**Develop a production-mode capability system**

**Notes:**
More specifically there are 7 (4 on the previous overhead) tasks that have been identified that are common to all encoding implementations.

Tasks E deals with making decisions, and Task F verifies the completeness and accuracy of these decisions. And, then Task G deals with systems development work.

Consider this set of 7 tasks as the minimum activities that must take place to achieve an encoding implementation of the SDTS.  

Note: Each of these tasks is at a high level. Depending on the particular situation, any of these tasks could be a project in itself.  

## Task Dependencies

**Task Dependencies**

**Sequential relationship between tasks**

**Possible concurrence**

**D**

**E**

**F**

**G**

**A**

**B**

**C**

**Learn**

**Conceptual Mapping**

**Data-element Mapping**

**Build Sample Modules**

**Format Mapping**

**Encode Dataset**

**Systems Development**

**Notes:**
Although the tasks are listed sequentially, certain tasks can be performed concurrently. The dependencies between the tasks are illustrated in the bar chart above. The solid lines illustrate the most  sequential relationship between tasks, and the dashed lines show possible concurrence. The relative lengths of the bars is not intended to imply task duration. The shorter bars are used for verification tasks. Actual task duration will vary widely depending on resources used on the project. 

## Implementation Plan:  The Team

**SDTS requires a wide range of knowledge and abilities**
**The team needs members to fill the roles of:**
**1.  Source Data Model Expert - Conceptual Level**
**2.  Source Data Model Expert - Format Level**
**3.  Software Developers (Analyst, Designer, Programmer)**
**4.  Policy Authority**

**Notes:**
Before we get into more detail on the tasks themselves, let's take a closer look at the human resources needed on this type of project.

The project is best handled through a team approach because of the wide range of knowledge and abilities that is needed. At a minimum the team needs members to fill the roles listed above. (Note: This is just the roles/knowledge needed of the team as a whole. The actual number of team members will be as many people as necessary.)

The requirement for the first three roles is self-explanatory, but the fourth requires some explanation. Why is a Policy Authority needed?   There is no single unique solution for mapping each source data model construct into the SDTS constructs. The SDTS standard is so flexible that there are multiple legal ways to make the mapping. The choices made reflect policy. The policy can be explicit, in formal policy statements, or implicit in the data produced. But either way, the policy is there. By having a Policy Authority as a part of the team, the necessary decisions will be made in a more timely(?) fashion and not hamper the progress of the project.

## Task A:  Learning

**Role****	****Area to learn****	****	****References**
**1****	****SDTS Conceptual Model****	****SDTS Document, Part 1, Section 1-4.1, Part2 **
**2****	****SDTS (Logical) Format****	****SDTS Document, Part 1, Section 4.2-5**
**1,2,3****	****SDTS Profiles****	****	****Topologic Vector Profile, Raster Profile**
**3****	****SDTS/ISO 8211****	****	****SDTS Document, Part 3**
**3****	****ISO 8211 Standard****	****	****ANSI/ISO 8211, or FIPS PUB 123**

**Role 1 - Source Data Model Expert (Conceptual Level)**
**Role 2 - Source Data Model Expert (Format Level)**
**Role 3 - Software Developers (Analyst, Designer, Programmer)**

**Notes:**
The next series of overheads will be exploring each of the seven tasks in greater detail - to give you a better idea of the type of work that is involved in each of them.

Task A: Learning

As is common when embarking on any new subject, time needs to  be set aside to study it, before trying to apply it. It should be no surprise that there is a learning curve associated with the SDTS. The team members should spend time studying the SDTS literature, examining case studies, attending workshops, etc. 

There are many areas to concentrate on learning. It is not necessary for all team members to be proficient in every area. The table above contains the areas to learn, references available, and the role number of the recommended proficient team member.

## Task B:  Conceptual Mapping

**Specify each native data model construct using SDTS constructs**
**Preserve the information in the native data model**
**Consider**
**Spatial Object Mapping**
**Entities and Attributes**
**Data Quality**
**Geocoding**
**Extent of a Transfer**
**... and others**

## Task C:  Data Element Mapping

**To account for everything required by the SDTS (and possibly an profile)**
**Consider:**
**Spatial Object Modules**
**Attributes and Data Dictionary**
**Data Quality Requirements**
**... and other module requirements**

**Notes:**
Task C: Data Element Mapping

This task requires not only a change in perspective from task B, but also a change from the conceptual level to a logical level. Now take the SDTS perspective and analyze the source data model. The task objective is to account for everything required by the SDTS (and possibly a profile). Often the source data model does not contain all the information needed for a content-complete transfer.  

After determining the module types needed, there are a number of decisions to make about modules in general. How many of each type of module is needed in a transfer? Is the amount fixed or does it vary depending on the specific transfer? How should modules be named? Are there any module to module relationships needed? All of these questions and others need to be answered considering the SDTS, a profile, and the SDM.

Many of the issues that were discussed under task B at the conceptual level, can now be revisited at the module-level. Some of the topics that are common to many implementations are discussed in the below.

Spatial Object Modules - For each desired module type, inspect the fields, subfields, and inclusion/exclusion rules and see what is required or optional. If topology is involved, then the decision of how much to encode must be made as SDTS has provisions for redundant topology. If aggregates are desired then consider how composites will be used, forward and backward pointers. If raster is used, then what metadata to supply, and what encoding technique is to be used.

Attributes and Data Dictionary - Any user-defined entity must have an authority, a definition, and a set of attributes. All attributes must have authorities, definitions, and domains. This type of information is usually not a part of the SDM and must be gathered from other sources. The number of, composition of, and structuring of the attribute modules needs to be decided. The SDTS also permits a separate Data Dictionary transfer that can apply to an entire series of transfers. If this route is chosen then version management and change control procedures need to be instituted.

Data Quality Requirements - The SDTS requires a statement of quality in each of five categories. (This is where the team member with the policy authority will have the most headaches.) Usually the SDM does not contain enough quality information to meet the requirements (although 'don't know' is an acceptable statement).

Other module requirements - The transfer must be identified, the projection that relates the coordinates to ground should be specified, etc. The SDTS provides a place to put every type of metadata. Some of it is required, but much is optional.

## Task D:  Build Sample Modules

**To verify the conceptual mapping (Task B) and the module-level mapping (Task C)**
**Not a check of format understanding, but of content (do not use ISO 8211)**

- 10/01/93

**Notes:**
Task D: Build Sample Modules

The task objective is to verify the conceptual mapping (task b) and the module-level mapping (task c). The team should do a "paper exercise" where an SDTS content-level transfer is built "by-hand" from a portion of a SDM dataset. This is not a check of format understanding, but of content. Therefore, do not use ISO 8211 at this point - use a format that is human readable and verifiable. This task is invaluable as it increases the teams' knowledge and experience through application of decisions made in previous tasks.

## Task E:  Format-level Mapping

**Specify how the modules will be encoded in ISO 8211**
**Field-level issues:  data type, structure, format, ...**
**File-level issues:  which modules, fixed or varying, ...**
**Record-level issues:  field order, content, ...**
**Media-level issues:  type, naming, ...**

- 10/01/93

**Notes:**
Task E: Implementation-level Mapping

The task objective is to specify how the modules will be encoded in ISO 8211. The SDTS modules are mapped into ISO 8211 constructs, under the restrictions of Part 3 of the SDTS and a profile (if any).  However, the SDTS makes very few restrictions about the relationships between modules, files, and media (Table 3.1b in the SDTS). This leaves many decisions to make at all levels - field, record, file, and media. Additionally, the decisions can apply to a series of transfers or be transfer-specific (made at the time of the transfer).

## Task F:  Encode Sample Dataset

**To verify the accuracy and completeness of the implementation mapping (Task E)**
**Create ISO 8211 files**

**Notes:**
Task F: Encode Sample Dataset

The objective of this task is to verify the accuracy and completeness of the implementation mapping of Task E. This task provides knowledge and experience with ISO 8211 and software, and media-level utilities.  All that is necessary is that a minimum set of indicative modules be encoded, testing out the major decisions from Task E.

## Task G:  Systems Development

**Previous tasks can collectively be considered part of the “analysis” phase of a systems development cycle**
**With the conceptual-, logical-, and format-level mappings specified and tested, work can begin on developing a system to produce transfers**
**Design of a Spatial Data Transfer Processor**

**Notes:**
Task G: Systems Development

With the conceptual-, logical-, and format-level mappings specified and tested, work can begin on developing a system to produce SDTS/Profile-compliant datasets.  The tasks A through F can collectively be considered part of the 'analysis' phase of a systems development cycle, where requirements are stated. Any discussion of systems development methodologies is beyond the scope of this presentation.