The suffixes listed are prefixed by the current <ReaderKeyword> in a mapping file. By default, the <ReaderKeyword> for the GDF reader is GDF.
DATASET
Required/Optional: Required
The value for this keyword is the file containing the GDF data set to be read.
Example:
GDF_DATASET /usr/data/road/amsterdam.gdf
Workbench Parameter: Source Geographic Data File (GDF) File(s)
SPECIFICATION
The value for this keyword can be one of the following values CEN, NAVTEQ, NAVTECH (deprecated), TELEATLAS, or BESTGUESS. This indicates which GDF specification will be used when parsing the input GDF file.
A value of CEN means that the official CEN 3.0 specification will be used. The values NAVTEQ and TELEATLAS indicates that the NAVTEQ or TeleAtlas variants of the GDF specification should be used, respectively. The value BESTGUESS tells the GDF reader to use an intelligent guess as to which specification to use, based on the header of the GDF file. The default value is BESTGUESS.
Example:
A typical mapping file fragment specifying the specification looks like:
GDF_SPECIFICATION BESTGUESS
Workbench Parameter: Specification Variant
GEOMETRY_COMPLETION
The value for this keyword should be NONE, LEVEL0, LEVEL1, or LEVEL2. The default is LEVEL2. This indicates the level up to which the user wants to complete the geometry. All levels above this will have the geometry linked to the features indirectly. All levels with complete geometry will have the geometry explicitly on each feature directly.
When the FME reads GDF files, it requires a lot of effort to store and reference all the features between layers. For example, to get the geometry of a single level 2 feature, first the FME must locate all the level 1 features that are linked to it. Then it has to locate all the level 0 features that are linked to each Level 1 feature. Then it has to locate all the XYZ features that are linked to every Level 0 feature. Finally it has to put all that geometry together and process it to generate the geometry for the single level 2 feature. It is much easier if the features were output with no geometry but instead kept attributes that indicated to which other features it was linked.
For this reason, there is an option of choosing whether features produced by the reader have the "links" on them, or if the FME should to go through all the effort to complete the links and form the geometry on each feature. There is also the option of specifying on which levels the geometry should be completed, and which levels will be left as "linked" to lower-level features.
For example, if you were only interested in the level 1 features of a GDF dataset (you were going to delete or ignore the level 2 features) then there would be no reason for the FME to complete the geometry on level 2 features. You could choose to complete only the geometry on level 1 features and leave the level 2 features as linked (since you would be deleting them anyway).
Another example might be if you are planning to import features into a spatial database. In your new model, you would like to keep the links present so that if you edited and modified the geometry of a level 0 feature, the geometry of all level 1 and 2 features that link to it would immediately change. In this situation, you would select NONE for geometry completion, and just import all the features into your database as linked.
Of course, if you are translating GDF to any of the more common file-based formats for general viewing and usage, completing the geometry all the way up to level 2 is probably the most reasonable choice.
Example:
A typical mapping file fragment specifying that geometry be completed only up to level 1 looks like:
GDF_GEOMETRY_COMPLETION LEVEL1
Workbench Parameter: Geometry Completion
ATTRIBUTE_COMPLETION
The value for this keyword should be Yes or No. The default is Yes. This indicates if the user wants to complete the attribute links for each feature. If selected, all features will have their attributes explicitly appear on the features directly. If not selected, all features will have their attribute information remain in separate tables joined with link values.
The issues surrounding attribute completion when reading GDF is similar to geometry completion. Natively, a feature’s attributes are referenced through a linking mechanism and extra effort is needed if it is desired that the features read from GDF know all their attributes directly.
Therefore there is an option of choosing between whether features produced by the reader have the "links" on them or if the FME should to go through all the effort to complete the links and supply the attributes directly on each feature as they are read. Reasoning as to whether or not to choose attribute completion is similar to that outlined for geometry completion.
Example:
A typical mapping file fragment specifying that attributes not completed on each feature looks like:
GDF_ATTRIBUTE_COMPLETION No
Workbench Parameter: Attribute Completion
OUTPUT_MERGED_RECORDS
The value for this keyword should be Yes or No. The default is No. This indicates if the user wants attribute features that have been used in attribute completion to be output by the reader. This keyword has no effect if the ATTRIBUTE_COMPLETION keyword is set to No. If this keyword is set to Yes then features that primarily carry attribute values (for example GDF Name records) will be output.
Example:
A typical mapping file fragment specifying that record features that were used in attribute completion should not be output looks like:
GDF_OUTPUT_MERGED_RECORDS No
Workbench Parameter: Output Merged Records
CODE_VALUE_LOOKUP
The value for this keyword should be Yes or No. The default is Yes. This indicates if the user wants to replace the known codes of attributes with their actual expanded values for each feature. If selected, all features will have the code values of their attributes replaced. For example, an attribute Vehicle Type with the value 16 will have that value replaced by Taxi. If this option is not enabled, all features will have their attribute values left as the original codes.
Example:
A typical mapping file fragment specifying that code values not be completed on each feature looks like:
GDF_CODE_VALUE_LOOKUP No
Workbench Parameter: Code Value Lookup
GDF_MULTIPLE_VALUE_SEPARATOR
The value for this keyword can be any string. The default is |||. This indicates which characters will separate the values when one attribute has more than one value.
For instance, the Official Name of an Order 1 Administrative Area (Country) may have two values: Japan and Nippon. If the separator above is used, the value for Official Name will become Japan|||Nippon. It is useful to have known strings as separators when automatically splitting these strings during future processing.
Example:
A typical mapping file fragment specifying the separator as a colon looks like:
GDF_MULTIPLE_VALUE_SEPARATOR :
Also, to represent multiple values, the GDF Reader will output a list of attributes in the form:
Official Name{0} = Japan
Official Name{1} = Nippon
IGNORE_METADATA_HEADER
This option supersedes the previous IGNORE_03_RECORDS. The value for this keyword should be Yes or No. The default is No. This indicates if the user wants to ignore the FIELDEFREC (03) and RECDEFREC (04) records in the GDF file, or parse and honor them. If selected, all FIELDEFREC (03) records and RECDEFREC (04) in the file will be ignored when reading. This is useful for reading files with corrupt metadata. Without ignoring these corrupt lines, the file could not be read correctly. However, if the dataset is encoded in a schema different from the default one provided by the reader and the FIELDEFREC (03) and RECDEFREC (04) records for that dataset are corrupted, it will be impossible for the reader to read the dataset.
Example:
A typical mapping file fragment specifying that the metadata from the dataset header should be ignored looks like:
GDF_IGNORE_METADATA_HEADER No
Workbench Parameter: Ignore Header Metadata Records
CODE_LOOKUP
This directive indicates if the user wants to replace the known codes of attribute names with their actual expanded name for each feature. If selected, all features will have the code values of their attribute names replaced. For example, an attribute ON will be renamed to Official Name. If this option is not enabled, all features will have their attribute names left as the original codes.
A typical mapping file fragment specifying that codes not be completed on each feature looks like:
Values: YES | NO
Default Value: YES
Example:
GDF_CODE_LOOKUP No
Workbench Parameter: Code Value Lookup
SEARCH_ENVELOPE
Using the minimum and maximum x and y parameters, define a bounding box that will be used to filter the input features. Only features that interact with the bounding box are returned.
If all four coordinates of the search envelope are specified as 0, the search envelope will be disabled.
Mapping File Syntax
<ReaderKeyword>_SEARCH_ENVELOPE <minX> <minY> <maxX> <maxY>
Note: If all four coordinates of the search envelope are specified as zero, the search envelope will be disabled.
Required/Optional
Optional
Workbench Parameter
Minimum X, Minimum Y, Maximum X, Maximum Y
SEARCH_ENVELOPE_COORDINATE_SYSTEM
This directive specifies the coordinate system of the search envelope if it is different than the coordinate system of the data.
The COORDINATE_SYSTEM directive, which specifies the coordinate system associated with the data to be read, must always be set if the SEARCH_ENVELOPE_COORDINATE_SYSTEM directive is set.
If this directive is set, the minimum and maximum points of the search envelope are reprojected from the SEARCH_ENVELOPE_COORDINATE_SYSTEM to the reader COORDINATE_SYSTEM prior to applying the envelope.
Required/Optional
Optional
Mapping File Syntax
<ReaderKeyword>_SEARCH_ENVELOPE_COORDINATE_SYSTEM <coordinate system>
Workbench Parameter
Search Envelope Coordinate System
CLIP_TO_ENVELOPE
This directive specifies whether or not FME should clip features to the envelope specified in the SEARCH_ENVELOPE directive.
Values
YES | NO (default)
Mapping File Syntax
<ReaderKeyword>_CLIP_TO_ENVELOPE [yes | no]
Workbench Parameter
Clip To Envelope
EXPOSED_ATTRS
This directive allows the selection of format attributes to be explicitly added to the reader feature type.
This is similar to exposing format attributes on a reader feature type once it has been generated; however, it is even more powerful because it enables schema-driven applications other than Workbench to access and leverage these attributes as if they were explicitly on the schema as user attributes.
The result of picking a list of attributes is a comma-separated list of attribute names and types that will be added to the schema features. Currently all reader feature types will receive the same set of additional schema attributes for a given instance of the reader.
Required/Optional
Optional
Mapping File Syntax
Not applicable.
While it is possible for FME Objects applications to invoke this directive, the required format is not documented.
This directive is intended for use in our GUI applications (for example, Workbench) only.
Workbench Parameter
Additional Attributes to Expose