EDCS Reference Manual
Concept Mapping from FACC 2.1 to EDCS 4.0

This document describes how environmental concepts are mapped from the FACC Edition 2.1 to EDCS Version 4.0.

Table of Contents

Part 1: FACC Edition 2.1 Background

  1. Overview
  2. Denoting a Concept

Part 2: EDCS Version 4.0 Background

  1. Overview
  2. Denoting a Concept

Part 3: Concept Mapping from FACC Edition 2.1 to Version 4.0

  1. Denoting Concepts
  2. Specifying Units of Measure
  3. Attribute Value Characteristics
  4. Mapping Concepts

Part 4: Mapping Tables for FACC Edition 2.1 to EDCS Version 4.0

Part 5: Mapping API for FACC Edition 2.1 to EDCS Version 4.0

  1. Mapping API Functions
  2. Mapping API Data Structures
  3. Mapping API Use Examples
Part 1: FACC Edition 2.1 Background

1. Overview

- Scope of DIGEST

Digital Geographic Information (DGI) has evolved into an essential element in the planning and conduct of civil and military operations. The required data volume, demands, and data complexity dictate that multi-national agreements for digital data standards be established to assure compatibility. In support of this aim, the Digital Information Exchange Standard (DIGEST) standards define those aspects necessary to the exchange of DGI. They are as follows:

The type of data to be exchanged using these standards includes the digital representation of the following:

- Purpose of DIGEST

DIGEST standards enable interoperability and compatibility among national and multinational systems and users. They also support the increasing use of joint development programs. In fact, it is essential that geographic staffs involved in the development of national Geographic Information Systems are advised of the advantages of making their data structures and feature and attribute coding schemes compatible with these standards.

- Feature and Attribute Coding Catalog

The intent of the DIGEST feature and attribute coding specification is to provide a standard scheme for documenting features and attributes necessary to distinguish environmental concepts commonly found in a Digital Geographic Information Systems and for the orderly exchange of such data. The specification, which is Part 4 of DIGEST, provides a common menu of features and attributes along with a standardized coding system. They are known collectively as the - Feature and Attribute Coding Catalogue (FACC) Data Dictionary.

FACC provides a means for encoding real-world entities or objects and concepts, including those which are not necessarily visible or have a tangible physical form (e.g., airspace). FACC describes the world in terms of features, attributes and attribute values. FACC does not specify the delineation or geometry of features. Attributes are the properties or characteristics associated with features. A standardized dictionary is required to support encoding in order to maximize interoperability and to understand the production, exchange, distribution, and exploitation of digital geographic data.

The FACC Data Dictionary allows for individual nations to define "national" features and attributes for cases where such features and attributes are not readily defined in the normative FACC Data Dictionary. National extensions are not specified within the normative FACC Data Dictionary, and may not support interoperability.

The FACC Data Dictionary can be modified and updated to keep pace with the dynamic technology improvements and changing requirements. National extensions may, if proposed and approved, be incorporated into future editions of the normative FACC Data Dictionary. Procedures for extending and modifying the FACC Data Dictionary are described in DIGEST Part 4, Clause 5.3. In this way, the FACC Data Dictionary may be extended so as to satisfy application requirements.

FACC Data Dictionary elements implement a specific coding structure. The coding structure does not specify criteria for feature and attribute selection or collection (e.g., positional accuracy, feature granularity). Selection and collection criteria are dependent upon user requirements, and determined by product specifications, data models, and database schemas.

- Feature coding

Within FACC, each feature is identified (denoted) by a unique five-character code. The first character corresponds to the feature category and can have an alphabetic value from "A" to "Z". Currently there are ten major feature categories, including one category, "S", which has been reserved for dataset-specific features. The categories are as follows:

Category Category Code Name
A Culture
B Hydrography
C Hypsography
D Physiography
E Vegetation
F Demarcation
G Aeronautical Information
I Cadastral
S Special Use (Dataset-specific)
Z General

