Más contenido relacionado Similar a Tracking of changes to GNAF (Aug 2018) (7) Tracking of changes to GNAF (Aug 2018)2. © PSMA Australia Limited
Tracking of change to ADDRESS_DETAIL_PID in G-NAF
Background
• Each address in G-NAF has a unique ID - “ADDRESS_DETAIL_PID”.
• This ID is unique to each address label rather than an addressable object (e.g. a property).
• Currently in G-NAF, the address label representing an addressable object can change and still be
representing the same addressable object after the change (e.g. it represents the same property).
• The allocation of a new ADDRESS_DETAIL_PID in these circumstances is an issue for some users
seeking to track actual new addresses (i.e. representing new addressable objects) entering G-NAF.
3. © PSMA Australia Limited
Why would an address label to an existing addressable object change?
• The uniqueness of an address in G-NAF is determined by the 16 components which make up the
address label.
• Collectively these 16 components are referred to as the “merge criteria”.
• A change to any one of these 16 components will result in a different ADDRESS_DETAIL_PID being
allocated.
• The 16 components are:
state_abbreviation number_first_prefix flat_number_prefix
locality_name number_first * flat_number
primary_postcode number_first_suffix flat_number_suffix
street_name number_last_prefix level_number
street_type number_last
street_suffix number_last_suffix
* A lot number can be used in the
absence of a number_first
4. © PSMA Australia Limited
Why would an address label to an existing addressable object change?
The most likely reasons for a change to an address string allocated to an addressable object are:
• A name change to the locality the address falls within brought about by;
o A name change to the entire locality.
o The creation of a new locality containing the addresses.
o A change in a locality boundary.
o The movement of the address geocode across a locality boundary where a property extends across
multiple localities.
• A change in a street name, street type or street suffix associated with an address.
• The renumbering of addresses along a street.
• A change from the use of a lot number to a street number to identify a feature on a street.
• The removal of the superfluous level number in a “hotel style” address (e.g. 502/20 Level 5).
• The use of an alternative address label where a property abuts two streets (e.g. a corner property).
5. © PSMA Australia Limited
Identifying the changes in ADDRESS_DETAIL_PID
• The identification of a change is difficult as the address label itself is not always directly linked to a specific addressable object, nor is
there generally sufficient metadata to confirm the type of addressable object represented.
• Whilst several address contributors provide a link to a property or parcel, most contributors to G-NAF provide just the address label
and the G-NAF process indirectly links it to a property or parcel via matching routines and where available, the address geocode
provided.
• G-NAF does provide a link to a cadastral parcel (i.e. LEGAL_PARCEL_ID), however it is indirectly created through other state /
territory jurisdictional contributor datasets and whilst it is generally comprehensive, it has an incomplete coverage.
• The situation is further complicated as many addresses relate to a property rather than a parcel and as such the LEGAL_PARCEL_ID
may only represent one of the parcels an address relates to. In addition there may be multiple addresses within a property.
• In the absence of a specific addressable object, two approaches were investigated for use in identifying changes to an
address_detail_pid. These were:
1. Using the geocode associated with an address. As geocodes can move around a little the process it is currently planned to
allow a movement of up to 3 metres
2. Comparing the LEGAL_PARCEL_ID allocated to an address notwithstanding the shortcomings identified above.
6. © PSMA Australia Limited
Comparison of Results using the LEGAL_PARCEL_ID and address
geocode as the Addressable Object
• The comparison of the two different addressable objects (i.e. LEGAL_PARCEL_ID and address
geocode) shows that the use of the address geocode identifies the most candidates. This is
particularly so when a large change in locality names is involved as in the August 2017 release.
• Whilst the process using the address geocode as the addressable object identified the most
candidates, it missed some identified by the LEGAL_PARCEL_ID approach.
• The actual implementation beyond this review phase will need to use both the address geocode and
the LEGAL_PARCEL_ID as the addressable object if the maximum number of changed
ADDRESS_DETAIL_PIDs are to be identified.
7. © PSMA Australia Limited
Address changes that WILL NOT be identified in this G-NAF
process change
The major objective of this enhancement is to identify instances where an address is retired and replaced
with a new address within the same update, representing the same addressable object.
As such, the enhancement to G-NAF will NOT identify the following instances where;
• A new address is created on the same geocode as an existing address and the pre-existing address is
retired in a subsequent update.
• One of two existing addresses at a site is retired. Occurs when one of the two addresses at the site has
been recognised by the contributor as an alias of the other address and has been retired. This
relationship had not previously been recognised by G-NAF (ie there is no replacement address
involved).
• The geocode of an existing address is moved and a new address is placed on or near the original
geocode. There was no retirement of the address it was simply moved to another property.
Whilst not all scenarios will be covered initially, as new modes of confidently detecting changes across
releases are developed, the approach used will be expanded to cover additional addresses.
8. © PSMA Australia Limited
Implementation in G-NAF
To allow instances where the address label of an addressable object has changed to be identified following an update of
G-NAF, a new table has been created in G-NAF for August 2018 release containing 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
• This table would include both principal and alias addresses as the locality name of alias addresses in G-NAF also
changes when a locality name change occurs.
• Where an address is identified as being replaced, a new address feature identifier would be allocated and linked to
both the new and retired ADDRESS_DETAIL_PID. Respective created dates and retired dates would be populated.
• This table would allow users to identify addresses that had been simply updated by a change to one or more of the
address components and to identify the address component that had changed (e.g. locality name, street name etc).
• The implementation of the new table would also bring about the retention of retired addresses in G-NAF in order to
provide the full history of instances where addresses have been retired in this manner.
9. © PSMA Australia Limited
G-NAF Data Model Change
The data model from August 2018 release includes two additional tables called ADDRESS_FEATURE
and ADDRESS_CHANGE_TYPE_AUT as shown below
10. © PSMA Australia Limited
New Tables in G-NAF
The two new tables in August 2018 release are as follows:
ADDRESS_FEATURE
ADDRESS_CHANGE_TYPE_AUT
Note: The codes are not listed due to the large number of change types. Please look at the tables within the data.
Name Data Type Description Prim
Key
Man F K TABLE F K Col
ADDRESS_FEATURE_ID varchar2(16) The Identifier is unique to the record within the table.
The ID is prefixed with the state or territory
abbreviation (e.g. NSW123456).
Y Y - -
ADDRESS_FEATURE_PID varchar2(16) The Persistent Identifier is the unique identifier for the
addressable object this record represents. The PID
allows for tracking change to the
ADDRESS_DETAIL_PID associated with an
addressable object over time. The PID is prefixed
with AF and the state or territory abbreviation
(e.g. AFNSW123456).
N Y - -
ADDRESS_DETAIL_PID varchar2(15) The Persistent Identifier that is unique to the real
world feature this record represents.
Y Y ADDRESS_DETAIL ADDRESS_DETAIL_PID
DATE_ADDRESS_DETAIL_CREATE
D
Date Date the address (ADDRESS_DETAIL) record was
created.
N Y - -
DATE_ADDRESS_DETAIL_RETIRED Date Date the address (ADDRESS_DETAIL) record was
retired.
N N - -
ADDRESS_CHANGE_TYPE_CODE varchar(50) The code indicating the type of change (e.g.
LOC-STN for locality name and street name change).
N N ADDRESS_CHAN
GE_TYPE_AUT
CODE
Name Data Type Description Prim Key Man F K TABLE F K Col
CODE varchar(50) An abbreviated name of the type of change. Field length: up to
fifty characters. This is the persistent identifier.
Y Y - -
NAME varchar2(100) Name of the address change type code. N Y - -
DESCRIPTION varchar2(500) Description of address change type code. N N - -
11. © PSMA Australia Limited
Summary
• The updating of an address label identifying an addressable object (e.g. a property) will cause a change in
the ADDRESS_DETAIL_PID if any of the components in the address string occurs.
• This happens to some addresses in every update, and based on the August 17 and November 17 updates,
can range from 3,000 to 15,000 addresses.
• It is possible to track these changes, if a new table is added to G-NAF and the changes are identified as part
of each update.
• The fact that addresses are not directly linked to known addressable objects poses some challenges in
identifying with a high degree of certainty that an actual change has occurred.
• To provide some degree of certainty that an update of the address label has occurred, the tracking will be
limited to those instances where the retirement of an address and addition of a new address with the same
geocode and / or legal parcel id occurs within the same update.
• If the history of these updates is to be preserved as G-NAF goes forward, the current approach of retiring
-1 addresses (i.e. retired) after four updates would need to cease (i.e. all addresses would remain in G-NAF).
• Changes will be occurring for August 2018 release with information supplied in release notes.