spatial data standards for facilities, infrastructure, and ... · pdf filespatial data...

Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE)

SDSFIE - NEC Harmonization:

Final Feature Type Comparison, and the "NEC 4.0 Adaptation"

of SDSFIE 3.0 Gold

June 22, 2012

Contract: W9132V-06-D-0005

Task Order: 22

Submitted By: Dr. Jeffrey Ehman, NEC Harmonization Team and Mr. Kurt Buehler, NEC Harmonization Lead

UNCLASSIFIED//PROPIN

THE SPATIAL DATA STANDARD FOR FACILITIES, INFRASTRUCTURE, AND ENVIRONMENT (SDSFIE)

PILOT PROJECT LESSONS LEARNED

Use or disclosure of data contained on this sheet is subject to the restrictions on the title page of this proposal. UNCLASSIFIED//PROPIN

1

Table of Contents

1.0 Introduction ........................................................................................................................ 2 2.0 Materials Adapted for the Analysis ..................................................................................... 2 3.0 Scope of Analysis ............................................................................................................... 3

3.1 Overall Goal ............................................................................................................... 4 3.2 Specific Objectives ..................................................................................................... 4 3.3 Summary Analyses: Specific Tasks, and Analytical Approach .................................... 5 3.4 Analysis of the Direct NEC – SDSFIE Feature Type Relationships ............................. 9

3.4.1 Case Classification ......................................................................................... 10 3.4.2 Case Assignment ............................................................................................ 15

4.0 Results .............................................................................................................................. 16 4.1 NEC and SDSFIE Model Characteristics................................................................... 16 4.2 Summary of Results .................................................................................................. 17 4.3 Detailed Results: the crosswalk in spreadsheet form .................................................. 19 4.4 Unresolved Issues Involving NEC and/or SDSFIE Feature Types ............................. 19 4.5 SDSFIE Feature Types Requiring Changes for the NEC 4.0 Adaptation ................... 22 4.6 Recommendations for Physical Implementation of the NEC 4.0 Adaptation .............. 27

4.6.1 Feature Type Naming ..................................................................................... 27 4.6.2 Attribute Naming ............................................................................................ 28 4.6.3 Real Property Feature Types ........................................................................... 28

5.0 Conclusions ...................................................................................................................... 29 Appendix A: Decision Framework for SDSFIE – NEC Relationship "Case" Assignment ......... 32





2

1.0 Introduction

The purpose of this report is threefold: first, to document a third and final comparison of the NEC standard (version 4.0) with the SDSFIE Gold standard (version 3.0); second, to document the changes required and recommendations for creating an Adaptation of SDSFIE 3.0 Gold for the NEC 4.0 based on the relationships between the two standards; third, a description of all unique features of the NEC 4.0 Adaptation.

The report first presents the pertinent scope (individual tasks) of Task Order 22, and then states the specific portion of those tasks that this report addresses. Next the report presents the results of the final comparative analysis of the NEC and the SDSFIE standards, with reference to associated spreadsheets with the full detailed results. The report then lays out the changes that are required in the NEC and SDSFIE standards, and issues that have been identified for resolution in order to promote additional harmonization between the standards. Next, the report lists the recommendations for generation of a physical implementation of the NEC 4.0 Adaptation of SDSFIE 3.0 Gold. The report concludes with a description of Version 1.0 of the NEC 4.0 Adaptation of SDSFIE Gold.

2.0 Materials Adapted for the Analysis

The following government furnished material was used in support of the analysis:

• NEC v4.0 Workbook.xls – the NEC model in spreadsheet format, with the following individual spreadsheets (i.e., "tabs"):

o Cover

o Entity_Views

o Entities

o Entity_Types o Entity_Attributes

o Listed_Values o Associations

o Thematic_Groups o View_Groups

o View_Types

Those spreadsheet names presented in bold indicate those augmented to perform the analysis, and are included in their updated form in an Excel Workbook entitled "NEC v4.0 Workbook - SDSFIE Crosswalk v1.0.xlsx", which accompanies the delivery of this report.





3

3.0 Scope of Analysis

Of the six Tasks listed in the detailed Statement of Work for Task 22 (NFDD-SOW-Detailed.docx) this report and the analysis upon which it is based addresses documentation components of the first four Tasks:

Task 7.1: The STARS Team will analyze and compare all concepts (elements) in the NFDD versus the concepts (elements) in Gold for the first 30 days of the TO #22 contract. This analysis will include a comparison for all the feature information concepts, object information concepts, attributes with their domain types, associations with their roles, and accompanying metadata (as appropriate) found in NFDD and Gold.

Task 7.2: The STARS Team will use the results of analysis in Task 7.1 to prepare a draft report within 45 days of award which clearly identifies (a) all concepts in NFDD which clearly do not conflict with concepts in Gold, including brief summary explanations of why; and (b) all concepts in NFDD which conflict in some way with concepts in Gold, including brief summary explanations of why. The report will include visual aids such as tables, diagrams, and schematics to clearly explain the correlation between the NFDD concepts (elements) and Gold concepts (elements). Upon delivery, the STARS Team believes a two-week government review of the report to occur and provide comments. The STARS Team will review the government response to the report and incorporate all requisite changes for a final report. This final report will be delivered within 2 weeks of receiving Government comments on the draft report.

Task 7.3: The STARS Team will prepare an initial NFDD Adaptation Design, which will include the NFDD elements which do not conflict with Gold, and the Gold elements which do not conflict with NFDD. This design documentation will be provided within three (3) weeks of finalizing the report in subtask 7.2. This Adaptation Design will specify the physical representation of the adaptation and will be presented in spreadsheet format.

Task 7.4: …The STARS Team will develop a four-part draft document with attached spreadsheets (as done for Gold) as the outcome from the modeling workshop within three weeks of the modeling workshop. The document will include:

(a) NFDD Adaptation Requirement Section in which the requirements for Gold elements which the contractor can clearly incorporate in the initial draft Adaptation and final Adaptation are documented

(b) Potential Changes to NFDD Section in which the clearly documented requirements which may require changes to the NFDD, or cannot be resolved without further effort are documented

(c) Consensus Conclusion Section in which complete documentation of the consensus conclusions reached regarding requirements (a) and (b) to include the supporting rationale and any possible future work discussed by the SMEs is thoroughly documented

(d) Potential Changes to SDSFIE in which the clearly documented requirements which may require changes to the SDSFIE are documented.





4

3.1 Overall Goal The STARS Team's overall goal for the project is to create an NEC 4.0 Adaptation of the SDSFIE. The specific objectives of this phase of the project involve (1) present the results from the final analysis and resulting crosswalk of NEC feature types to existing SDSFIE feature types, (2) identify and document unresolved issues and areas for improvement in harmonization between the two models, and (3) present recommendations for developing the physical implementation of the Adaptation.

3.2 Specific Objectives In regards to the four-part draft document described in Task 7.4 (above), the parts will be addressed in this document as follows:

Part 1. Present and discuss the final results of the analysis, i.e., a summary of the crosswalk from the NEC to the SDSFIE standard. It answers the question: what in NEC maps to SDSFIE and what does not map? Given that preceding documents focused on this analysis, part one can be considered an update to those documents. The analysis for Part 1 is addressed in Sections 3.3 and 3.4, and the results are presented in Section 4.2. The crosswalk itself, in spreadsheet form, is described in Section 4.3.

Part 2. Present and discuss the set of NEC feature types that were identified as requiring

updates prior to being considered for the crosswalk analysis. The NEC feature types to include in this set were determined primarily by the NGA SMEs during the workshops. This set of feature types is presented in Section 4.4.

Part 3. Present and discuss all of the unresolved issues that were identified as requiring

additional collaborative work for resolution in order to further the harmonization of the two standards. That work, and subsequent decisions, could result in changes to the NEC standard, the SDSFIE standard, or both. It will include further examination of the business rules established by users of both standards. This list of issues is presented in Section 4.5.

Part 4. Present and discuss the changes required in the SDSFIE model in order to create

the NEC 4.0 Adaptation of SDSFIE. Each of these changes will be submitted as "change requests" within SDSFIE's established Change Management Process. This list of changes is presented in Section 4.6.

In addition to these four document sections, recommendations for developing the physical implementation of the Adaptation are presented in Section 4.7.





5

3.3 Summary Analyses: Specific Tasks, and Analytical Approach The STARS Team approached the objective of developing a unidirectional NEC to SDSFIE crosswalk, and guidance for the Adaptation, by breaking down the necessary analysis into a number of discrete analytical steps, which are as follows:

3.3.1 Consistency of Core Attributes The NEC model was examined for presence of core attributes found in all NEC feature

types, i.e., in the "Feature Entity {Abstract}", which correspond to the five SDSFIE Foundational Attributes (Primary Key (*IDPK), sdsID, sdsFeatureName, sdsFeatureDescription, and sdsMetadataID).

3.3.2 Consistency among Feature Types For all NEC "Entity Types", SDSFIE Feature Types that have a clear and direct definitional

consistency (or conflict) were identified. Originally, cases in which potential or indirect consistency exists between a NEC Entity (Feature Type) and an SDSFIE Feature Type were identified. Subsequently, and as is reported here, "potential" and "indirect" consistency cases were resolved to either being matches, or non-matches.

Note that there are two types of NEC Entities that were not considered for this step in the

analysis: 1. NEC Abstract Entities – these are parent entities of the feature type entities 2. NEC information Entities – these are non-geometric tables that are associated with the

feature type entities

The following fields (columns), and set of possible values, were added to the Entity_Types spreadsheet to record the results of this step of the analysis:

• is NEC table object? – indicates whether the entity is a non-geometric table; possible values are:

o "yes" o "no"

• is NEC Abstract Entity? – indicates whether the entity is an Abstract (and non-geometric) Entity; possible values are:

o "yes" o "no"

• Definitional Consistency? – indicates whether the definition of the SDSFIE Feature Type and the NEC Feature Type definition are clearly and directly consistent; possible values are:

o "yes" – this assigned value includes three different cases:





6

The (NEC) "Definition" and the "SDSFIE Definition" are very similar, enough so that there is a direct conflict between the SDSFIE Feature Type and the NEC feature type.

The "SDSFIE Definition" is more general than the NEC "Definition", and the NEC feature type would match only one or more, but not all, of a relatively short list (~12) of domain values associated with a SDSFIE attribute.

The "Definition" of a NEC feature type is more general than any one "SDSFIE Definition", and the NEC feature type would need to be split among two or more SDSFIE feature types, possibly on the basis of an NEC domain value.

o "no" – there was no SDSFIE Feature Type identified with a definition that was directly or indirectly consistent with the NEC Feature Type.

• Notes 2 – comments about the relationship between the two definitions, specifications of a SDSFIE domain value that best matches the NEC feature type, or a list of one (or more, for Splits) SDSFIE Feature Type(s) directly consistent with the NEC feature type.

• SDSFIE Feature Type – the name of the SDSFIE Feature Type that is most consistent with the NEC feature type, or the name of the first in a list of SDSFIE Feature Types that are equally consistent with the NEC feature type. Note that, for records with values of "Definitional Consistency?"="no", this field may contain the SDSFIE Feature Type that was under consideration for a match with a NEC feature type.

• SDSFIE Definition – the definition of the SDSFIE Feature Type that is most consistent with the NEC feature type, or the definition of the first in a list of SDSFIE Feature Types that are equally consistent with the NEC feature type. Note that, for records with values of "Definitional Consistency?"="no", this field may contain the SDSFIE Feature Type Definition that was under consideration for a match with a NEC feature type definition

• Other fields in the crosswalk spreadsheet, added for purposes of aiding the review process, include:

• Has Real Property Identifier (RPUID)? – indicates whether ("1") or not ("0") the SDSFIE Feature Type models DoD real property and carries a RPUID attribute.

• NCGIS Bin – associated the NEC Feature Types with domain groups and particular SMEs, where "T" = topographical, "A" = aeronautical, and "M" = maritime.

3.3.3 Consistency of Feature Type Geometries For each "match" from a NEC Entity Type (Definitional Consistency = "yes"),

correspondence of the NEC geometry ("Point", "Curve", and/or "Surface") was checked against that of the matched SDSFIE geometry ("Point", "Line" or "Area/Polygon", respectively).

The following fields (columns), and set of possible values, were added to the Entity_Types

spreadsheet to record the results of this step of the analysis:





7

• NEC Allowed Geometry 1 • NEC Allowed Geometry 2 • NEC Allowed Geometry 3 • Geometry Inconsistency? • SDSFIE Allowed Geometry • SDSFIE Default Geometry

The first three above fields describe the possible geometries for NEC feature types. Only one of the four following values is listed in each:

1. "Polygon" (NEC "Surface") 2. "Point" 3. "Line" (NEC "Curve") 4. "NONE GIVEN"

Note that this listing is unique for each record. Thus, the set of possible (and existing) values are as follows:

NEC Allowed Geometry 1 NEC Allowed Geometry 2 NEC Allowed Geometry 3 Polygon Point Line Point Polygon Line Polygon Line Point Line Point Polygon NONE GIVEN The last two above (bulleted) fields describe the possible SDSFIE geometries. Only one of the three following values is listed in each:

1. "Polygon" (SDSFIE "Area/Polygon") 2. "Point" 3. "Line"

Note that this listing is non-unique. Thus, the set of existing values [a subset of those possible] are as follows:





8

SDSFIE Allowed Geometry SDSFIE Default Geometry Point Point Line/Point Point Polygon/Point Point Polygon/Line/Point Point Line Line Polygon/Line/Point Line Polygon Polygon Polygon/Point Polygon Polygon/Line Polygon Polygon/Line/Point Polygon The remaining field is as follows:

• Geometry Inconsistency? – describes the level of inconsistency between matched feature type geometries, using all three of the NEC-related fields, and the SDSFIE Allowed Geometry field; possible values are:

o "No" – describes a case in which the set of the NEC allowed geometries (and this could be 1 single geometry, or 2, or all 3 different geometries) are identical to those present in the SDSFIE Allowed Geometry field.

o "Yes (subset)" – describes a case in which the SDSFIE Allowed Geometry Field contains one or two geometry types not listed among the NEC allowed geometries (i.e., but at least one NEC allowed geometry is a SDSFIE Allowed Geometry).

o "Yes (excess)" – describes a case in which one or two NEC allowed geometries are not present in the SDSFIE Allowed Geometry Field (i.e., but at least one NEC allowed geometry is a SDSFIE Allowed Geometry).

o "Severe" – describes a case in which none of NEC allowed geometries are present in the SDSFIE Allowed Geometry Field.

3.3.4 Consistency of Feature Type Attributes For each of the NEC "Entity Types" that were found to have a clear and direct definitional

consistency (i.e., conflict) with a SDSFIE Feature Type (i.e., those with a "Yes" value in "Definitional Consistency?" column), all attributes in both standards were examined so as to identify attributes that correspond in definition.

The following fields (columns), and set of possible values, were added to the

Entity_Attributes spreadsheet to record the results of this step of the analysis:

• SDSFIE Feature Type Name – the name of the SDSFIE Feature Type that was found to be the most consistent with the NEC feature type, or the name of the first in a list of SDSFIE Feature Types that are equally consistent with the NEC feature type, as listed in the Entity_Types spreadsheet.





9

• SDSFIE Attribute Name – the name of an attribute of the SDSFIE Feature Type that matches the definition of the NEC attribute. Note that this field is blank if no SDSFIE attribute matches the definition of the NEC attribute.

• SDSFIE Attribute Definition – the definition of the named SDSFIE Attribute.

• Notes 2 – Comments about the matched attributes, or other pertinent information.

3.3.5 Consistency of Domain Values For each NEC "Entity Attributes" that was found to have a clear and direct definitional

consistency (i.e., conflict) with a SDSFIE Feature Type Attribute, and where at least one attribute from either of the two standards was enumerated, NEC domain values were examined so as to identify SDSFIE domain values (or values of attributes with a boolean data type) with a definitional correspondence which thus could be populated on the basis of the NEC attribute values.

The following fields (columns), and set of possible values, were added to the Listed_Values

spreadsheet to record the results of this step of the analysis:

• SDSFIE Feature Type Name – for the NEC domain value record, the name of the SDSFIE Feature Type that was found to be the most consistent with the NEC feature type, or the name of the first in a list of SDSFIE Feature Types that are equally consistent with the NEC feature type, as listed in the Entity_Types spreadsheet. Note that this field is blank if no SDSFIE domain value matches the definition of the NEC domain value.

• SDSFIE Domain Name – the name of the domain of an attribute of the SDSFIE Feature Type that matches the definition of the NEC domain value. Note that this field is blank if no SDSFIE domain value matches the definition of the NEC domain value.

• SDSFIE Domain Value Name – the name of a domain value for an attribute of the SDSFIE Feature Type that matches the definition of the NEC domain value. Note that this field is blank if no SDSFIE domain value matches the definition of the NEC domain value.

• SDSFIE Domain Value Definition – the definition of a domain value for an attribute of the SDSFIE Feature Type that matches the definition of the NEC domain value. Note that this field is blank if no SDSFIE domain value matches the definition of the NEC domain value.

• Notes 2 – Comments about the matched NEC domain value and/or its SDSFIE counterpart, or other pertinent information.

3.4 Analysis of the Direct NEC – SDSFIE Feature Type Relationships The NEC feature types for which a direct relationship was identified with a SDSFIE feature type (i.e., those with a "Definitional Consistency?"= "yes" value) were further analyzed to determine the nature of the relationship, and what actions would be necessary in development of the NEC Adaptation to SDSFIE 3.0 Gold.





10

In analyzing the relationships between "matched" NEC and SDSFIE Feature Types, and considering the SDSFIE Adaptation Rules1, it was evident that characterization and categorization of those relationships with respect to the Adaptation approach would be beneficial to organize and expedite the development of the physical adaptation. To this end, 3 primary "cases" and seven "sub-cases" were identified to discriminate between the types of matches and, for each case, to identify the requisite approach to adapting the SDSFIE standard to accommodate the NEC Feature Types.

3.4.1 Case Classification Overall Goal: develop a capability by which data that is compliant to the NEC schema can be generated from SDSFIE databases. The implication of this overall goal is that an Adaptation of the SDSFIE model must contain all required NEC model elements. Note that the following decision framework for distinguishing between Cases and Sub-Cases is presented in summary format in Appendix A of this document. Characterization of the Relationships between the NEC and SDSFIE Feature Type "Concepts" In general, the NEC feature types are more specific than the SDSFIE feature types. This is evident in number of NEC v. SDSFIE feature types (534 v. 236, respectively). In many cases, the NEC feature types match a SDSFIE feature type category but the NEC feature types are more narrowly defined. Thus, they are a specific "type" of the more general SDSFIE feature class. This relationship is evident between the NEC and SDSFIE feature classes in many different subject matters domains, notably in cases for which the SDSFIE feature types were purposely generalized – such as the utility models (i.e., Communication, Electrical, POL, Thermal, Water, and Wastewater nodes and segments, the generic UtilityFeature, and the Pavement model). For example, the NEC "Aerial" feature type is a specific member of the SDSFIE "CommUtilityNode" feature type. In almost all of these cases, the NEC feature types carry one or more attributes different than those present in the SDSFIE class into which they would fit. And in many of these cases, the NEC feature types carry much more attribution than the SDSFIE class into which they would fit. There are several different approaches that can be taken to account for including this different / extra attribution. At a high level, two approaches could be taken:

1. Create an Adaptation of the SDSFIE Gold model that accounts for the NEC schema differences.

2. Change the SDSFIE Gold model itself such that it accounts for the NEC schema differences.

1 Guidance for the Adaptation of SDSFIE 3.0, Version 1.0 (DISDIG, 11 May 2011)





11