Each major feature category is further divided into subcategories identified by the second character of the five-character code containing an alphabetic value from "A" to "Z". Finally, the third, fourth, and fifth characters of the five-character feature code are a numeric value from 000 to 999. This value provides unique feature type identification within categories. Thus, all features must be identified by all five alphanumeric characters; e.g., the feature named "Building" is denoted by the code "AL015". Feature codes are listed in Annex A of the FACC Data Dictionary.

Each feature is associated with a textual description, which provides a human readable dictionary definition for the feature. Each Feature Code is also associated with a short human readable name.

Examples:

  Code: "AA010"
  Name: "Mine"
  Definition: "An excavation made in the earth for the purpose of extracting natural deposits. (See also AQ090)"

  Code: "BB150"
  Name: "Landing Place"
  Definition: "A place on shore where landing from the sea is possible."

  Code: "DB180"
  Name: "Volcano"
  Definition: "A mountain or hill, often conical, formed around a vent in the earth's crust through which molten rock, ash, or gases are or have been expelled."

  Code: "FA001"
  Name: "Administrative Area"
  Definition: "An area controlled by administrative authority."

  Code: "GB075"
  Name: "Taxiway"
  Definition: "A prepared surface providing access to/from runways and the aircraft parking area, terminal area, or service area, etc."

- Attribute coding

Attributes are used to describe characteristics of a feature, e.g., vegetation characteristic of a forested area (e.g., deciduous or evergreen). Each attribute is described by using an attribute code to represent the category of information. Each attribute is associated with a textual description, which provides a human readable dictionary definition for the attribute. Attribute value format statements provide a computer interpretation for the attribute value data type (e.g., real, alphanumeric) and attribute values give quantitative/qualitative meaning to the attribute.

Each attribute is identified by a unique three-character alphanumeric code. For example, the attribute named "Building Function Code" is denoted by the code "BFC", and the attribute named "Total Usable Width" is denoted by the code "WD2".

There are two types of attribute values: "coded" and "actual". A given attribute has only one type of value, which is specified in Annex B of the FACC Data Dictionary.

Certain generic attribute concepts are often useful for value adding, or explaining missing attribution, and are pre-defined in FACC for all types of attributes. These concepts are: Null, Unknown, Unpopulated, Not Applicable, Multiple, and Other. DIGEST Part 2, Annex C, Clause C.2.3.4.4 describes the implementation of these generic attribute concepts.

- Coded Value Attributes

"Coded" values (equivalent to enumerants in other coding schemes) may range from 0 to 999 and each value is given meaning by a name consisting of descriptive text. The value of such attributes is thus an (enumerant) code denoting the named description.

For Coded Value Attributes, its value may be logically defined as shown below, comprised of a code, a format (a data type) and a value:

Attribute Code Attribute Value Format Attribute Value
BFC I 6

where code "BFC" denotes the attribute named "Building Function Category";
                    "I" indicates the data type of the coded value (a 4-byte integer for coded value attributes); and
                    "6" indicates the value of the attribute (the code denoting the named description "Hospital").

The full specification for this attribute concept is:

  Code: "BFC"
  Name: "Building Function Category"
  Definition: "Type or purpose of the building."
  Value Domain:
    Code / Name: "0" "Unknown"
    Code / Name: "1" "Fabrication Structures"
    Code / Name: "2" "Government Building"
    Code / Name: "3" "Capitol Building"
    Code / Name: "4" "Castle"
    Code / Name: "5" "Government Administration Building"
    Code / Name: "6" "Hospital"
    Code / Name: "7" "House of Worship"
    Code / Name: "8" "Military Administration/Operations Building"
    Code / Name: "9" "Museum"
    Code / Name: ...
    Code / Name: "997" "Unpopulated"
    Code / Name: "998" "Not Applicable"
    Code / Name: "999" "Other"

Additional information about Coded Value Attributes is contained in Annex B.

- Actual Value Attributes

"Actual" values have a format (data type), one of: A (Alphanumeric), I (Integer), L (Lexical), R (Real Number) or S (Structured Text). Real values are typically measurements like height, width, etc. The units of measurement associated with an attribute are abbreviated according to the units of measurement codes defined in DIGEST Part 3, Clause 7 and incorporated into the specification of the attribute.

