WPC 2 BU Z-0pt (TA)#|d2cpi (M)Helv 14pt Bold (AD)Helv 12pt Bold (AD)Prestige Elite 12cpi (M)^,,4Xp,44P,4,TXXXXXXXXXX,,Hddp|PHx|00dL|\\XX|h\Xd4T4XP,T\P\T0T\$(T(\\\\8D4\P|LPPXPLHP LaserJet Series II (Additional)HLSEIIAD.PRSd6X@C,t0u'm@2%- #|dPrestige Elite 12cpi (M)Helv 14pt Bold (AD).PRSd6X@C,t0qD@2 W[YYT/Prestige Elite 12cpi (M)Helv 14pt Bold (AD)Helv 12pt Bold (AD)Courier 10cpi BoldPrestige Elite 12cpi Bold (M)Helv 8pt Bold (AD)*/tC4,-Xt2pQX|?xxx,A5x `w;X.Prestige Elite 12cpi (M)Helv 14pt Bold (AD)Helv 12pt Bold (AD)Courier 10cpi Boldrestige Elite 16.67cpi (PW)Courier 10cpi Bold2i L-"m^  Systems Dev. X© X` ` sequential relationship between tasks(#` X© X` ` possible concurrence. (#` #2p;׼# ======================================== 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. 0*&& @ ddxx  !ddx x @     %Implementation Plan: The Team SDTS requires a wide range of knowledge and abilities The team needs members to fill the roles of: X(1)X` ` Source Data Model Expert Conceptual Level(#` X(2)X` ` Source Data Model Expert Format Level(#` X(3)X` ` Software Developers (Analyst, Designer, Programmer)(#` X(4)X` ` Policy Authority (#` ======================================== 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 selfexplanatory, 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. "# 0*&& @ !ddx x  Addx x @    F+Task A: Learning J Addx x  addx 8  J       &Role D  Area to learn v?References      1` SDTS Conceptual Modelj SDTS Document, Part 1, Section 1 4.1, Part 2     2 SDTS (Logical) Format  SDTS Document, Part 1, Section 4.2 5  j   1,2,3 SDTS Profiles Topologic Vector Profile Raster Profile      34 SDTS/ISO 8211 Mapping> SDTS Document, Part 3       3 ISO 8211 Standard ANSI/ISO 8211, or FIPS PUB 123  > ======================================== 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.$ 0*&& J addx 8   ddx x J >    &Task B: Conceptual Mapping Specify each SDM construct using SDTS constructs  "Preserve the information in the SDM Consider: oXSpatial Object Mapping(# oXEntities and Attributes(# oXData Quality (# oXGeocoding(# oXExtent of a Transfer(# oX... and others(# ======================================== Task B: Conceptual Mapping The task objective is the specification of each source data model (SDM) construct using SDTS constructs. The primary concern at this point is preserving the information in the SDM. Occasionally, there may be reasons why data in the SDM is not to be transferred (i.e., confidential, processing system specific, unreliable, etc.). There are many issues/topics that need to be addressed depending on the specifics of the SDM. Some of the issues common to all implementations are discussed below. (notes continued on next page) 0*&& Additional Notes on Conceptual Level Mapping Task: Spatial Object Mapping The spatial elements of the source data model need to be equated with the SDTS spatial objects. This is done via definitions. Entity and Attributes The attribution method of the source data model must be mapped into the SDTS model of entity/attribute/value. Depending on what the structure of the source method is, this could be easy or complex. Basically the SDTS model has entities, which have attributes, which haves values, belonging to domains. Similar to the spatial object definitions, the SDTS (Part 2) also contains a standard list of hydrographic and topographic entities, and attributes. Data Quality Information of a data quality nature from the source data model would be classified into one or more of the categories. Additionally the level to which the quality information pertains should be stated individual element, group of elements, entire transfer. Geocoding Any information about projections, transformations, and ground reference system, internal reference systems, can be preserved in SDTS Extent of a Transfer What will constitute a transfer geographically? How many horizontal partitions, how many vertical layers? How close will transfers follow our product series? Other issues Is graphic representation information to be preserved? Is there any security type information to preserve? How is the spatial domain of a transfer going to be encoded? etc... T# 0*&& @ ddx x  ddx x @    : %Task C: Data Element Mapping z "To account for everything required  !by the SDTS (and possibly a profile) Consider: oXSpatial Object Modules(# oXAttributes and Data Dictionary(# oXData Quality Requirements(# oX...and other module requirements(# ======================================== 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 contentcomplete 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 modulelevel. Some of the topics that are common to many implementations are discussed in the below. (notes continued on next page),$ 0*&& 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 userdefined 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. J"0*&& #2p}wC׼# @ ddx x  ddxx @    H %Task D: Build Sample Modules oX to verify the conceptual mapping (task b) and the modulelevel mapping (task c). (# oXnot a check of format understanding, but of content (do not use ISO 8211) (# ======================================== Task D: Build Sample Modules The task objective is to verify the conceptual mapping (task b) and the modulelevel mapping (task c). The team should do a "paper exercise" where an SDTS contentlevel transfer is built "byhand" 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. 0*&& @ ddxx  ddxx @     !Task E: Implementationlevel Mapping (Specify how the modules &will be encoded in ISO 8211 oXFieldlevel issues: data type, structure, format, ...(# oXFilelevel issues: which modules, fixed or varying,...(# oXRecordlevel issues: field order, content, ...(# oXMedialevel issues: type, naming, ...(# ======================================== Task E: Implementationlevel 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 transferspecific (made at the time of the transfer). 0*&& @ ddxx  ddxx @     %Task F: Encode Sample Dataset o Xto verify the accuracy and completeness of the implementation mapping (task E)(# oXcreate ISO 8211 files(# ======================================== 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 medialevel utilities. All that is necessary is that a minimum set of indicative modules be encoded, testing out the major decisions from Task E. 0*&& @ ddxx  !ddxx @    W &Task G: Systems Development oXprevious tasks can collectively be considered part of the 'analysis' phase of a systems development cycle(# oXWith the conceptual, logical, and implementationlevel mappings specified and tested, work can begin on developing a system to produce transfers (# oXDesign of a Spatial Data Transfer Processor(# ======================================== Task G: Systems Development With the conceptual, logical, and implementationlevel mappings specified and tested, work can begin on developing a system to produce SDTS/Profilecompliant 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. Another presentation will go into more detail about the "Design of a Spatial Data Transfer Processor", recommending a software architecture.