Before going into the lower-level choices, these two high-level cases should first be considered. Given the stated overall goal, and if there were an objective to ensure that all DoD data developed using the SDSFIE standard were able to be available in NEC format, then it would be important that everyone collecting data would populate the additional NEC attributes2. This objective would thus point towards a solution that involve changing the SDSFIE Gold model itself, and thus requiring the Change Management Process (CMP). However, because of the relationship discussed above – that in most cases the NEC model is more specific than the SDSFIE model, and because the NEC feature types are often only one kind of a SDSFIE feature type, adding the additional NEC attributes to the more general SDSFIE feature type is not recommended. Doing so would add undesirable weight to the SDSFIE 3.0 model, which was purposely modernized away from the 2.x condition of having too many attributes. An approach that would allow NEC attributes to be collected for only one kind of a more general SDSFIE feature type would be to create a specific "sub-type" of the SDSFIE feature type that fits the NEC feature type. Because the SDSFIE model allows for attributes, enumerations, and alternate geometries to be added to a sub-type, without impacting the attribution of the parent feature type, this approach meets the objective. It does not add unnecessary bulk to the model, and does not place any undue, confusing, and/or irrelevant data collection burden when using the more general parent feature type (i.e., when the specific sub-type is not being used). For example, the 29 additional attributes of the NEC "Aerial" feature type could be placed at the subtype level, without adding to the attributes of the parent SDSFIE "CommUtilityNode" feature type. Specification of the Various Cases of Relationships between NEC and SDSFIE "Concepts:

Case 1. The NEC and SDSFIE feature type concepts are essentially the same.

In Case #1, the feature type names may be different, and the feature type definitions may use different words, but the feature types are conceptually consistent. There are 3 sub-cases of Case 1, based on:

i. whether or not there is only one NEC feature type being matched to the SDSFIE feature type

ii. whether or not the NEC feature type carries additional attribution, and

iii. whether or not the NEC and SDSFIE feature types are geometrically consistent. In this case, if there are any additional attributes that the NEC feature type carries, SDSFIE Adaptation rules allow that these attributes (and their enumerations) can be

2 The other use case is for NEC data could be seamlessly imported into the SDSFIE model to the benefit of SDSFIE users.





12

added to the SDSFIE feature type by means of an extension to an adapted version of the SDSFIE feature type.

Case 1a. There is only one NEC feature type being mapped to the SDSFIE feature type, and the NEC feature type carries no additional attribution, and the NEC and SDSFIE feature types are geometrically consistent.

In this case: • The NEC feature type is consistent in definition with the SDSFIE feature type,

and no change to the SDSFIE feature type is necessary for storage and/or subsequent export of NEC features.

Case 1b. There is only one NEC feature type being mapped to the SDSFIE feature type, and either the NEC feature type carries additional attribution, OR the NEC and SDSFIE feature types are geometrically inconsistent.

In this case: • The SDSFIE feature type is adapted though profiling and/or extension. • Additional attributes (and their enumerations, if present) that the NEC feature

type carries, as well as any extended or profiled geometries, are dealt with at the level of the adapted SDSFIE feature type, per the SDSFIE Adaptation rules.

Case 1c. There is more than one NEC feature type that is consistent in definition with a SDSFIE feature type, and at least one of the NEC feature types either carry additional attribution, or is geometrically inconsistent with the SDSFIE feature type.

In this case: • A subtype of the SDSFIE feature type will be created for each NEC feature

type that has been matched to the SDSFIE feature type. • Additional attributes (and their enumerations, if present) that the NEC feature

type carries as well as any extended or profiled geometries are dealt with at the subtype level of the adapted SDSFIE feature type, per the SDSFIE Adaptation rules.

Case 2. The SDSFIE feature type concept is more general than that of the most closely

related NEC feature type. In Case #2, given that the NEC feature type is but one "type" of the SDSFIE feature type, we recommend subtyping: creating a subtype of the SDSFIE feature type that is equivalent to the NEC feature type. In this case, if there are any additional attributes that the NEC feature type carries, SDSFIE Adaptation rules allow that these attributes can be added to the subtype, with the set of attributes of the parent feature type unaffected.





13

There are 4 sub-cases of Case 2, based on: i. the presence or absence of an enumeration in which the subtype could be

represented as an enumerated value, and ii. whether or not the NEC feature type carries additional attribution and associations

and is geometrically consistent with the SDSFIE feature type. Case 2a. No enumeration is present in which the subtype could be specified as an

enumerated value. In this case:

• The subtype with the NEC definition is created through an extension to the matching SDSFIE feature type in the adaptation.

• (There is no need to create an enumeration for the single subtype.)

Case 2b. An enumeration is present in which the subtype could be specified as an enumerated value, but there is currently no enumerated value that has the same concept as (is consistent in definition with) the subtype.

In this case: • The subtype with the NEC definition is created through an extension to the

adaptation. • Additionally, the CMP is required to add an enumerated value to the existing

enumeration. • For features within this subtype, the value for the attribute with the existing

enumeration is restricted to the added enumerated value.

Case 2c. An enumeration is present in which the subtype could be specified as an enumerated value, and there currently is an enumerated value that has the same concept as (is definitionally-consistent with) the subtype.

In this case: • The subtype with the NEC definition is created through an extension to the

adaptation. • For features within this subtype, the value for the attribute with the existing

enumeration is restricted to be the enumerated value that has the same concept as the subtype.

The singular exception to subtyping as a Case 2 recommendation is Case 2d: Case 2d. An enumeration is present for an SDSFIE attribute in which (1) the NEC

feature type could be specified as an enumerated value, and there currently is an enumerated value that has the same concept as (is consistent in definition with) the NEC feature type, and (2) the NEC feature type carries no additional attribution, no associations, and exactly matches the SDSFIE permissible geometry or geometries,





14

and (3) there is only one NEC feature type being matched to the SDSFIE feature type3.

In this case: • There is no need to subtype. The restriction on the enumerated value fully

provides the distinction between the NEC feature type concept, and that of the other, more broadly defined SDSFIE feature type. The SDSFIE feature type would be included in the adaptation as is, so that during data migration or conversion the NEC feature could be converted to the SDSFIE features.

Case 3. The NEC feature type concept is more general than that of the most closely

related SDSFIE feature type.

In Case #3, given that the SDSFIE feature type is but one "type" of the NEC feature type, in most cases we recommend creating an entirely new feature as an extension to the adaptation. In certain cases, we recommend changing the existing SDSFIE feature type to be broader, and to match that of the NEC feature type concept. The latter case would require the CMP. subtyping: creating a subtype of the SDSFIE feature type that is equivalent to the NEC feature type4.

Case 3a. There are no clear benefits to changing the SDSFIE feature type definition (and, in some cases possibly the name) that outweigh the ramifications of the change.

In this case: • A new feature with the NEC name and definition is created through an

extension to the adaptation. • All attribution and related enumerations are added as well.

Case 3b. There are clear benefits to changing the SDSFIE feature type definition (and, in some cases possibly the name) that outweigh the ramifications of the change.

In this case: • The definition of the matching SDSFIE feature type will be broadened to be

more consistent with the NEC feature type. This will require a CMP. • If there is some limited set of attribution and related enumerations associated

with the NEC, these would need to be added to the modified SDSFIE feature type. This would require a CMP.

3 Note that, to date, no instances of the Case 2d type have been identified. 4 Note that, to date, Sub-Cases of Case 3 have not been specified.





15

Case 4. There exists no definitional consistency between the NEC feature type and any SDSFIE feature type. 5.

In this case:

• A new feature type would be created as an extension to the adaptation.

