Feature Representation (VPF Writer)

FME can write the notes.rat tables and the associated Note Join Table (.njt) for each feature class. To create the notes table, add a list attribute to the feature that has the note. For example, to add two notes to a maritima feature class in the lim coverage, add the attributes:

notes_rat{0} INTRACOASTAL WATERWAY The project depth is 3.6 meters

notes_rat{1} CAUTION: Improved channels are subject to shoaling

notes_rat{} does not need to be on the feature type definition

The VPF writer will try to honor as much as possible the original VPF specific attributes.

If a vpf_text_height is present, it will be used to write the SYMBOL.RAT size attribute. If none is present but a vpf_text_scale is present, then vpf_text_height will be guessed from the fme_text_size. If no vpf_text_height and no vpf_text_scale are present, then a default value of 2 will be used, as long as the text feature has a symbol_id attribute.

If a vpf_original_geometry attribute is present and the point geometry of the FME text feature is still identical to the first coordinate of the original geometry, then the original geometry will be written. If the vpf_original_geometry attribute is not present or the point geometry of the FME text feature is not identical to the first coordinate of the original geometry, then the current point coordinate will be written with a second point to express the current rotation, provided it is not zero. That second point, representing the lower right corner of the string, will be guessed using the fme_text_size (height in ground units) and the approximation that the width of a character in ground units is half its size.

A feature’s feature type plays an important role in writing a VPF database. The feature type on a feature class feature tells the writer what feature class a feature belongs to; what coverage that feature class exists in; and what library the coverage belongs to. Since it is possible to have same table name under the same coverage belonging to different libraries but with different schemas, the only way a feature type can defined as unique is by using a combination of library name, coverage name and feature class name. The syntax for a feature class feature’s feature type is:

<library name>\<coverage name>\<feature class>			

For example:

DNC 	: H001\CUL\TRANSL
VMAP0 : SASAUS\TRANS\ROADL

Note that the ‘\’ separator can be changed to another character by specifying a value for the Feature Class Separator reader parameter.

Recognized library, coverage and feature class types will vary according to the writer’s product type. For example, if a writer’s product type is DNC and the writer finds a feature with the feature type browse\libref\libref, it will know that all the incoming features belong to the libref feature class in the libref coverage for the browse library in the DNC database.

The feature type for a metadata feature tells where in the database the metatable exists. A metadata feature’s feature type may have one or no separators depending on where the underlying metadata table exists in the database. Features destined for a metadata table at the root level of a database will have no separators and the following syntax.:

<metatable name>

For example, if an incoming feature is destined for the database header table named dht the feature type for these features will simply be dht.

Features destined for a metadata table that exists at the library level of a database will have the syntax:

<library name>\<metatable name>

For example, if an incoming feature is destined for the library header table named lht in the browse library of a DNC database, the feature type for these features will be browse\lht.

All VPF products have four recognized levels of topology ranging from level 0 to level 3. (See the Military Standard, Vector Product Format, MIL-STD-2407, for details.) Text features do not participate in topology building. Since topology is defined at the coverage level, the VPF writer accumulates all the features belonging to one coverage and then throws them in the topology pipeline. Based on the topology level the coverage belonged to, the topology pipeline splits features into primitives and builds all the topological relationships. After the topology has been built, primitives are written to respective primitive tables and the features to the feature tables.

Note that the writer expects that the data given to it is topologically clean (that is, it is in conformance with the VPF spec on topology). The writer is not responsible for doing any topological cleaning. Any topologically unclean data may result in incorrect output data.

VPF data can be tiled or untiled. When data is tiled, the features are first clipped for every tile and then thrown into the pipeline for topology building. This process is repeated for every tile, since topology for every tile is supposed to be independent from those of other tiles. It is possible to skip tile clipping using SKIP_TILE_CLIPPING Skip Tile Clipping to improve performance. However, this parameter is recommended only in certain specified conditions.

For the features that cross tile boundaries, the information of the current primitive ID, the external tile and the primitive ID in that tile are stored as triplet IDs on the primitives. By default, VPF writer does not calculate the triplet IDs due to immense overhead involved in the process.

To activate clipping in the writer, SKIP_TILE_CLIPPING Skip Tile Clipping must be set to No, and the TILEREF feature type for each of the libraries must be written.