EDCS Reference Manual
Concept Mapping from EDCS 4.2 to FACC 2.1 |
---|
This document describes how environmental concepts are mapped from the EDCS Version 4.2 to FACC Edition 2.1.
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 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.
Every concept In the EDCS Version 4.2 can be consistently denoted in two fashions: a label and a code.
The label field of an EDCS Dictionary Entry is a compact and human-readable designator that is used to denote a concept. Labels may include the name or names for the concept. Labels:
The code field of an EDCS Dictionary Entry is a compact, and not necessarily human-readable, designator that is used to denote a concept. Codes:
There is a one-to-one relationship between labels and codes in the same EDCS Dictionary. Therefore, a label and a code may be used interchangeably to denote the same concept.
The EDCS Version 4.2 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.2, 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.2 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)400) 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 400.
Analogous mechanisms, and supporting structures and data types, exist for concepts in each of the other eight EDCS Dictionaries.
Thus:
The symbolic constant can be used by programmers as a shorthand for the code, with the value of the code denoting the concept (e.g.) "Extraction Mine". The symbolic constants are defined in ISO/IEC 18041-4 EDCS Language Bindings: Part 4: C.
The label is human-readable, and follows particular syntactic rules. It also denotes the concept (e.g.) "Extraction Mine", and is represented as a string with no prefix. Its string-value is defined in the EDCS abstract specification (ISO/IEC 18025 EDCS). The corresponding symbolic constant is derivable from the label through a set of rules documented in ISO/IEC 18041-4; in particular, the results of applying those rules are fully documented there.
The code is an integer, and is intended for efficient software use. It also denotes the concept (e.g.) "Extraction Mine".
In summary:
- 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:
- 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"- 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.
- Metadata coding
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. Metadata are used to describe why the value of an attribute doesn't fall within its specified range of expected values. Metadata values which an attribute can take on are: "Unknown", "Multiple", "Unpopulated", "Not Applicable", and "Other". In addition "Null/No Value" is also defined. How these metadata concepts are encoded in FACC attribute values depends on the representation of that attribute. Table 5.2, below, from the FACC specification details these encodings.
Attribute Type |
Null/No Value |
Unknown | Multiple | Unpopulated |
Not Applicable |
Other |
---|---|---|---|---|---|---|
Text (T) - Fixed Length - Variable Length |
|
|
|
|
|
|
|
-327682 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Notes: The value for "Null" for each data type is defined in DIGEST, Part 2, Annex C, Table C-67.
If the length is one or two "-" or "--" should be used instead (refer to DIGEST, Part 2, Annex C, Clause C.2.5.4).
The Null value for a short integer is defined to be the bit pattern 10000000 00000000, which is equivalent to the maximum negative number in "two's complement number format". Therefore for a 16-bit length number, the corresponding value for Null is -32768.
The Null value for a long integer is defined to be the bit pattern 10000000 00000000 0000000 0000000, which is equivalent to the maximum negative number in "two's complement number format". Therefore for a 32-bit length number, the corresponding value for Null is -2147483648.
See the DIGEST Website for more information on the structure and content of FACC Edition 2.1.
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 3-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:
The code is a 5- (or 3-) character string, or an integer, intended primarily for efficient software use, but in practice might be a string that is (sometimes) human interpretable, e.g., the code "AA010" denoting the feature concept named "Mine".
The EDCS Version 4.2 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.2, 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.
The EDCS Version 4.2 symbolic constant is a constant
that can be used by programmers as a shorthand for the code.
-- The FACC Edition 2.1 code is a "naked" string or
integer. Although a C-language specific symbolic constant might
be defined, the DIGEST FACC specifies no such functionality.
The EDCS Version 4.2 label is human-readable,
but follows particular syntactic rules and can be machine parsed.
The corresponding symbolic constant is easily derivable
from it.
-- The FACC Edition 2.1 code is a compact string or
integer. Although the codes for features (classification)
and attributes (both strings) could be (and sometimes are) memorized,
they are not especially convenient for such use for most users.
The EDCS Version 4.2 code is functionally equivalent
to the FACC Edition 2.1 code, however it is always an
integer. In FACC Edition 2.1 codes it may be either a
string or an integer.
-- It is important to keep these differences in code types in mind.
All EDCS Version 4.2 codes are positive, non-zero integers that
are consecutively assigned within the scope of an EDCS Dictionary. The
code whose value is the integer 1 will denote different concepts
in different EDCS Dictionaries, just as the label whose value
is "METER" will denote different concepts in different EDCS Dictionaries.
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:
Classification (comparable to FACC Edition 2.1 Feature)
EC Label: "ACCESS_ZONE"
#define ECC_ACCESS_ZONE ((EDCS_Classification_Code) 1)
Attribute (comparable to FACC Edition 2.1 Attribute)
EA Label: "ACOUSTIC_AMBIENT_NOISE_SPECTRAL_MODEL"
#define EAC_ACOUSTIC_AMBIENT_NOISE_SPECTRAL_MODEL ((EDCS_Attribute_Code)
9)
Enumerant (comparable to FACC Edition 2.1 Coded
Attribute Values)
EE Label: "ANDES" (for EA Label: "ACOUSTIC_AMBIENT_NOISE_SPECTRAL_MODEL")
#define EEC_ACAMBNSESPECMD_ANDES ((EAC_Acoustic_Ambient_Noise_Spectral_Model)
1)
(Note that each EA is a separate data type.)
EDCS Dictionaries containing concepts not comparable to those in FACC Edition 2.1:
Metadata (FACC handles these in a variety of fashions)
EM Label: "VALUE_SPECIFIED"
#define EVC_VALUE_SPECIFIED ((EDCS_Metadata_Code) 1)
Unit (FACC binds these into the specification of
individual attributes)
EU Label: "AMP_PER_METRE"
#define EUC_AMP_PER_METRE ((EDCS_Unit_Code) 1)
Unit Equivalence Class (FACC has nothing comparable)
EQ Label: "ABSORBED_DOSE"
#define EQC_ABSORBED_DOSE ((EDCS_Unit_Equivalence_Code) 1)
Scale (FACC has nothing comparable)
ES Label: "YOTTA"
#define ESC_YOTTA ((EDCS_Scale_Code) 1)
Organizational Schema (FACC has nothing comparable)
EO Label: "GENERAL"
#define EOC_GENERAL ((EDCS_Organization_Schema_Code) 1)
Group (FACC has nothing comparable)
EG Label: "ABSTRACT_CONCEPT" (for EO Label: "GENERAL")
#define EGC_GEN_ABSTRACT_CONCEPT ((EOC_General) 1)
(Note that each EO is a separate data type.)
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.2, 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.2, 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.
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. Additionally, non-coded value (text, integer, and real) take on values as defined in Table 5.2.
In EDCS Version 4.2, these concepts have been moved into the EDCS Attribute Value Metadata Dictionary, where they can be applied to attributes of any type. The labels of attribute value metadata 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.2, would be denoted as the pair of concepts:
Attribute Label: "BUILDING_FUNCTION"
Attribute Value Metadata Label: "MISSING"
Concepts encoded using the FACC Edition 2.1 are encoded differently using the EDCS Version 4.2, however essentially all concepts supported by FACC Edition 2.1 are also supported by EDCS Version 4.2, albeit sometimes using a combination of several EDCS Version 4.2 "atomic" concepts.
The tables at the end of this section document the mapping of concepts from EDCS Version 4.2 to FACC Edition 2.1. 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 EDCS Version 4.2 where there are equivalent concepts in FACC Edition 2.1: classifications, attributes, enumerants. In addition to listing the "EDCS 4.2 Symbolic Constant" for each concept, each table includes the columns "EDCS 4.2 Concept Mapping Type", "FACC 2.1 Concept Mapping Information", and "Additional Notes".
The Concept Mapping Types are as follows:
This section describes the EDCS Version 3.x to FACC Edition 2.1 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 Functionsmap_EDCS_attribute.c A sample program taking a list of EDCS Version 4.2 attribute symbolic constants on the command line, and printing out the associated FACC Edition 2.1 concept mapping information.
Example: To retrieve mapping information for EAC_HEIGHT_ABOVE_SURFACE_LEVEL and EAC_WIDTH:
"map_EDCS_attribute EAC_HEIGHT_ABOVE_SURFACE_LEVEL EAC_WIDTH"
Example Output:
"Mapping for EDCS Attribute EAC_HEIGHT_ABOVE_SURFACE_LEVEL
was INDETERMINATE. This means that it maps to different FACC Attributes depending on the value associated with it.
The mapping for non-interval and non-metadata values is:
FACC Attribute:
HGT
FACC Value Type: SHORT
INTEGER
FACC Expected Unit:
EUC_METRE
FACC Expected Scale:
ESC_UNI
Mapping Notes:
Changed datatype from REAL to "Integer". May also map to HTR if interval-valued
or metadata.
Mapping for EDCS Attribute EAC_WIDTH was ONE to ONE:
FACC Attribute: WGP
FACC Value Type: FLOAT
FACC Expected Unit: EUC_METRE
FACC Expected Scale: ESC_UNI"
map_EDCS_enumerant.c A sample program taking a list of EDCS Version 4.2 enumerant symbolic constants on the command line, and printing out the associated FACC Edition 2.1 concept mapping information.
Example: To find mapping information for EEC_BLDGFN_SHOPPING_CENTRE
and EEC_TERMRPHTY_SAND_DUNES:
"map_EDCS_enumerant EEC_BLDGFN_SHOPPING_CENTRE
EEC_TERMRPHTY_SAND_DUNES"
Example Output:
"Mapping for EDCS Enumerant EEC_BLDGFN_SHOPPING_CENTRE
was ONE to ONE:
FACC Attribute:
BFC
FACC Value Type:
CODED
FACC Coded Value:
122
Mapping for EDCS Enumerant EEC_TERMRPHTY_SAND_DUNES was
ONE to ONE:
FACC Attribute:
SRD
FACC Value Type:
CODED
FACC Coded Value:
38"
map_EDCS_attribute_value.c
A sample program taking a space delimited list of EDCS Version 4.2 attribute
symbolic constant and value specification pairs on the command line,
and printing out the associated FACC Edition 2.1 concept mapping information.
Handles interval, boolean, metadata, and single values.
Example: To find mapping information for EAC_BRUSH_DENSITY
with the interval value [0, 5] and the EU PERCENT with ES UNI,
and EAC_RIGHT_BANK_SLOPE with the interval value [15, 30]
and the EU PERCENT with ES UNI, and EAC_TREE_SPACING with the real value
5.0 and the EU METRE with ES UNI, and EAC_CAPACITY with the metadata value
of EVC_MISSING:
"map_EDCS_attribute_value "EAC_BRUSH_DENSITY
[0, 5] EUC_PERCENT ESC_UNI" "EAC_RIGHT_BANK_SLOPE
[15, 30] EUC_PERCENT ESC_UNI" "EAC_TREE_SPACING 5.0 EUC_METRE ESC_UNI"
"EAC_CAPACITY EVC_MISSING""
Example Output:
"Mapping 1: "EAC_BRUSH_DENSITY [0, 5] EUC_PERCENT ESC_UNI"
Mapping was ONE to ONE:
FACC Attribute: BUD
FACC Value Type: CODED
FACC Coded Value: 1
Notes: <= 5%.
Mapping 2: "EAC_RIGHT_BANK_SLOPE [15, 30] EUC_PERCENT ESC_UNI"
Mapping was ONE to ONE:
FACC Attribute: SR1
FACC Value Type: CODED
FACC Coded Value: 1
Notes: <= 30%.
Mapping 3: "EAC_TREE_SPACING 5.0 EUC_METRE ESC_UNI"
Mapping was ONE to ONE:
FACC Attribute: TSD
FACC Value Type: FLOAT
FACC Float Value: 5.000000
Notes: May also map to TS1/TS2/TS3 if interval-valued
or metadata.
Mapping 4: "EAC_CAPACITY EVC_MISSING"
Mapping was ONE to ONE:
FACC Attribute: CAP
FACC Value Type: TEXT
FACC Text Value: UNK"
|