-
Copy the schemas of different VPF products under the FME installation folder, as described in Using the VPF Writer. All these schemas are in conformance with VPF spec. Therefore, when writing to VPF, make sure that the destination feature type bears the full path name starting from the library. For instance, for DNC writing, the feature type should look like a11\cul\buildnga.aft
Note that all the VPF products allow a predefined database schema with little flexibility. There is flexibility with the library only. For example, for a DNC database, we can pick library names starting with letters a (approach), c (coastal), g (general), h (harbour) or b (browse). You can append any suffix to these library names. For instance a101, abc or a6 are all valid names provided the length does not exceed 8 characters but names like k1 or t1 would be invalid for DNC. Also, lib1 can be a valid library name for product VMAP1 but not for DNC.
Make sure that destination feature class falls under the correct folder according to the VPF database structure. For example, a11\cul\buildnga.aft would be a valid destination feature type, but a11\dqy\buildnga.aft would not, since dqy coverage is not supposed to have the table buildnga.aft. However, a11\dqy\dqyarea.aft would be acceptable.
- When translating from a non-VPF format to VPF, make sure that the features end up in the correct destination feature type that geometrically makes sense. All area features should be directed to *.aft tables, line features to *.lft tables, and so on. This mapping is automatically done from VPF to VPF.
- Writing to a VPF database may involve a huge number of feature classes and there is no automatic way of generating a workspace that has all the destination feature types in the format <lib_name>\<coverage_name>\<feature_class_name>. Feature type names of all the destination feature classes have to be brought into this format manually, unless you use the Merge Feature Type option in the Workbench Reader dialog.