This historic document provides information about the lineage of some Landonline cadastral data. The information is as published prior to the creation of Landonline.
It is essential that users have an appreciation of the quality of data when considering various uses. There are several quality aspects which users need to know in order to properly assess whether data is suitable for their application. The aspects are: lineage, standards, positional accuracy, attribute accuracy, completeness, timeliness and logical consistency. This section provides information on these quality aspects as related to the DCDB.
Lineage relates to an appreciation of data sources and how data has been derived from those sources to populate a database.
2.1.1. Cadastral Spatial Component
The DCDB's spatial component has been populated primarily by hand digitising from the department's existing large scale cadastral record maps. The scales of these maps range from 1:396 (50 links to an inch) to 1:50,000 with scales of 1:792, 1:1000, 1:1584 and 1:2000 predominant in urban areas and scales of 1:7920 and 1:10,000 predominant in rural areas.
This spatial capture approach was influenced by the need to provide a reasonably accurate database in a limited time frame to meet the spatial needs of Land Information NZ and its clients. Research undertaken in Land Information NZ and backed by overseas studies has shown that the more accurate numerical methods of input are considerably slower than hand digitising. The increase in capture time is not attributed to the input of data, but is due to the necessity to research survey data from survey plans and traverse sheets and the tabulation and checking of that data prior to input. However, this approach has not precluded numerical methods of input in specific areas where a higher degree of positional accuracy has been required. Refer also 220.127.116.11..
Cadastral record maps portray land parcels, the smallest land unit, that has been subdivided primarily from subdivisional plans and for which title may issue. Their focus is on legal "cadastral" land parcels, their identification, and the geographical position of their boundaries relative to a coordinate system. The land parcels may be all of the land in one ownership or title, or may be less than a property or title. The view of land parcels recorded on cadastral record maps and represented within the DCDB is the view defined on approved survey plans and may differ from the view represented from title or valuation sources.
The focus of land parcels under the "title" system is on the ownership, the legal land description and the constraints against the land. Under the titles system, land parcels may be aggregated to form properties, may have been subdivided by "diagram on transfer" and not recorded on Land Information NZ's cadastral record maps, or title for subdivided land parcels not issued. The situation is further complicated by customary Maori land where the Maori Land Court may have subdivided the land by a court partition and a survey of subdivision has never been completed.
The valuer's view of land parcels focus on property values, improvements and actual and permitted use. In determining what is a land parcel to be valued, the valuer may include all contiguous land in one ownership, or separately value an ownership where the land is not contiguous or has a separate use. The land parcel definition may therefore differ from the "cadastre", "title" and "valuation" land parcel definitions as illustrated below.
The DCDB may differ -
- from a titles database in that diagram on transfer subdivisions may not be shown, parcels are aggregated in the issue of titles, non standard appellations are often used in the title description and timeliness of action may cause differences
- from a Maori land database in that unsurveyed Maori partitions are generally not shown and that database may not use the same form of appellation
- from the Valuation NZ database in that this database is based on an aggregation of land parcels into land holdings, contains unregistered miscellaneous leases, and appellation may be non standard.
18.104.22.168. Imperial Record Maps
Imperial scale record maps were drawn in colour on holland backed hot press or cartridge drawing paper. This media is reasonably stable although some dimensional distortion may be evident. The media is subject to deterioration through mishandling resulting in creases around the edges. The coordinate system used was predominantly old cadastral datum (OCD), that is a plane datum based on a local or initial meridional trigonometrical station without projection corrections applied. The accuracy of imperial cadastral record maps was determined by three major factors:
- Draughting error by using erroneous OCD coordinates or Geodetic coordinates without a correction being applied and poor recording by 'fudging' of data to fit existing work;
- Non linear sheet dimensional distortions;
- General sheet deterioration.
22.214.171.124. Metric Record Maps
From 1975 record maps were produced to metric scales on Herculene polyester drawing media. These were printed via rotary or flatbed printing onto diazo foil as "working copies". It is this working copy, maintained on a daily basis, that was used for DCDB population. Metric record maps were drawn on the New Zealand Map Grid (NZMG) projection using coordinate transformations from Geodetic Datum 1949.
The accuracy of the metric cadastral record maps was also determined by three major factors:
- The method of compilation whereby errors evident in the imperial sheets were perpetuated by reducing these sheets and tracing the data.
- It is known that a number of these maps, purported to be in terms of NZMG, had not been corrected to Geodetic datum. In effect the NZMG sheet edge and meridional circuit grid are in their correct position relative to one another but the parcel information is in terms of OCD.
- Dimensional distortions in the "working copy" intermediates, from which the DCDB was digitised, due to production by rotary diazo copiers.
126.96.36.199. Survey Plans
Some capture was undertaken from the original survey plan of subdivision. This occurred where the subdivision was extensive, contained large amounts of natural (water) boundaries or where the existing record map accuracy was suspect.
188.8.131.52. Numeric Entry
Some capture was undertaken by numeric entry of survey coordinates and bearings and distances. This method of capture was used where existing record maps were known to be inaccurate, where survey coordinate anomalies were known to exist, or where a higher positional accuracy was required by clients for integration with other datasets derived from a higher precision source such as large scale topographical data or orthophotography.
Generally new maintenance data are entered by numeric entry or use survey coordinates to control position.
2.1.2. Meshblock Component
A meshblock is defined as being the smallest geographical unit for which statistical data is collected, stored and processed by Statistics New Zealand. Land Information NZ, under an agreement with Statistics New Zealand is responsible for managing the geographical definition of meshblocks. Meshblock boundaries are aligned to the cadastral data with that relationship continuously maintained.
2.1.3. Lineage Indicator
In order to interrogate the lineage of points stored within the database, codes describing data source and capture date are assigned to attribute nodes (EMF's) as shown in the table below.
|Source Code||Document Scale||Source Code||Document Scale|
|1||(Geodetic Datum Survey)||2||(Old Cadastral Datum Survey)|
|3||(Digitised 0-500)||8||(Digitised 2001-5000)|
|4||(Digitised 501-792)||9||(Digitised 5001-7920)|
|5||(Digitised 793-1000)||10||(Digitised 7921-10000)|
|6||(Digitised 1001-1584)||11||(Digitised 10001-25000)|
|7||(Digitised 1585-2000)||12||(Digitised 25001-50000)|
2.1.4. Attribute Component
Attributes within the DCDB are derived from a number of sources.
Parcel attributes are predominantly interpreted from the cadastral record maps. The exception is street address and the unique meshblock identifier which were originally sourced from Electoral Record Maps (ERM) used to support our involvement in the Electoral process. The Electoral Record Maps recorded a house number where allocated and a street name as listed in the Authoritative Streets and Places (ASP) database. This database is defined as being an authoritative listing of street and place names for New Zealand with respect to their location within a local authority, general or Maori electoral district and, where appropriate, no-licence district. Street address data is now continually updated through advice from Territorial Authorities, whose responsibility it is under the Local Government Act to maintain such records and to advise LINZ of such changes.
Road names are entered in terms of the Authoritative Streets and Places (ASP) database.
Railway names are as gazetted on 13 August 1996.
A number of standards are used in the compilation and maintenance of the DCDB. These include:
"old LINZ" standard for:
- Geographic Reference
- Land Appellation
- Area Measurement
- Street Address
- Local Government Names
2.2.1. Geographic Reference
The standard adopted for geographic or positional information in the DCDB is the "old LINZ" standard for geographical reference and is defined as follows:
- Geographical Reference
- The coordinate system for geographic reference of horizontal positions is New Zealand Map Grid (NZMG) coordinates. (Based on the NZMG Projection, a minimum error conformal projection with a scale variation not exceeding 0.024% with coordinates based on the International (Hayford) Spheroid. The true origin is at latitude 41 S and longitude 173 E with coordinates 2 510 000 metres east and 6 023 150 metres north.)
- Coordinates will be expressed in metres.
- NZMG coordinates (x and y) of a point will be expressed using the convention whereby the easting (abscissa or x-axis) is shown first followed by the northing (ordinate or y-axis).
- Computer Record Format
- In all cases NZMG coordinates will contain seven digits before the decimal point, with provision for up to three digits following the decimal point, for both ordinate and abscissa.
2.2.2. Land Appellation
Appellation for land parcels are entered into the DCDB in terms of the "old LINZ" standard for existing land parcel appellation and simplified appellation format for new parcels created from 1 June 1987.
To quote from the "old LINZ" Standard for Land Appellation.
"Land appellation can generally be defined as the textual reference used to identify a defined parcel of land which has a legal entity. A great variety of appellations were generated during the provincial period of land administration in New Zealand. The standardisation requirements for matching computer files for a national Land Information System, has now provided the much needed opportunity to both rationalise and simplify the proliferation and variation of current land appellation formats. The appellation of each parcel of land (the smallest land units covering the whole country) will provide the common key essential for matching the land data files of each department, and ultimately their linkage to form the 'core' LIS. Maintenance procedures will be implanted in this system to ensure that the individual records in the respective files are kept in agreement, and that these files are maintained with a high integrity.
Standardisation of existing land appellation comprises the first part of the LINZ standard for Land Appellation. As well as standardising the appellation identifying each parcel of land in the computer records of each sub-system, introduction of this standard will also reduce the number of different appellation formats from more than 14,000 to less than 8,000.
The Land Appellation Database (LAD) is the LINZ STANDARD for existing land parcel appellation in respect of Land District Code; Registration District or Survey District or Maori Block name; parcel type ; and format. It is a national listing of all these appellations including those which have been superseded or are defunct.
The simplified appellation system for new parcels created from 1 June 1987, is based on the principle that all land parcels defined on a survey plan are uniquely identified by referencing them to the plan number. Modern Land Transfer plans have appellation expressed in this simplified form, which provides a unique reference and also gives a direct link to the plan creating the new parcel. It is a logical step to adopt this principle for new Crown and Maori land appellations. By retaining the prefixes identifying the three plan systems currently in use this will allow for future conversion of existing records to this system, and provides a useful indication of the purpose for creating the parcel(s) and subsequent administrative procedures.
The need for historical reference through preceding appellation(s) is no longer considered necessary. Once simplified appellation has been established, the link to historical appellation will be provided through the underlying survey plan."
2.2.3. Area Measurement
The "old LINZ" standard for area measurement is defined as follows:
Format for data transfer:
Units : square metres (m2)
Format type : 32 bit integer
Resolution : 1 square metre
1 acre = 4046.856 4224 square metres (Imperial to Metric (SI units))
1 hectare (ha) = 10,000 square metres
Format on printed reports and screens:
Areas less than 10,000 square metres will be displayed as square metres and suffixed with 'm2' (eg. 630m2):
Areas equal to or greater than 10,000 square metres will be displayed in hectares with four figures after the decimal point and suffixed with 'ha' (eg. 1.2300 ha).
The storage and standard output of area from the DCDB are at variance with this "old LINZ" standard. Areas are stored as hectares and decimals of a hectare. Data can be reported in terms of the "old LINZ" standard if required.
2.2.4. Street Address
There have been a number of attempts to establish a standard for street address. These are the "old LINZ" standard for Street Address, the RAPID (Rural Address Property IDentification) system and more recently the Draft Australasian/New Zealand Standard for Rural Street Addressing. None of these standards have been adopted nationally by Local Authorities.
The "old LINZ" standard provides recommended conventions and procedures for floor identification, building/property name, street/unit numbering and street name, type and suffix. However, building and property names are not recorded in the DCDB as we have no means of maintaining these data.
Street address information is recorded in the DCDB to conform with the standards adopted by individual local authorities. Section 319 A and B of the Local Government Act 1974 require Local Authorities to advise LINZ of the naming of roads and allocation of property numbers.
Street names conform to the national Authoritative Streets and Places (ASP) database compiled for Electoral purposes.
2.2.5. Local Government Names
A standard code for each regional and local government agency, and each ward has been adopted.
These codes are the same as those used in Statistics New Zealand's, New Zealand Geostatistical System (NZGSS), and Land Information NZ's Authoritative Streets and Places database. They have been placed in an indirect table to support outputs from the Statistical Layer for Digital Meshblocks.
2.3. Positional Accuracy
All aspects of spatial data are subject to positional errors as a direct result of the capture methods used. The accuracy standard for the DCDB was the "old LINZ" Standard for Geographical Accuracy, that is
"For the great majority of points, digitised coordinates must be accurate, relative to numeric survey coordinates, to within +/- 1mm multiplied by the representative fraction of the capture map scale."
The Surveyor General's DCDB Data Accuracy Specifications (Interim), established in September 1997, specify the following standard for positional accuracy of parcels, roads, railways and hydrographic areas as follows;
|95% of all coordinates shall not differ from their true position, relative to the survey control framework, by more than the following:|
|Areas||Pegged Survey Points||Points not Pegged #|
# excludes points on irregular boundaries
The geographical extent of individual urban, rural and remote areas will be defined by the Surrveyor General.
It is recognised that population by digitisation perpetuated all the existing errors in the manually produced cadastral record maps and may contribute more of their own. The department has, however, endeavoured to minimise errors when preparing data for capture and during data capture to ensure that the positional accuracy of the DCDB is at least as accurate as the existing cadastral record maps from which most of the DCDB is derived.
For the positional accuracy of specific areas please refer to the district office responsible for capture. They can investigate the lineage, and from local knowledge, indicate the positional accuracy that can be expected in any given area.
Positional accuracy of NZMG coordinates is determined by the influence of a number of error sources:
2.3.1. Coordinate Error
The NZMG has been adopted for geographical referencing. The final accuracy and integrity of the NZMG coordinate base is directly dependent upon the coverage of the geodetic control system and the use to which that control has been put in the local cadastral system. NZMG coordinates are derived mathematically from the meridional circuit coordinates during data capture.
There is no mathematical relationship between Old Cadastral Datum (OCD) coordinates and Geodetic Meridional Circuit coordinates. As part of data preparation District Offices of the Department have compiled tables of coordinate differences between the two coordinate systems. These are used to linearly adjust coordinates captured from imperial record sheets referenced to OCD. Refer also Section 2.4.3.
2.3.2. Graphic Error
Graphical errors affecting the accuracy of NZMG coordinates within the DCDB include plotting errors, non-linear sheet dimensional distortions, general sheet deterioration and digitising errors. However, the major factor affecting positional accuracy is the scale at which the original record map was drawn and the compilation (draughting) methods used.
The lineage or source code of each attribute node provides an indication of the reliability of coordinates stored within the database. The table below indicates the accuracies that may be expected in terms of the "old LINZ" Standard for Geographical Accuracy based on the source code of the attribute node at that point.
|Code||Expected Accuracy||Code||Expected Accuracy|
2.4. Positional Accuracy Improvement
2.4.1. Data Preparation
Very early in the DCDB development stages the need to upgrade the department's graphical records was identified. For two years prior to data capture considerable staff resources were committed and every effort made to eliminate, as far as possible, potential sources of error. The following data preparation tasks were instigated.
2.4.2. Graphical Improvement
- Investigation of the datum used for the plotting of all existing record maps to determine if OCD or Geodetic Datum was used and noted to avoid future confusion.
- Existing record maps were examined to determine suitability for digital data capture. Sheets that were known to be grossly inaccurate, poorly draughted or deteriorating, to the extent that data was lost or distorted, were identified and corrected prior to capture by replotting.
- Areas where the scale of existing record maps was considered inadequate, particularly semi urban areas, were replotted.
2.4.3. Coordinate Improvement
No mathematical transformation exists between OCD coordinates and NZMG. NZMG coordinates can only be derived from meridional circuit coordinates which are in terms of Geodetic Datum 1949. It was therefore critically important that the relationship between OCD meridional circuit coordinates and Geodetic meridional circuit coordinates were established as accurately as possible.
During data preparation, some 25,000 coordinate correction factors were established and entered into a OCD/Geodetic Datum Spot Difference Table. When conversion from OCD to Geodetic datum was required on any given digitised or numerically entered coordinate the corrections in the vicinity were extracted by the system and a factor calculated for the point in question.
This procedure reliably and consistently converted OCD drawings and coordinates to Geodetic Datum prior to transformation to NZMG during data capture and data maintenance.
2.4.4. Data Capture
In most cases the NZMG neat edge or meridional circuit grid as shown on existing record maps was used to control set up during data capture and to control graphical positioning within the database. However, coordinates may have been used where the record map was known to contain inaccuracies, where roadside data had been numerically entered to satisfy additional accuracy requirements or where sufficient control points had been entered into the area through database maintenances.
Linear map dimensional distortions were eliminated during digitising registration. Coordinates for all control points were entered, digitised, and residuals between the entered coordinates and digitised coordinates displayed. From these residuals the operator detected any registration error caused by either poor digitising, map sheet distortions, or errors in the control point coordinates. Once the residuals were accepted an "affine" adjustment was selected to spread inaccuracies caused by dimensional distortions inherent in the existing drawings throughout the map sheet, thus effecting a "pro-rata" adjustment.
184.108.40.206. Coordinate Control
Geodetic coordinates for prominent points such as road intersections were often searched and used to control digitising registration. Up to eighteen control points can be used and an affine transformation used to adjust the existing definition to this accurate control.
220.127.116.11. Numeric Entry
Greater positional accuracy can be provided by controlling and supplementing digitising with numerical methods of input. These methods were used in areas where existing record maps were known to be inaccurate, where survey coordinate anomalies were known to exist, or where a higher positional accuracy was required for integration with other datasets sourced from data with a higher precision, such as large scale topographic data or orthophotography.
For example, full numeric entry of roadside definitions to upgrade the road fabric definition has been used in many instances. This definition was then used to control and adjust internal parcel definition.
2.4.5. DCDB Maintenance
An important feature of the DCDB is that continuous data maintenance (updating) procedures were incorporated from the beginning of data capture to maintain the database in terms of new subdivisional plans and proclamation actions received daily in each Region or Branch office. Boundary and other changes were entered as they occur by using coordinate entry techniques.
Maintenance not only maintains the timeliness and integrity of the database but can also progressively upgrade the spatial geographic accuracy to higher standards. This data has been used to supplement coordinate controls identified above and has been used to systematically upgrade database accuracy.
2.4.6. Parcel Adjustment
A process of parcel adjustment has been used during the maintenance process to improve the spatial accuracy of data initially digitised into the database from the hard copy record maps.
Where numeric entry of maintenance data has been used, misfits will occur with existing data of a lesser accuracy. Where the difference is small, only the points adjacent to the survey are upgraded. However, where the difference is substantial, adjustment has generally been applied to the adjoining region to enable the distortions to be spread throughout the immediate vicinity and not show as obvious discontinuity's in roadside angles and offsets or overlaps/gaps between cadastral boundaries.
Algorithms have been developed to provide the means by which positional integrity can be improved over time as maintenance data is added. Specifically the parcel adjustment process comprises the following steps:
- Attribute nodes within the maintenance and existing cadastral networks defining common features are paired.
- Those pairings considered to be best representing any systematic coordinate differences within the maintenance region are included as observations for a linear transformation. The observations are weighted depending on the source code of the resident database attribute node.
- The included paired control points are then transformed.
- Coordinates of points other than the paired control points are adjusted. Their lineage, source code, the distance from control points, and the proximity of other points with more accurate source codes are all considered by the adjustment algorithm.
As the database has been updated over the years with new survey information, the amount of movement in neighbouring coordinates has diminished to the point where minimal or even negative improvement has occurred in many parts of the database.
With the approval of the Survey and Titles Automation Project in 1996 and the inclusion in that project of the creation of a survey accurate digital cadastre, the continued spatial improvement of the DCDB has been discontinued. In general, a policy of fitting new subdivision into the existing DCDB spatial fabric has been adopted.
2.5. Attribute Accuracy
During data capture verification procedures were used to ensure that data had been interpreted and entered correctly from the record maps into the various attribute tables. For each source record map captured, a verification check plot and parcel attribute listing report was produced and checked against the source document for correctness and completeness.
The verification plot contained attribute data entered into road and railway attribute tables. These were checked to ensure that spelling was correct in terms of the Authoritative Streets and Places (ASP) database, that the full road type was shown, and that uppercase lettering had been used. The names were checked for readability, ie. that they have not been placed upside down.
The plot also contained a parcel ID which corresponded to values listed in a Parcel Attributes Report. This was checked against the source documents to ensure the correct attribute data was entered for each parcel. This included ensuring that:
- The "old LINZ" simplified/standard appellation format types were adhered to when inputting data into the appellation and registration fields.
- The correct plan reference was interpreted. If in doubt the plan aperture cards were examined.
- Areas and area source codes had been interpreted and entered correctly.
- Street address 1and road names had been entered correctly in terms of Electoral Record Maps used to support the Electoral system and the Authoritative Streets and Places database.
- Certificate of Title or document references had been entered in the document field for diagram on transfer subdivisions, or to assist with uniqueness where appellation and area are the same.
- Data was edited on completion of validation checks and prior to posting into the GIS database.
The above procedures do not ensure that errors or differences between datasets obtained from other sources will not occur. Comments under Section 2.1 - Lineage, indicated for example that differences may occur between the DCDB and title and valuation records.
In 1997 processes were put in place to check, standardise and improve the accuracy of attribute data in the database. These checks are being consistently applied to the database resulting in significant ongoing improvements.
A verification plot of the captured area was checked against the source record map to ensure that all features had been digitised correctly and that correct feature codes had been assigned to each spatial feature. This check also ensured that the road and railway centreline network was complete, that centroids had been placed and attribute data entered for all land parcels and that sheet edge joins had been captured correctly.
Building polygon and linear topology also ensures completeness of spatial data.
DCDB spatial and attribute data are maintained on a daily basis in terms of newly approved and deposited survey plans, changes to street names and street address as advised by Territorial Authorities, changes to the status of land as advertised in the NZ Gazette and changes to appellation and area resulting from proclamation actions as advertised in the NZ Gazette. Changes should, in most cases, be effected within five working days of the amending action taking affect.
2.8. Logical Consistency
Logical consistency of data is ensured through a two step polygon topology generation process:
- Parcelisation creates topologically correct network structures by splitting lines at every line intersection, generating a system node at every intersection and correcting overshot or undershot digitised lines.
- Polygon Formation where topological relationships between boundary segments and centroids are formed.
Several factors must apply before topology can be created.
- Each defined polygon must contain a centroid.
- A system node must exist at the intersection point of two or more line features in the same network, ie. parcelisation completed.
- All boundary line features of a polygon and the centroid must be defined as being in the same network. The boundary line feature must connect end to end, such that no 'holes' exist in the polygon boundary.
- Two line features cannot leave or enter a system node exactly at the same angle, ie. there can be no duplicate features.
Errors in topological structuring are reported and the process is cycled through until a clean topological structure is generated ensuring logical consistency of data.
Linear topology is formed for all road centreline networks.
Note: Land Information NZ does not warrant that full topology can be formed on the data but will use its best endeavours to achieve this if the client needs it.
Topological information may not necessarily transfer between systems during data conversion. However, by maintaining topology within the DCDB, formation of topology on other systems with this facility may be achieved with little further work.