3.4.2 Case Assignment The following fields (columns), and set of possible values, were added to a new spreadsheet,

populated to the greatest extent possible, and then merged with the NEC records in the Listed_Values spreadsheet to record the results of this step of the analysis:

• NEC Feature Type – a duplicate of the (NEC) Name field in the original Listed_Values spreadsheet

• Matched SDSFIE Feature Type – a duplicate of the SDSFIE Feature Type field described above (in Section 3.2.1 of this report).

• Summary of Recommendation – a description of the key steps for inclusion of the NEC Feature Type in an SDSFIE Adaptation.

• # Matches From NEC to SDSFIE FT – the number of NEC Feature Types that were matched to the "Matched SDSFIE Feature Type". Instances in which there is a one-to-one match, the value would be "1". In other cases, such as with the SDSFIE Feature Type "Structure", the number is more than "1".

• Many NEC FTs to 1 SDSFIE FT (Possible cases = 1c, 2a, 2b, or 2c) – a summarized version of the previous "# Matches…" field. Values are "++" for any value > 1 in the "# Matches…" field, and are otherwise blank.

• Case Type (Nature of relationship between feature types) – Cases 1 through 3 are specified in this field, followed by a summary description of the relationship. If uncertainty regarding the relationship, or remaining issues need to be resolved, a value of "To be Discussed" is assigned.

• Sub-Case Type – the Sub-Cases of Case 1 and Case 2 are specified in this field, followed by a summary description of the relationship.

• CMP Required?; cause – an indication whether or not the Change Management Process, part of SDSFIE governance, will need to be employed in order to follow the recommendation for the particular NEC Feature Type. Possible values are "yes" or "no". If the value is "yes", then it is followed by a short description of the "cause" for the CMP requirement.

• Geometric Inconsistency to addressed – a description of the geometric inconsistency between the NEC and the SDSFIE Feature Type (based on the values in the field described in Section 3.3.3 of this report).

5 Note that all NEC Feature types that were assigned anything other than a "yes" value for the "Definitional Consistency?" field can be considered Case 4 instances.





16

• # Attributes matched – a count of the NEC attributes that were matched to a SDSFIE attribute.

• # Attributes to be added or mapped – the number of NEC attributes that were mapped and/or need to be added to the Feature Type in the SDSFIE Adaptation.

• # Enumerations to be added (not including those with T & F Boolean values) – the number of NEC enumerations that will need to be added as part of the NEC Feature Type in the SDSFIE Adaptation.

• # Enumerated Values to be added or mapped (not including T & F Boolean values) – the number of NEC enumerated values that were mapped or will need to be added as part of the NEC Feature Type in the SDSFIE Adaptation.

• # Existing Enumerations to be considered for modification [CMP required] – the number of NEC enumerations that have matching values with SDSFIE enumerations, and will need to be considered for modification as part of the NEC Feature Type in the SDSFIE Adaptation.

• Notes / Questions – text pertaining to feature type matching, or Case/Sub-Case assignment, or other comments developed subsequent to those in the Notes 2 field (as described in Section 3.2.4 of this report.)

4.0 Results

In this section of the report, a summary of analysis results are presented, followed by an explanation of the detailed tables in the Excel Workbook entitled "NEC v4.0 Workbook - SDSFIE Crosswalk v0.1.xlsx", which accompanies the delivery of this report.

4.1 NEC and SDSFIE Model Characteristics The NEC 4.0 model consists of 632 Entities, which are comprised of:

• 14 Abstract Entities (parent grouping of one or more feature type) • 8 Superclasses • 528 feature types (with geometry) • 6 feature type subclasses, or no geometry specified • 76 tables (non-geospatial)

The SDSFIE 3.0 Gold model consists of 239 Entities, which are comprised of:

• 236 Feature Types (with geometry) • 3 tables (non-geospatial)





17

4.2 Summary of Results

4.2.1 Consistency of Core Attributes The correspondence of the five SDSFIE "Foundational Attributes" (Primary Key (*IDPK),

sdsID, sdsFeatureName, sdsFeatureDescription, and sdsMetadataID) with those that are a part of the NEC feature type model are presented in the following table:

NSG FDD SDSFIE

Relationship Entity Name Attribute Attribute

Inherited from: Entity {Abstract} Unique Entity Identifier *IDPK

Association with: Identification Information Generic Entity Identifier sdsID

Association with: Geographic Name Information

Full Name AND GenericName sdsFeatureName

Association with: GA Metadata of Feature Entity [Many Fields] sdsMetadataID

Association with: Note Memorandum sdsFeatureDescription

4.2.2 Feature Type Matches Of the 528 NEC Entity feature types (with geometry and not subclasses), the breakdown

regarding definitional consistency with the SDSFIE Feature Types is as follows:

Definitional Consistency?

Count Percentage

yes 192 36.4% no 336 63.6%

TOTALS 528 100.0%

4.2.3 Consistency of Geometries Of the 192 NEC Entity feature types (with geometry and not subclasses) with definitional

consistency, the breakdown regarding geometric consistency with the SDSFIE Feature Types is as follows:





18


Geometric Inconsistency?

Count Percentage of feature types with definitional

consistency yes No 95 49.5%

Yes (subset) 36 18.7% Yes (excess) 58 30.2%

Severe 3 1.6%

TOTALS 192 N/A Of all 528 NEC Entity feature types (with geometry and not subclasses), the overall

breakdown regarding geometric inconsistency with the SDSFIE Feature Types, by definitional consistency, is as follows:


Geometric Inconsistency?

Count Percentage of all feature types with geometry and

not subclasses yes No 95 18.0%

Yes (subset) 36 6.8% Yes (excess) 58 11.0%

Severe 3 0.6% no N/A 336 63.6%

TOTALS 528 100.0%

4.2.4 Attribute Matches The 192 NEC Entity feature types, which were found to have a clear and direct definitional

consistency with an SDSFIE Feature Type, have a total of 1761 attributes. Of these NEC attributes, 69 were found to have definitional consistency with the attribute of

a SDSFIE Feature Type. This is only 3.9% of the 1761 possible attribute matches.

4.2.5 Domain Value Matches Of the 69 NEC attribute matches, 52 have domains with at least one enumerated value that

can be matched to the domain value of a SDSFIE attribute (or, in a few cases, a SDSFIE attribute with a boolean data type). Additionally, of the 69 matched NEC attributes, 4 have domains that can be used to differentiate between SDSFIE Feature Types for "split"-type relationships (e.g., one NEC feature types to many SDSFIE Feature Types).

Within the 52 NEC domains that can be matched to one or more values of a SDSFIE domain

(or boolean T/F value), there are a total of 192 NEC domain values that can be matched to a SDSFIE domain value or T/F value of a boolean attribute.





19

4.3 Detailed Results: the crosswalk in spreadsheet form The following three spreadsheets were augmented with additional fields, which were populated to conduct the analysis:

• Entities - NEW

