Every VPF feature class contains a feature table to define the attributes appearing on features of that class. It is also possible for a VPF feature class to include related attributes from another table, by specifying that a particular column of the feature class table relates to a primary column of another table.
Consider, for example, a mythical database which includes a list of the families of a street and if they have a fire hydrant on their lawn. This database also allows for many families to reside at one address. The feature class is defined as follows:
- The feature table contains a special column, STRADDR.RAT_ID, used to join to the identifier column of the STRADDR.RAT table.
- The STRADDR.RAT table defines the street addresses and contains a column, OCCUPANT.RAT_ID, that links into the OCCUPANT.RAT table.
The schema for the street feature class is something like:
Class name: STREETL Geometry type: vpf_line Feature table: STREETL.LFT
Table STREETL.LFT attributes:
ID int (Row identifier) STRADDR.RAT_ID int (Link to STRADDR.RAT table.) EDG_ID int (Link to edge primitive table.) STRCODE int (Code for street name; refers to a value lookup in the
INT.VDT table.)
Table STRADDR.RAT attributes:
ID int (Row identifier) ADDRESS int (Street number) HYDRANT char(3) (Does it have a hydrant on its lawn; 'Yes' or 'No '). OCCUPANT int (Link to “occupants” table.)
Table OCCUPANT.RAT attributes:
ID int (Row identifier)
FAM_NAME text(40) (Family name)
NUM_RES int (Number of residents)
CLUST_ID int (Identifies “cluster” of occupants.)
The feature class table relates the tables according to the following structure:
|
Table |
Foreign Attribute |
Related Table |
Join Attribute |
|
STREET.LFT |
EDG_ID |
EDG |
ID |
|
STREETL.LFT |
STRADDR.RAT_ID |
STRADDR.RAT |
ID |
|
STRADDR.RAT |
OCCUPANT |
OCCUPANT.RAT |
CLUST_ID |
A small cul-de-sac containing two properties, one of which has two families living in it, might be represented in the STREETL feature class with the following feature. Note the use of nested lists and enhanced values from VDTs. The HYDRANT attribute would normally come from a value attribute table as well.
Feature class: STREETL
Geometry: Aggregate containing one line
Attributes on feature:
ID 12
STRADDR.RAT_ID 5
EDG_ID 19
STRCODE 5
STRCODEdesc “29th Avenue”
STRADDR_RAT{0}.ID 5
STRADDR_RAT{0}.ADDRESS 1234
STRADDR_RAT{0}.HYDRANT “Yes”
STRADDR_RAT{0}.OCCUPANT 23
STRADDR_RAT{0}.OCCUPANT{0}.ID 1
STRADDR_RAT{0}.OCCUPANT{0}.FAM_NAME “Smith”
STRADDR_RAT{0}.OCCUPANT{0}.NUM_RES 4
STRADDR_RAT{0}.OCCUPANT{0}.CLUST_ID 23
STRADDR_RAT{0}.OCCUPANT{1}.ID 2
STRADDR_RAT{0}.OCCUPANT{1}.FAM_NAME “Jones”
STRADDR_RAT{0}.OCCUPANT{1}.NUM_RES 2
STRADDR_RAT{0}.OCCUPANT{1}.CLUST_ID 23
STRADDR_RAT{0}.ID 6
STRADDR_RAT{0}.ADDRESS 2345
STRADDR_RAT{0}.HYDRANT “No”
STRADDR_RAT{0}.OCCUPANT 14
STRADDR_RAT{1}.OCCUPANT{0}.ID 3
STRADDR_RAT{1}.OCCUPANT{0}.FAM_NAME “Murray”
STRADDR_RAT{1}.OCCUPANT{0}.NUM_RES 2
STRADDR_RAT{1}.OCCUPANT{0}.CLUST_ID 14
Note: It is important to note that the author is not certain that the VPF standard allows databases to be structured in this way. However, the VPF reader interprets such structures and it provides a reasonable example to explain how related attribute tables are expressed in FME features. If the VPF standard calls for a flatter structure, this attribute naming scheme still applies.