For example, a four lane, 19.5 meter wide road (denoted by the feature code "AP030"), having the common name "M-4", would be attributed as follows:

Attribute Code Attribute Value Format Attribute Value
RTN (route number) A "M-4"
LTN (track/lane number) I 4
WD2 (total usable width in decimetres) I 195

Data types or values for Lexical format attributes default to DIGEST Lexical level 0 or ASCII. However, when a LEX flag is present, a much wider range of character sets is available and it follows the ISO 10646 set of characters. Lexical values are described in detail in DIGEST Part 3, Clause 5.

Structured Text format is used with only a few "low frequency of occurrence" attributes which must be expressed in non-standard units of measure. The format for Structured Text is:

    number(unit)[qualifier], where

number is the numeric quantity of the attribute,
unit (see DIGEST Part 3, Clause 7) is enclosed in parentheses ( ), and
qualifier is an expression (such as a rate) which qualifies unit and is enclosed in brackets [ ].

For instance, the rate at which aircraft can safely fly according to "Minimum Enroute Altitude" (denoted by the attribute code "MEA") would be attributed as follows:

Attribute Code Attribute Value Format Attribute Value
MEA S "6000[ft](AMSL)"

where "ft" indicates "Feet" (Reference DIGEST Part 3, Clause 7), and "AMSL" indicates "Above Mean Sea Level".

Some example Actual Value Attribute specifications are:

  Code: "AIA"
  Name: "Airspace Identification Attribute"
  Definition: "A set of characters which enables an individual airspace to be uniquely identified."
  Value Domain: Lexical text string (15 characters).

  Code: "AOO"
  Name: "Angle of Orientation"
  Definition: "The angular distance measured from true north (0 deg) clockwise to the major axis of the feature. If the feature is square, the axis 0 through 89 deg shall be recorded. If the feature is circular, 360 deg shall be recorded."
  Value Domain: Integer between O and 360 inclusive, in increments of 1 degree.

  Code: "BEN"
  Name: "Basic Encyclopedia Number"
  Definition: "Unique number associated with a feature which is used to identify the feature in other national or intelligence data bases."
  Value Domain: ASCII text string (16 characters).

  Code: "C60"
  Name: "Rate of Current (IHO)"
  Definition: "Rate of current flow at tide reference level."
  Value Domain: Real, in Knots.

  Code: "PDR"
  Name: "Pedestrian Rate"
  Definition: "Number of pedestrians per time unit (this attribute utilizes the structured text approach), e.g. '10(persons)[per hour]'."
  Value Domain: Structured ASCII text (80 characters).

Additional information about Actual Value Attributes is contained in Annex B.

See the DIGEST Website for more information on the structure and content of FACC Edition 2.1.


2. Denoting a Concept

In FACC Edition 2.1, only a single mechanism exists for denoting feature (classification), attribute, and "coded" (enumerant) concepts: the code.

-- For features, for example:

  Code: "AA010"
  Name: "Mine"
  Definition: "An excavation made in the earth for the purpose of extracting natural deposits. (See also AQ090)"

The feature name is "Mine", and the code is (a 5-character string containing) "AA010".

-- For attributes, for example:

  Code: "C60"
  Name: "Rate of Current (IHO)"
  Definition: "Rate of current flow at tide reference level."
  Value Domain: Real, in Knots.

The attribute name is "Rate of Current (IHO)", and the code is (a 4-character string containing) "C60".

-- For coded attribute values (enumerants), for example:

  Attribute Code: "BFC"
  Value Domain:
    Code / Name: "1" "Fabrication Structures"

The coded value (enumerant) name is "Fabrication Structures" and the code is (an integer) 1.

In summary:

Part 2: EDCS Version 4.0 Background

1. Overview

