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 the TLcdVPFDatabase 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.

Table 1. Properties read by the VPF model decoder
Property Mandatory Description

lcd.vpf.dbpath

x

the path to the VPF database’s DHT file

lcd.vpf.library

x

the name of the library

lcd.vpf.coverage

x

the name of the coverage

lcd.vpf.point

the name of a point feature class to decode

lcd.vpf.line

the name of a line feature class to decode

lcd.vpf.area

the name of a area feature class to decode

lcd.vpf.text

the name of a text feature class to decode

lcd.vpf.lowerleftX

the lowerleft X coordinate of the decoding bounds

lcd.vpf.lowerleftY

the lowerleft Y coordinate of the decoding bounds

lcd.vpf.width

the width of the decoding bounds

lcd.vpf.height

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.