The TLcdVPFModelDecoder
class is an implementation of ILcdModelDecoder
for the decoding of VPF data.
You can choose one of three options for decoding VPF feature classes:
-
Pass the Database Header Table (DHT) to the decoder, which contains information that defines the database content.
-
Pass a VPF properties file or a Java Properties object, describing the feature class to be decoded, to the decoder.
-
Pass a
TLcdVPFFeatureClass
object to the decoder. You can retrieve it using the VPF API, starting from theTLcdVPFDatabase
class.
The contents of the VPF properties file are presented in detail in The VPF properties file, while Configuration parameters details the configuration parameters of the VPF decoder.
Model structure resulting from a DHT file
When you decode VPF data by passing the DHT file to the decoder, all feature classes of that database will be decoded. The
decoder returns
an ILcdModelTreeNode
that has the same hierarchy as the VPF data model. The ILcdModelTreeNode
returned by the decoder represents the VPF database.
It contains one or more VPF libraries, which in turn contain the VPF coverages. These ILcdModelTreeNode
objects do not contain any elements. They are used only to maintain the structure of the VPF data model. The models representing
the VPF feature classes, which contain the VPF primitives, are in the ILcdModelTreeNode
of the VPF coverages.
Database | +-- Library | +-- Coverage | +-- Feature Class
The VPF properties file
VPF property files can be used to specify a VPF feature class, and optionally its bounds. If you use property files, you can load feature classes without having to select them through the API or a GUI each time they are needed. Table 1, “Properties read by the VPF model decoder” provides an overview of the properties that are supported by the VPF model decoder. Fields marked as mandatory should be present in each VPF property file.
Property | Mandatory | Description |
---|---|---|
|
x |
the path to the VPF database’s DHT file |
|
x |
the name of the library |
|
x |
the name of the coverage |
|
the name of a point feature class to decode |
|
|
the name of a line feature class to decode |
|
|
the name of a area feature class to decode |
|
|
the name of a text feature class to decode |
|
|
the lowerleft X coordinate of the decoding bounds |
|
|
the lowerleft Y coordinate of the decoding bounds |
|
|
the width of the decoding bounds |
|
|
the height of the decoding bounds |
Configuration parameters
Decoding bounds
You can pass decoding bounds to the decoder to limit the spatial extent of the model to be decoded. The use of decoding bounds can result in a performance improvement, as well as lower memory consumption.
You can specify decoding bounds in three ways:
-
Pass them immediately to the decoder in the
decode
method -
Include them in the VPF properties file
-
Set bounds on the decoder with the
setDecodingBounds
method
The decoder looks for the bounds in the listed order.
Some objects may be partly inside and partly outside the
decoding bounds. The model’s applyOnInteract
operation will only apply
functions on those objects if the applying bounds interact with the part of the object that
is within the decoding bounds. This might result in unexpected behavior outside the decoding
bounds: an object might be completely painted while only the part inside the decoding
bounds is selectable, for example.
Model Types
The VPF model decoder is capable of creating three types of models:
-
_Hybrid model:_the recommended default model type used by the decoder. This model is a lazily-loaded model that uses caches. The most frequently accessed caches are permanently kept in memory, while the others are soft-referenced. This results in a higher minimum memory requirement than the on-the-fly model, as well as a more consistent performance. The more memory is available, the better the model will perform, because of fewer cache misses.
-
In-memory model: this model is a conventional LuciadLightspeed model, loaded fully into memory at once when the model is created.
-
On-the-fly model: this model is a lazily-loaded model; its features are loaded into memory only when they are needed the first time. The model uses some caching, but all caches are soft-referenced. VPF feature objects are re-used and should therefore not be referenced. See the next section for more information about referencing objects. The more memory is available, the better the model will perform, because of fewer cache misses.
You can use the setModelType
method to configure the model type used by the VPF model decoder.
Model element modes
A VPF feature may consist of multiple geometric primitives, a country may consist of multiple islands, for example, a river may be split up by a tile border, and so on. You can map the primitives and features to model elements in two different ways:
-
One model element per geometry: each individual VPF primitive is mapped on a model element. If a feature consists of multiple geometries, there will be as many elements in the model as the number of primitives it has. They will all have the same feature ID but a different geometry.
-
One model element per feature: each feature is mapped on a model element.If a feature consists of multiple primitives, there will be only one element in the model, an
ILcdShapeList
that contains all geometries of the feature.
You can configure the model element mode using the TLcdVPFModelDecoder.setModelElementMode()
method.