The EDCS provides mechanisms to unambiguously specify objects used to model environmental concepts. This is accomplished by specifying a collection of nine EDCS Dictionaries of environmental concepts, and a functional interface to convert between numeric values given in different units of measure and scales. An EDCS Dictionary is a list of EDCS Dictionary Entries each of which specifies a single concept. Each EDCS Dictionary contains entries of a similar nature, however each entry is unique. Each EDCS Dictionary Entry consists of the following fields:

The nine EDCS Dictionaries are: Additional entries may be added to most EDCS Dictionaries through the process of registration.

The EDCS Application Program Interface (API) supports conversion between real values given in different units of measure.

See the EDCS Website for more information on the structure and content of the EDCS.


2. Denoting a Concept

Every concept In the EDCS Version 4.0 can be consistently denoted in two fashions: a label and a code.

The EDCS Version 4.0 carefully separates the abstract specification of the EDCS (see ISO/IEC 18025 EDCS) from language-specific bindings (see ISO/IEC 18041-4 EDCS Language Bindings: Part 4: C).

As a result, in EDCS Version 4.0, three mechanisms exist for denoting EDCS concepts: the symbolic constant, the label, and the code.

For example, from files "edcs_types.h" and "edcs_class_iso.h" in the SDK Version 4.0 release: 

   /*
    * GLOBAL CONSTANT: ECC_EXTRACTION_MINE
    *
    * Definition:
    *  An <EXCAVATION> made in the <TERRAIN> for the purpose of extracting
    *  and/or exploiting natural resources; an extraction mine.
    */

    #define ECC_EXTRACTION_MINE ((EDCS_Classification_Code)343)

   static const EDCS_Classification_Label_Entry
   EDCS_Classification_Labels[]=
   {...
    {ECC_EXTRACTION_MINE, "EXTRACTION_MINE"},
    ...
   }; /* EDCS_Classification_Labels */

The classification symbolic constant is "ECC_EXTRACTION_MINE", the label is "EXTRACTION_MINE", and the code is the EDCS_Classification_Code data type (an integer) of value 343.

Analogous mechanisms, and supporting structures and data types, exist for concepts in each of the other eight EDCS Dictionaries.

Thus:

In summary:

Part 3: Concept Mapping from FACC Edition 2.1 to Version 4.0

1. Denoting Concepts

The EDCS Version 4.0 is significantly different than FACC Edition 2.1 in the manner in which analogous concepts are denoted are denoted -- i.e., how each unique concept may be referenced by either humans or software. In EDCS Version 4.0, three mechanisms exist for denoting EDCS concepts: the symbolic constant, the label, and the code. These are all equivalent in some sense to the code in the FACC Edition 2.1.

Example concepts from each EDCS Dictionary follow, first stating its label, and then specifying its symbolic constant, and finally specifying its code data type (always fundamentally an integer) and finally its value.

EDCS Dictionaries containing concepts comparable to those in FACC Edition 2.1:

EDCS Dictionaries containing concepts not comparable to those in FACC Edition 2.1:


2. Specifying Units of Measure

Units of measure in the FACC Edition 2.1 are bound into the specification of individual attributes. For example, the following two FACC Version 2.1 attributes differ only in their units of measure:

  Code: "HGF"
  Name: "Height Above Surface Level in Feet"
  Definition: "Distance measured from the lowest point of the base at ground or water level (downhill side/downstream side) to the tallest point of the feature."
  Value Domain: Integer, in Feet.

  Code: "HGT"
  Name: "Height Above Surface Level"
  Definition: "Distance measured from the lowest point of the base at ground or water level (downhill side/downstream side) to the tallest point of the feature."
  Value Domain: Integer, in Meters.

In the EDCS Version 4.0, concepts of units of measure have been given their own EDCS Dictionary and a separate EDCS Scale Dictionary supports the specification of the scale of the units of measure for an attribute value. Unit and scale labels are prefixed with "EUC_" and "ESC_", respectively, and their codes are represented as positive, non-zero consecutively assigned integers. Both the unit and scale are required in order to fully specify the meaning of the value of many quantitative attributes.

