Color: [0, 0, 0, 255] Background Color: N/A Outline Color: N/A Vertical Alignment: bottom Horizontal Alignment: center Right to Left: false Angle: 0 XOffset: 0 YOffset: 0 Size: 8 Font Family: Arial Font Style: normal Font Weight: normal Font Decoration: none
Description: This is the equivalent of the DCDB Survey network. It is all the "current" "primary" polygon parcels derived from the PAR1.CRS table rings, not LIN1.CRS lines .
Polygons have all codes from PAR1.CRS plus some joined from other tables and one Corax reclassification item featcode .
The APP.DAT table (appellation) has the parcel Lot/DP description and some other useful flags to indicate if there is a survey record and a title reference. Not all parcels have these, eg roads and water features. There could also be more than one appellation for a parcel.
If you are loading the parcel layer into a geodatabase, note that the PAR_ID which is unique in the CRS (SUE) Static Unique Entity, is not for cleaned parcels because multipart parcels have been split into the separate components. This has huge benefits for performance and simplicity. There are 12,000 multipart parcels in the 2 million parcels, eg some island groups and other exceptions.
Extra items
SUFI is joined from DCDBMap to parcel for backward links to valuation matches. For this purpose the PAR_ID can replace the SUFI key in most cases. There could be valuation splits within a multi-polygon parcel by polygon where this would not be accurate.
FEATCODE is a Corax addition as a reclassification of PARCEL_INTENT . This simplifies 80 codes down to 6 codes. Generally road and hydro polygons do not have an appellation, but if they do they will have a parcel tag. There is no way to automatically classify these areas as water, commonly in harbours. Feature name and title purpose can help, but not for Lake Taupo.