• Entity_Types - NEW

• Entity_Attributes - NEW

• Listed_Values - NEW These spreadsheets are a part of the Excel Workbook entitled "NEC v4.0 Workbook - SDSFIE Crosswalk v1.0.xlsx", which accompanies the delivery of this report.

4.4 Unresolved Issues Involving NEC and/or SDSFIE Feature Types In the following table, and in all subsequent document sections, font formatting is used to distinguish between NEC and SDSFIE feature types and their attributes. All feature type and attribute names are presented in italicized font. All feature type names are presented in bold font. NEC feature type and attribute names are presented in Arial font. SDSFIE feature type and attribute names are presented in Garamond font. SDSFIE Domain names are presented in italicized Garamond font, but unlike SDSFIE Attribute names, start in capital letters. SDSFIE domain values are presented in Garamond font. NEC domain names are presented in italicized Arial font, and NEC domain values in plain Arial font. The following table summarizes these presentation characteristics: Standard Feature Type Attribute Domain Value SDSFIE FeatureType attributeName DomainName value NEC Feature Type Attribute Name Domain Name value This section lists and describes all of the unresolved issues that were identified as requiring additional collaborative work for resolution in order to further the harmonization of the two standards. That work, and subsequent decisions, could result in changes to the NEC standard, the SDSFIE standard, or both. In some cases, it will include further examination of the business rules established by users of both standards. This list should be reviewed by the DISDI Program Office to determine whether to elevate some of these issues to Change Requests before further collaboration is done. These issues are summarized in the following table.





20

Name of NEC

Feature Type(s) Name of SDSFIE Feature

Type(s) Issue or Recommendation

Aqueduct WaterUtilitySegment Aqueducts may participate in water utilities, and may be main lines. WaterUtilitySegments have to be either "wMainLine" or "wServiceLine" for the waterSegmentType attribute. However, wMainLine features are defined as being pressurized, which is atypical for aqueducts. Aqueduct was not matched to any SDSFIE feature type in the adaptation.

Buried Utility; Pipeline

CommUtilitySegment; ElectrialUtilitySegment; GasUtilitySegment; POLUtilitySegment; ThermalUtilitySegment; WastewaterUtilitySegment; WaterUtilitySegment

Can map to the set of seven SDSFIE *UtilitySegment Feature Types (those listed in box to the left) according to Buried Utility:Buried Utility Type, or according to Pipeline:Product. However, there is no means to tell if these are *MainLine (e.g., gMainLine, tMainLine, or wMainLine) or *ServiceLine for the SDSFIE Gas-, Thermal-, or Water- UtilitySegment Feature Types without further NEC attribution.

Dock DocksAndWharfs Consider changing the SDSFIE Feature Type concept (name and definition) so as not to include "Dock", which technically is water (and not itself a structure) or a slip. If a decision is made regarding this concept, it could be elevated to a Change Request.

Ferry Crossing; Ice Route; Maritime Radar Reference Line; Maritime Route

TransportationRoute Need to address whether or not the term "vessel" is included in the term when we say "vehicle" in the SDSFIE Feature Type definition. Currently the inclusion of "vessel" is assumed. Consider adding an attribute and associated domain with enumerated values that specify the type of transportation route.





21

Name of NEC Feature Type(s)

Name of SDSFIE Feature Type(s)

Issue or Recommendation

Firing Range; Naval Firing and/or Practice Area

MilitaryRange; MilitaryTrainingLocation

There may be some overlap between the two SDSFIE Feature Types, and more generally the characterizations of MilitaryRange or MilitaryTrainingArea. That issue should be addressed first. Then the definitional consistency with the two NEC feature types should be evaluated.

Flood Control Structure

RiverineFlowStructure; ClosureStructure; GravityDrain

Need to get better definitions for NEC *barrage (fixedBarrage and movableBarrage) and *gate types (dykeGate, emergencyGate, and especially floodGate) and, moreover, need to examine (and resolve, if necessary) and overlaps between the gate types existing within RiverineFlowStructure, ClosureStructure, and GravityDrain, as least as they relate to the NEC Flood Control Structure FT. Also, SDSFIE RiverineFlowStructure could be renamed.

Ford RoadLinearAttributeEvent Need to evaluate mapping of NEC Ford to RoadLinearAttributeEvent, with an enumerated value addition to RoadLinearEventType.

Grain Storage Structure

GrainElevator SDS needs to revisit definition of GrainElevator, or add new entity of GrainStorageStructure with a possible enumeration of silo.

Grave Marker CemeteryOrBurialSite Grave Marker is indicative of a burial site. This relationship needs further attention.

Magnetic Station NaturalResourceSurvey The close alignment, but slight definitional inconsistency, between these two feature concepts suggests that the relationship requires further evaluation.

Railway RailTrack Business segmentation rules need additional comparison.





22

Name of NEC Feature Type(s)


Issue or Recommendation

Road Interchange; Runway Intersection

PavementSection Segmentation rules differ between NEC and SDSFIE feature for interchanges. Need to consider importance of maintaining the different business rules that prevent harmonization.

Safe Altitude Area (SAA); Safe Altitude Area (SAA) Sector; Terminal Arrival Altitude (TAA); Terminal Arrival Altitude (TAA) Sector

AirfieldImaginarySurface The enumerated values for SDSFIE SafetyZone domain require improvement. At present the definitions are the same as the values. More values could be added to differentiate among the matching NEC feature types. This item is included in the table of CRs, in Section 4.6 (below).

Scoreboard; (many others)

RecreationArea ; RecreationFeature

Consider combining the two SDSFIE Feature Types, and evaluate the definitional consistency with NEC Scoreboard.

Shoreline Ramp; Boat Ramp

DocksAndWharfs Revisit the NEC ShorelineRamp and BoatRamp feature type matches to the SDSFIE DocksAndWharfs Feature Type, and the matches to TypeOfDock:*RAMP (i.e., ACCESS_RAMP, LOG_RAMP, and RAMP) and SLIPWAY.

Spillway Dam Logical difference needs to be addressed for harmonization.

4.5 Recommended Changes to the SDSFIE Model, Resulting from Adaptation Development

This section lists and describes recommended changes to the SDSFIE model, some of which were implemented in creating the NEC 4.0 Adaptation of SDSFIE. Each of these changes will be submitted as "change requests" within SDSFIE's established Change Management Process, some with further refinement and/or added specificity. The changes are presented in two tables. The first table includes all recommended changes that were implemented for the Adaptation. The second table includes recommended changes that were not implemented for the Adaptation, including those pertaining to maintenance and improvement of the SDSFIE model.





23

This table includes all recommended changes that were implemented for the NEC 4.0 Adaptation:


Name of SDSFIE Attribute or Domain Recommended Change

AgriculturalTract AgricultureTractType Add the following domain values, based on NEC feature types to be subtypes of AgriculturalTract:

• cropLand [Note: need to differentiate cropland from "rowCrop" or otherwise alter domain.]