For example, to fully specify the value of the height of a mountain, in FACC Edition 2.1 either of attributes "HGF" or "HGT" could be used, however no other unit of measure for length, or different scale, could be used. In the EDCS Version 4.0, the same information would be specified for the attribute denoted by the label HEIGHT_ABOVE_SURFACE_LEVEL by simultaneously specifying two separate, orthogonal concepts: EUC_MILE and ESC_DECI, where EUC_MILE specifies the "mile" unit of measure and ESC_DECI specifies the "deci" scale of that unit of measure.


3. Attribute Value Characteristics

In FACC Edition 2.1, each coded value (enumerated) attribute had several enumerant concepts denoted by names such as "Unknown", "Multiple", "Unpopulated", "Other", and/or "Not Applicable", which were descriptions of the attribute data value rather than the attribute data value itself.

In EDCS Version 4.0, these concepts have been moved into the EDCS Attribute Value Characteristic Dictionary, where they can be applied to attributes of any type. The labels of attribute value characteristic concepts are prefixed with "EVC_" and their codes are represented as positive, non-zero, consecutively assigned integers.

For example, in FACC Edition 2.1:

  Attribute Code: "BFC"
  Value Domain:
    Code / Name: "0" "Unknown"

The equivalent, in EDCS Version 4.0, would be denoted as the pair of concepts:

  Attribute Label: "BUILDING_FUNCTION"
  Attribute Value Characteristic Label: "MISSING"


4. Mapping Concepts

Concepts encoded using the FACC Edition 2.1 are encoded differently using the EDCS Version 4.0, however essentially all concepts supported by FACC Edition 2.1 are also supported by EDCS Version 4.0, albeit sometimes using a combination of several EDCS Version 4.0 "atomic" concepts.

The tables at the end of this section document the mapping of concepts from FACC Edition 2.1 to EDCS Version 4.0. In the significant majority of cases, the concept mapping is one-to-one and direct. In some cases, however, the mapping is more complex.

These tables document the mappings for each of the concept types in FACC Edition 2.1: features (classifications), attributes, coded attribute values (enumerants). In addition to listing the "FACC 2.1 Code" for each concept, each table includes the columns "EDCS 4.0 Concept Mapping Type", "EDCS 4.0 Concept Mapping Information", and "Additional Notes".

An additional column, "EDCS 4.0 Relevant Unit and Scale", is included for FACC Version 2.1 attributes, since this information is implicit in their definition, but must be made explicit when using the EDCS Version 4.0.

The Concept Mapping Types are as follows:

When the Concept Mapping Type is ONE_TO_ONE, ONE_TO_ONE_QUALIFIED, ONE_TO_ONE_CONDITIONAL, CHANGE_TO_CHARACTERISTIC, or CHANGE_IN_DATATYPE, then the "EDCS 4.0 Concept Mapping Information" column has very specific formatted information in it. It will be one or more of the following possibilities (multiple concepts will be of this form, separated by semicolons):

As should be clear from several of the preceeding mapping examples, it is important to keep in mind that FACC Edition 2.1 "actual" "Integer" and "actual" "Real" valued attributes include the specification of Unit and Scale information as part of their definition. Since the EDCS Version 4.0 represents these concepts separately, and supports only a specific set of Unit and Scale concepts, conversion of data values from a FACC-based data set to an EDCS-based data set may be required.

Examples:

Careful examination of the mappings of specific concepts from FACC Edition 2.1 to EDCS Version 4.0 will reveal that in some cases more than one FACC Edition 2.1 concept is mapped to the same EDCS 4.0 concept.

Examples:

Part 4: Mapping Tables for FACC Edition 2.1 to EDCS Version 4.0

Part 5: Mapping API for FACC Edition 2.1 to EDCS Version 4.0

This section describes the FACC Version 2.1 to EDCS Version 4.0 Mapping API functions, data structures, and use examples. The implementation of this mapping API is not included by default with the EDCS distribution but can be downloaded separately at www.sedris.org.

1. Mapping API Functions
2. Mapping API Data Structures 3. Mapping API Use Examples
Return to: Migration Index, Main EDCS Index

Last updated: July 28, 2006 Copyright © 2006 SEDRIS™