The upcoming August release of G-NAF has implemented changes to the Geocoded National Address File (G-NAF) structure to assist users in tracking address changes.

G-NAF users who track new addressable objects entered into the dataset (such as a property) have found this process challenging, due to the systemised allocation of IDs (ADDRESS_DETAIL_PID) which are unique to each address label rather than each object. This can result in:

changes to the address label (such as merge criteria) which aren’t representative of changes to the object (i.e. a new label is attached to an existing property)

the removal of new addresses, if a label is not supplied by contributors (-1 confidence) within a 12 month period.

For example, an address can change from a property lot number to a rural address with allocated street numbers.

Users will now find the identification and tracking of address changes much easier, with the introduction of a new Address Feature table which identifies the specific components changed within an address. Containing both principal and alias addresses, the table features six fields:

ADDRESS_FEATURE_ID

ADDRESS_FEATURE_PID

ADDRESS_DETAIL_PID

DATE_ADDRESS_DETAIL_CREATED

DATE_ADDRESS_DETAIL_RETIRED

ADDRESS_CHANGE_TYPE_CODE

The new table has the added feature of retaining retired addresses, in order to provide the full history of instances in which addresses have been retired. There is potential, in future updates, for this table to incorporate address changes to an addressable object (such as a property).

The script attempts to drop tables in the database. As a table creation script, these tables will not normally exist, so the script will error and fail on most platforms (unless the user edits it to remove the DROP statements). If the tables do exist, it would drop the tables and may unexpectedly delete data. (Note a fix could include removing the DROP statements or changing them to use the non-standard DROP IF EXISTS statement, depending on the platform. Note using DROP IF EXISTS may result in users unexpectedly losing data).

The table creation script includes redundant NULL constraints on primary key fields. PRIMARY KEY constraints require fields to satisfy UNIQUE and NOT NULL constraints, so adding NOT NULL constraints to primary key fields is not necessary. (Adding them just degrades the performance of INSERT operations).