The Australian Government coat of Arms

Communities of practice

Communities of practice

Aug 2018 Release of G-NAF and Administrative Boundaries - New Address Feature Table Added

g-naf

#1

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:

  1. ADDRESS_FEATURE_ID
  2. ADDRESS_FEATURE_PID
  3. ADDRESS_DETAIL_PID
  4. DATE_ADDRESS_DETAIL_CREATED
  5. DATE_ADDRESS_DETAIL_RETIRED
  6. 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).

For more information please take a look at PSMA’s blog post or for more detail, view their Slideshare presentation Tracking of changes to G-NAF (Aug 2018):


#2

August 2018 should also fix the following issues:

  • 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).