• farm • holdingPen • hopField • maricultureSite • plantNursery • riceField • vineyard

CommUtilityNode CommNodeType Add the following domain values, based on

NEC feature types to be subtypes of CommUtilityNode:

• cAerial • cDishAerial

GeneralContour GeneralContourType Add the following domain value, based on

NEC feature type "Isogonic Line" to be a subtype of GeneralContour:

• magneticVariation

MonitoringLocation MonitoredAspectType Add the following domain values, based on NEC feature types to be subtypes of MonitoringLocation:

• hydrologicPersistence maritimeAcousticStation [Note: need to verify that "audio" is insufficiently resolved to identify the NEC feature type referenced by this domain value.]

• tideHeight • waterDepth





24



• waterDirectionalVelocity • waterVelocity • waterVolume

PavementSection PavementSectionType Add domain value for

PavementSection:PavementSectionType = "turnPad" so as to accommodate the NEC feature type of that name.

RailTrack RailConstructionType Add the following domain value, based on NEC feature type "Railway Sidetrack" to be a subtype of RailTrack:

• rPassingSiding Define "rPassingSiding" as follows: "A rail siding, used for passing."

RecreationArea RecreationAreaType Add the following domain values, based on NEC feature types to be subtypes of RecreationArea:

• golfDrivingRange • park • racetrack

RecreationFeature RecreationFeatureType Add domain value for RecreationFeature:

RecreationFeatureType = "botanicGarden" so as to accommodate the NEC feature type of that name.

WastewaterUtilityNode WastewaterNodeType Add the following domain value, based on NEC feature type "Storm Drain" to be a subtype of WastewaterUtilityNode:

• inlet





25

This table includes recommended changes that were not implemented for the NEC 4.0 Adaptation, including those pertaining to maintenance and improvement of the SDSFIE model.



AirfieldImaginarySurface SafetyZone Bolster definitions of SafetyZone enumerated values. At present the definitions are essentially the same as the values. More values could be added to differentiate among the matching NEC feature types (see entry in table in Section 4.5).

Bridge N/A Change Bridge definition "not under an obstacle" part and add reference to "pedestrian" or "carrying a pipe".

CommUtilityNode N/A Change definition of CommUtilityNode from "…participates in the transmission of a signal…" to "participates in the transmission and/or reception of a signal". The rationale is that antennas and aerials can do either and/or both transmission and reception.

CommUtilityNode CommNodeType Alter definition of the CommUtilityNode: CommNodeType domain value "cAntenna" to avoid overlap with the cAerial and cDishAerial values that are being added.

CommUtilityNode CommNodeType Add domain value for navigational aids to the CommUtilityNode:CommNodeType domain. The rationale is that this will allow mapping to Special Navigation System Station and other NEC FTs.

CommUtilitySegment N/A Change definition of CommUtilitySegment from "…for the transmission of a signal." to "…for the transmission and/or reception of a signal."

ElectricalUtilityNode N/A Change definition of ElectricalUtilityNode to encompass "lighting systems" and "lighting facilities",





26



beacons, directional lighting, other lights, etc.

ElevationContour (Attribute) Add attribute with domain that specifies the vertical datum to which the elevation value is referenced. Add attribute that specifies the +/- convention for the elevation value, indicating if the value is above or below the referenced vertical datum.

NavigationalAid NavigationAidType Add the following domain values, based on NEC feature types to be subtypes of NavigationalAid:

• lowPoweredFanMarker • zMarker

RailroadTurntable N/A Revisit the feature type definition and make

it narrower.

RailTrack N/A Remove the word "main" from the feature type definition, as it is confusing regarding the enumeration of track type.

RailTrack RailConstructionType Change definition of the rSiding domain value to avoid conflict/overlap with the rPassingSiding value being added to the RailTrack: RailConstructionType domain. Define "rSiding" as follows: "A rail siding, not used for passing."

SpotElevation (Attribute) Add attribute with domain that specifies the vertical datum to which the elevation value is referenced.

Tower TowerUseType Alter domain values for Tower: TowerUseType, so as to account for types of control towers other than those used for air traffic control. Could change definition of "CONTROL" value or could add a set of values for each type of control towers.





27



TransportationTunnel N/A Update definition to include non-natural tunnels.

VehicleParking N/A Change definition to: "A land area…" and include the word "vessels".

WaterFeature N/A Change the word "cartographic" and removes the word "oceans". New definition: "A geographic representation of surface water in any form. This feature is separate from WaterCourseLine, NaturalWaterbody, and Impoundment, which have a special use. This feature includes seas, lakes, ponds, pools, rivers, streams, creeks, wetlands, etc."

4.6 Recommendations for Physical Implementation of the NEC 4.0 Adaptation This section contains a list of recommendations for developing the physical implementation of the NEC 4.0 Adaptation of SDSFIE 3.0 Gold that is represented as a logical model, including the representation in particular vendor software (e.g., ESRI, Oracle, etc.). [Note that there are "recommendations" implicit in the preceding Sections of this document, e.g., the overall approach for sub-typing the SDSFIE Feature Types to accommodate NEC feature types, as presented in Section 3.4.1. Also note that not all recommendations were fully implemented in the development of the initial adaptation.]

4.6.1 Feature Type Naming Each new Feature Type or Sub-Type in the NEC 4.0 Adaptation needs a physical name.

• Recommendation 1: Use the AlphaCode name, which is an UpperCamelCase version of the NEC Entity Name. These names are located in column A of the "Entity_Types - NEW" spreadsheet. If the NEC AlphaCode names are longer than 30 characters, simply truncate the names.

The physical name of each new Feature Type or Sub-Type in the NEC 4.0 Adaptation cannot

be identical to an existing SDSFIE 3.0 Gold Feature Type name.

• Recommendation 2: In cases in which the names of a NEC feature type and SDSFIE Feature Type are identical, alter the SDSFIE Feature Type name within the Adaptation.

An example for the NEC and SDSFIE "AdministrativeBoundary" is presented here:





28

1. Change the name of SDSFIE AdministrativeBoundary to SDSFIEAdministrativeBoundary

2. Create a brand new feature type for the NEC feature type named Administrative Boundary

3. Create a subtype of SDSFIEAdministrativeBoundary for the NEC feature type named Aerodrome Boundary

4.6.2 Attribute Naming First, each new attribute, being carried over from a NEC feature type, needs a physical name.

The character limit of the name is 30 characters. Many of the NEC attributes exceed this limit (see column B of the "Entity_Attributes - New" spreadsheet).

Recommendation 3: Drop the NEC feature type name from the attribute name. Recommendation 4: Remove the periods (i.e., "."), and make the letter that follows the period a capital letter. Recommendation 5: Truncate the NEC Attribute name, unless it results in a duplicate names

Examples of these rules are presented here: Aqueduct.heightAboveSurfaceLevel.accuracy => heightAboveSurfaceLevelAccurac Backshore.maritimeBottomCharacter.materialQualityOrReason =>

