Upload
charleen-hawkins
View
220
Download
1
Embed Size (px)
Citation preview
US Army Corps of Engineers
BUILDING STRONG®
Local Data Requirements and Definitions
USACE SDSFIE Training
Prerequisites: Creating a Data Dictionary for Your Local Data
BUILDING STRONG®
Video sequence
2 of 24
BUILDING STRONG®
Objectives
Understanding “source” and “target” terminology Understanding what is a valid SDSFIE element Understanding how to validate and refine local
requirements in a Source Data Dictionary Understanding where to obtain the definitions to
populate a Source Data Dictionary Understanding how to develop a geodatabase
consistent with the final Source Data Dictionary
3 of 24
BUILDING STRONG®
TERMINOLOGY: “SOURCE” AND “TARGET
4 of 24
BUILDING STRONG®
“Source” and “Target” “source” = current or “as-is” condition of your
local data, or local geodatabase schema “target” = future or “to-be” condition of your local
data, or local SDSFIE Adaptation schema
5 of 24
from Source to Target
“Source data” “Source data dictionary” “Source geodatabase” “Source schema”
“Target data” “Target data dictionary” “Target geodatabase” “Target schema” or “Adaptation
schema”
BUILDING STRONG®
VALID ELEMENT DEFINITIONS IN THE SDSFIE STANDARD
6 of 24
BUILDING STRONG®
SDSFIE Element Uniqueness: Names and Definitions
Every SDSFIE element has a specific name and one unique definition
Definitions of SDSFIE elements must be unique in meaning; semantic overlap must be minimized
No two SDSFIE elements of same type (e.g., feature type) can have same name, but different definitions
No two SDSFIE elements with different names can have the same definition.
► Generally, no renaming in USACE Adaptations► Implementation exceptions are provided; in USACE adaptations,
the use of an alias is allowable but must be justified
7 of 24
BUILDING STRONG®
Valid SDSFIE Elements: Definitions
Relevant rules relative to SDSFIE elements that already exist, and adaptation extenstions:Rule 4-12: Extended feature types must be logically unique, with non-duplicate namesRule 4-14: Extended attributes may not have duplicative or conflicting definitionsSection 4.2: “No SDSFIE Adaptation can change the definition or data type of an existing element.”
8 of 24
*Guidance for the Adaptation of SDSFIE 3.0, DISDIG, Version 1.0, 11 May 2011
BUILDING STRONG®
Implications of SDSFIE Element Name and Definiton Policy
For the purposes of developing your data dictionary, implement this guidance and these rules as follows: Do not address definitional conflicts with 3.1 model elements at this time. (That will be done later.)Address definitional conflicts among your high-level data elements (i.e., feature classes and object tables)Focus on identifying and resolving any potential conflicts involving your non-standard (custom) high-level data elements
9 of 24
BUILDING STRONG®
VALIDATING LOCAL REQUIREMENTS IN YOUR DRAFT DATA DICTIONARY
10 of 24
BUILDING STRONG®
Validating Local Requirements in your Data Dictionary
Steps for reviewing the local requirements, as expressed in your draft data dictionary:Review all elements to verify they are requiredFlag any element that can be excludedFlag any element that is questionable with respect to inclusion criteriaIdentify additional requirements
11 of 24
BUILDING STRONG®
WHERE TO OBTAIN ELEMENT DEFINITIONS TO POPULATE YOUR DATA DICTIONARY
12 of 24
BUILDING STRONG®
Element Definitions Missing from the Data Dictionary have been Highlighted
13 of 24
BUILDING STRONG®
Definitions Sources for Elements from a “Prior Release” Elements in your local geodatabase may have
originated in a prior release of the standard, e.g., SDSFIE 2.6 or SDSFIE 3.0 Gold
With the exception of domain values (aka enumerants), SDSFIE 2.6 Elements are all lowercase and use underscores, e.g.,► soil_sample_point (a 2.6 feature class)► samp_typ_d (a 2.6 attribute)► d_smpmeth (a 2.6 domain)► VIBRACORE (a 2.6 domain value)
14 of 24
BUILDING STRONG®
Obtaining Definitions for Elements from a “Prior Release” 3.0 element definitions are already in your data
dictionary if you followed steps in Video 4. If there are only a very few 2.6 and/or 3.0
feature classes and/or object tables:► use the website’s Browse interface to obtain
definitions
15 of 24
BUILDING STRONG®
Using the Browse Interface to Obtain Definitions
16 of 24
Log in at sdsfieonline.org
Go to the Models & Workflows page
Select the data model► Click SDSFIE Gold to
expand► Click SDSFIE 2.61 -
Retired to select that data model
Scroll down in the Model Elements view to find and select the feature type or object table for which you need the definition
Highlight and copy the required definition
BUILDING STRONG®
Obtaining Definitions for Elements from a “Prior Release” If you have many 2.6 and/or 3.0 feature classes
and/or object tables:► download the 2.6 or 3.0 Gold workbook model to
obtain definitions; these can be found on USACE page of the sdsfieonline.org website:
http://www.sdsfieonline.org/PublicPages/Branches/Corps.aspx
17 of 24
BUILDING STRONG®
Definition Sources for Elements with non-SDSFIE origin
For those elements of your local data that were not based on a prior release of the SDSFIE, these sources may be helpful in obtaining definitions:Metadata for feature classes and object tables may contain required definitions, including attribute definitions
► If metadata is stored in ArcCatalog metadata model, then access definition through the ArcCatlog’s Description view
► Metadata may be stored in documents outside of the geodatabase and/or ArcCatalog, e.g., text, html, or PDF format
► Other locations (e.g., a domain-specific data dictionary, if you built feature classes from that schema)
18 of 24
BUILDING STRONG®
Communications within Data Owners and Others
For definitions still missing, ask others:►data owner►business process owner►data users
Provide list of elements flagged as “questionable for inclusion in adaptation”
Ask for any additional, known, near-future requirements
19 of 24
BUILDING STRONG®
Finalizing the Source Data Dictionary
Fill in all missing definitions Make any additional exlusions, found in review Make any additions (e.g., new requirements) Resolve any definitional conflicts (e.g., semantic
overlap) (Optional) Send entire data dictioary to local data
owners and local data users for final review; solicit final feedback
Make any final changes to data dictionary
20 of 24
BUILDING STRONG®
DEVELOPING A GEODATABASE ALIGNED TO YOUR FINAL DATA DICTIONARY
21 of 24
BUILDING STRONG®
Creating the Final “Source” Geodatabase
Remember that you are still working on the copy of your local geodatabase that you made earlier
Make deletions based on additional exclusions developed in the review process
Do NOT make additions to your schema (e.g., adding a feature class or attribute) if there are no data records present for the element(s)
Implement any other changes resulting from the review process
22 of 24
BUILDING STRONG®
Review
23 of 24
Understanding “source” and “target” terminology Understanding what is a valid SDSFIE element Understanding how to validate and refine local
requirements in a Source Data Dictionary Understanding where to obtain the definitions to
populate a Source Data Dictionary Understanding how to develop a geodatabase
consistent with the populated Source Data Dictionary
BUILDING STRONG®
Next steps
Videos should be seen next are►Creating the Local Adaptation
Contact [email protected] with comments or additional information
24 of 24