maritimeBottomCharacterMateri BoatLanding.hydrographicBaseHeight.referenceDatumName =>

hydrographicBaseHeightReferenc Second, SDSFIE 3.0 Gold attribute names of "area", "width", "length", and other names

denoting measurements, are reserved words. This is due to the fact that they are not permissible in several of the GIS implementations supported by the SDSFIE Tools.

Recommendation 6: For cases in which the NEC feature type has an attribute with a name denoting a measurement, the prefix "feature" will be added to the name.

Examples of this rule are presented here: area => featureArea length => featureLength width => featureWidth

4.6.3 Real Property Feature Types Real world features being captured, stored, and managed within the SDSFIE model are

typically on DoD land, are under the management control of DoD, or involve a DoD property





29

interest. This is not the case for the real world features being captured, stored, and managed within the NEC model. For the universe of feature data stored within the NEC model, some are within actual DoD real property boundaries, and some are not.

Recommendation 6: For NEC feature types that were found to best match definitionally to one of the SDSFIE Feature Types in the "RealProperty" Thematic Package, two distinct subtypes must be created: a DoD Feature Type and a Non-DoD Feature Type.

i. The subclass that will contain features that are DoD real property, and have a realPropertyUniqueIdentifier value, will be named RPNECname, where NECname is the NEC feature type name that has been matched to the SDSFIE Feature Type of the "RealProperty" Thematic Package.

ii. The subclass that will contain features that are not DoD real property, and do not have a realPropertyUniqueIdentifier value, will be named NECname, where NECname is the NEC feature type name that has been matched to the SDSFIE Feature Type of the "RealProperty" Thematic Package. In this case the realPropertyUniqueIdentifier attribute will be removed from the subclass.

5.0 Conclusions

This report provides final information about the degree to which the SDSFIE Gold model was Extended and Profiled in the development the NEC 4.0 Adaptation, based on the final decisions collectively made by the NEC and SDSFIE SMEs. Presented here are some statistics about the Adaptation, and the level of effort that was required in its implementation:

• 338 NEC geometric Entity Types (not including 6 additional subclasses or entity types with undefined geometry) do not have a corresponding SDSFIE Feature Class, and thus require an extended Feature Class in the Adaptation.

• Of the NEC attributes associated with the NEC geometric Entity Types which have a corresponding SDSFIE Feature Type Class, 96% do not have a corresponding SDSFIE attribute.

• There 15,755 NEC domain values, some shared among NEC feature types, that are not accounted for in this analysis (do not have a matching SDSFIE domain value) and will have to be addressed in the adaptation development process.

Thus, while a reasonable percentage (36%) of the NEC feature types are consistent in definition with a SDSFIE Feature Type, the attribution and enumerations matched at a much lower rate. This should not be surprising, as two standards were designed for different purposes. The SDSFIE standard includes a collection of Feature Types for which the Services are managing those real world features in some manner. The NEC standard accounts for and describes most (if not all) of the features on the earth's surface, with more specificity devoted to features with GEOINT utility.





30

Final descriptive statistics for the logical model of the NEC 4.0 Adaptation are presented in the following table:

Class of NEC Entity Types Count Percentage Matched SDSFIE Feature Class 190 36.0 % Did not match SDSFIE Feature Class 338 64.0 % Superclass with geometry 8 Not included in above percentages

Total 536 Of the 190 "matched" Entity Types, 93 are matched to an SDSFIE Feature Class that is considered Real Property. Of these 93 Entity Types, 89 require "splitting" due to the condition of NEC features being captured and stored for areas outside of DoD ownership. The method used for splitting, or the creation of two feature classes that are alternatively used to store DoD and non-DoD property, is described in Section 4.6.3 of this report. In all, 100 base "RP-" feature classes were created, including 7 emanating from additional splits (as documented in the "Entity_Types - NEW" spreadsheet of the crosswalk). Final descriptive statistics for the physical implementation of the NEC 4.0 Adaptation are presented in the following table:

Class of Adaptation Feature Class Count Note Base NEC Entity Types and Superclasses 536 From above table Base "RP-" Feature Classes 100 As described above Feature Classes from splits of Base NEC Entity Types

16 As described in "Entity_Types - NEW" spreadsheet of the crosswalk

"_A" Feature Classes to account for Area/Polygon multiple geometry

206

Following Guidance for the Adaptation of SDSFIE 3.0 (ODUSD I&E, 2011)

"_L" Feature Classes to account for Line multiple geometry

49

"_P" Feature Classes to account for Point multiple geometry

179

Total 1086 The report also provides detailed information on the steps required to adapt the SDSFIE 3.0 Gold standard for the NEC 4.0 standard. A list of potential Change Requests to be entered into the SDSFIE Change Management Process (CMP) are presented in found in Section 4.5 of this report, which were derived directly from the "Summary of Recommendation" entries and the Notes entries in the "Entity_Types - NEW" spreadsheet. With respect to creating the NEC 4.0 Adaptation to SDSFIE 3.0 Gold, some simple, commonsense rules are recommended and presented in Section 4.6 of this report. Finally, in terms of future harmonization efforts between





31

the NEC 4.0 and SDSFIE 3.0 Gold standards, remaining issues are presented in Sections 4.4 and a portion of Section 4.5 that includes recommendations that were not implemented in Version 1 of the NEC 4.0 Adaptation of SDSFIE 3.0 Gold. These remaining issues provide a starting point for future work.

Appendix A: Decision Framework for SDSFIE – NEC Relationship "Case" Assignment

Does the NEC FT have a direct definitional

relationship to a SDSFIE FT?

Is the NEC FT concept is

broader than that of the SDSFIE FT?

Is the SDSFIE FT concept is broader

than that of the NEC FT?

Does the SDSFIE FT, to which the NEC FT is

matched, have other matches to NEC FTs?

Are the NEC and SDSFIE FTs geometrically

inconsistent?

Does the NEC FT carry attribution that is not 100% matched to the

SDSFIE FT?

Does the SDSFIE FT have an

enumeration in which the NEC FT could be specified

as an enumerated

value?

Is there an enumerated

value that has the same

concept as the NEC FT?

YES Cases 1 – 3 NO Cases 1

& 2

NO Case 1

YES Case 1c

NO Cases 1a

& 1b

NO Case 1a NO Case 1a NO Case 1b

YES Case 1b YES Case 1b YES Case 1b NO Case 1b

YES Case 2

[No differentiation

(YES or NO)]

Cases 2a, 2b & 2c

[No differentiation]

Cases 2a, 2b & 2c

[No differentiation]

Cases 2a, 2b & 2c

NO Case 2a

YES Case 2b NO Case 2b

YES Case 2c YES Case 2c NO Case 2d NO Case 2d NO Case 2d YES Case 2d YES Case 2d

YES Case 3 NO Case 4

spatial data standards for facilities, infrastructure, and ... · pdf filespatial data...

Documents