This historic document provides information about the lineage of some Landonline cadastral data. The information is as published prior to the creation of Landonline.
Within VISION* the schema definition of a database refers to the format and organisation of the user attribute tables as well as the specification of any topological structures such as layers and networks.
The database schema used for DCDB allows us to organise our data in a logical manner which will help simplify and clarify data relationships, and facilitate the users understanding and analysis of the data.
The database schema provides the specification for layers, networks and the definition of feature codes and the user attributes associated with them.
3.1. Explanation of Schema
The DCDB schema consists of six data layers as outlined under List of User Defined Layers
These layers are used to group features, and networks, which are associated by the type of information they portray, for example, the Stats/Admin Layer only contains feature codes and networks related to statistical and administrative information.
Layers are the second level of the database structure with the map or database being the first level.
The layer structure can be used to assist the management of information in the database. For example, the Content Maintenance facility (cdm) enables various controls to be placed upon the use of information in the database at a layer level. Other programs like gina_out enable data processing to be restricted to selected layers of information.
Symbolisation of data within VISION* can also be controlled at a layer level.
List of User Defined Layers
|Layer Description:||Cadastral information||Land District|
|Statutory Restrictions||Statistical and|
|Comments||All cadastral boundary|
and Road Information
|-||To store a definition|
of Strata plans
of central government importance
|Meshblock boundary and|
|All Plan references|
and provisional plans
These are the next level of the structure below the layers and are further subdivision of the features, contained on a layer, into sub-groups. For example, the Cadastral Layer is divided into seven networks. Networks exist as outlined under List of User Defined Networks.
Each network enables the grouping of features which have some geometrical connectivity or geometrical relationships. Which features are physically connected to other features or which features are next to other features, is known as topology.
Networks may be of two types: Polygon or Linear.
Polygon networks are networks that topology can be created within. A polygon is a closed feature, for example, a parcel of land with topology formed. To form topology and hence create a polygon, a centroid identifier must be placed within the parcel's boundaries, then a relationship between the centroid identifier and the boundaries can be established (topology formation).
Linear networks are networks that only store line or point features which are not intended to form polygons. The lines within these networks may be inter-connected such as on the centrelines network or they may be randomly scattered such as private road boundaries on the private roads network. The relationship between networks and layers is shown in the following diagram.
List of User Defined Networks.
NOTE - The Statute layer (103) and Survey Maint network (1008) are not available for client supply.
3.2. Schema Features
The fundamental database spatial entity is called a feature. A feature has one or more coordinates, an optional graphic text string, optional graphic parameters, (text size and justification for example), system attributes, (feature code, layer and network number, length for example), and optional user defined attributes (appellation, plan number and street address for example). The feature code determines which symbolisation is to be used for a feature, and also determines which attribute table is used for the user defined attributes directly associated with the feature.
The DCDB schema uses three types of features namely: Polygon, Linear, and Point.
The list below shows the features defined in the schema, their type and definition:
|access_cl||road_cl||Linear||Centreline defining accessways|
|address||address||Point||Address feature (Road name and property number)|
|constituency||constituency||Polygon||Regional Constituency polygon centroid|
|constit_bdy||p_sufi||Linear||Boundary defining Regional Constituency derived from meshblocks.|
|easement_cl||covenant||Linear||Centreline defining easement in gross|
|emf||emf||Point||End point marker feature defining source of data|
|emf1008||emf||Point||Maintenance end point marker feature defining source of data - Not for client supply|
|general||general||Polygon||General Electorate polygon centroid|
|general_bdy||p_sufi||Linear||Boundary for General Electorate derived from meshblocks.|
|hyd_segment||hyd_segment||Polygon||Hydrographic polygon centroid|
|h_line||p_sufi||Linear||Line used to close off cadastral hydrographic features to ensure polygons are formed. eg. river confluence, river mouth.|
|land_dist||land_district||Polygon||Land district polygon centroid|
|ld_bdy||p_sufi||Linear||Land district polygon boundary|
|m_part_bdy||p_sufi||Linear||Parcel boundaries derived from unsurveyed Maori partitions.|
|maori||maori||Polygon||Maori Electorate polygon centroid.|
|maori_bdy||p_sufi||Linear||Boundary for Maori Electorate derived from meshblocks.|
|maint_bdy||p_sufi||Linear||Maintenance data - Not for client supply|
|mesh_bdy||p_sufi||Linear||Meshblock boundary feature code cloned from current cadastral boundaries or centrelines. This feature code is used in all client supply.|
|mesh_cad||p_sufi||Linear||Meshblock boundary following, or derived from, current cadastral boundaries.|
|mesh_topo||p_sufi||Linear||Meshblock boundary following, or derived from, current topographic features.|
|mesh_other||p_sufi||Linear||Meshblock boundary following, or derived from, features which are unknown, poorly defined or no longer current.|
|meshblock||meshblock||Polygon||Meshblock polygon centroid.|
|no_licence||no_licence||Polygon||Alcohol No Licence District Polygon centroid derived from meshblocks.|
|no_lic_bdy||p_sufi||Linear||Boundary for Alcohol No Licence District.|
|parcel||parcel||Polygon||Parcel polygon centroid|
|parcel02||parcel||Polygon||Maori partition parcel polygon centroid|
|parcel20||parcel||Polygon||Strata parcel polygon centroid|
|parcel32||parcel||Polygon||Proclamation parcel polygon centroid|
|parcel1008||parcel||Polygon||Maintenance parcel polygon centroid - Not for client supply|
|parcel_arc||p_sufi||Linear||Parcel Arc boundaries. Parcel boundaries which are also arcs.|
|parcel_arc02||p_sufi||Linear||Maori partition parcel Arc boundaries. Parcel boundaries which are also arcs. Cloned from parcel_arc|
|parcel_arc20||p_sufi||Linear||Strata parcel Arc boundaries. Parcel boundaries which are also arcs. May be cloned from parcel_arc|
|parcel_bdy||p_sufi||Linear||Parcel boundaries derived from survey plans.|
|parcel_bdy02||p_sufi||Linear||Maori partition parcel boundaries derived from survey plans. Cloned from parcel_bdy|
|parcel_bdy20||p_sufi||Linear||Strata parcel boundaries derived from survey plans. Maybe cloned from parcel_bdy|
|parcel_hyd||p_sufi||Linear||Surveyed stream/river/lake/coastline edges which are also legal parcel boundaries.|
|parcel_hyd02||p_sufi||Linear||Surveyed stream/river/lake/coastline edges which are also legal Maori partition parcel boundaries. Cloned from parcel_hyd|
|plan_prov||surv_plan||Point||Provisional plan feature|
|proc_bdy||p_sufi||Linear||Boundary defining proclamation|
|pte_road_cl||road_cl||Linear||Private road centreline.|
|pte_route_cl||road_cl||Linear||Private route centreline.|
|r_line||p_sufi||Linear||Boundary to close off road/rail polygons at intersections. Boundary does not coincide with cadastral bdy.|
|r_line20||p_sufi||Linear||Boundary to close off strata road/rail polygons at intersections. Boundary does not coincide with cadastral bdy.|
|r_legal_bdy||p_sufi||Linear||Road legality boundary - used internal to road/rail parcel.|
|r_legal_arc||p_sufi||Linear||Road legality arc boundary - used internal to road/rail parcel.|
|r_r_arc||p_sufi||Linear||Road/Railway Arc boundaries.|
|r_r_arc02||p_sufi||Linear||Maori partition Road/Railway Arc boundaries. Cloned from r_r_arc|
|r_r_arc20||p_sufi||Linear||Strata Road/Railway Arc boundaries. Maybe cloned from r_r_arc|
|r_r_bdy||p_sufi||Linear||Road/Railway boundaries. Road and/or Railway boundaries derived from survey plans.|
|r_r_bdy02||p_sufi||Linear||Maori partition Road/Railway boundaries. Road and/or Railway boundaries derived from survey plans. Cloned from r_r_bdy|
|r_r_bdy20||p_sufi||Linear||Strata Road/Railway boundaries. Road and/or Railway boundaries derived from survey plans. Maybe cloned from r_r_bdy|
|r_r_hyd||p_sufi||Linear||Surveyed stream/river/lake/coastline edges which are also legal road/rail boundaries.|
|r_r_hyd02||p_sufi||Linear||Surveyed stream/river/lake/coastline edges which are also legal maori partition road/rail boundaries. Cloned from parcel_hyd|
|rail_segment||railway||Polygon||Centroid feature used for rail polygon formation|
|rail_seg20||railway||Polygon||Strata centroid feature used for rail polygon formation|
|region||region||Polygon||Regional Council polygon centroid|
|region_bdy||p_sufi||Linear||Boundary for Regional Council derived from meshblocks.|
|road_legal||road_legal||Point||Road legality information|
|road_legal08||road_legal||Point||Maintenance road legality information - Not for client supply|
|road_segment||road_segment||Polygon||Centroid feature used for road polygon formation|
|road_seg20||road_segment||Polygon||Centroid feature used for road strata polygon formation|
|road_inter||road_inter||Polygon||Centroid feature used for road intersection polygon formation|
|road_inter20||road_inter||Polygon||Centroid feature used for strata road intersection polygon formation|
|ta||ta||Polygon||Territorial Authority centroid|
|ta_bdy||p_sufi||Linear||Boundary for Territorial Authority derived from meshblocks.|
|ward||ward||Polygon||Territorial Authority Ward centroid|
|ward_bdy||p_sufi||Linear||Boundary for Territorial Authority Ward derived from meshblocks.|
|walkway_cl||road_cl||Linear||Centreline defining walkways|
The relationship between the various features and the networks (or layers) is shown in the following diagram.
Cadastral Layer 100
NOTE - The Survey Maint network (1008) is not available for client supply.
District Layer 101
Strata Layer 102
Statute Layer 103
NOTE - The Proclamation network (1032) is not available for client supply.
Stats/Admin Layer 104
Plan Reference Layer 106
3.3.1. Primary Tables
The DCDB database schema has 21 user defined primary tables for storing attribute data. Attributes are stored within these tables via user attribute forms associated with certain feature codes, eg. the feature code "road_cl" (road centreline) has the table "road_cl" associated with it.
The user table definitions show the layout of these tables, what columns each table has, what type the column is, the maximum number of characters allowed in each column (size), whether or not a null value is permitted, whether there is an index on the column, if the column contains unique values and the range of feature codes associated with the table.
The emf, land_district and temp_query primary tables are not expanded on in the Data Characteristics manual as they are specific to Land Information NZ internal operations only.
3.3.2. Indirect Tables
Indirect tables contain information not directly associated with a database feature. There are two types of indirect tables - lookup and association. See Appendix 4
The lookup tables are used to resolve data redundancy issues. This means a field need only be entered once but can be accessed via multiple primary tables.
The association tables are used to resolve many to many relationships between primary tables.
There are 5 indirect (2 lookup and 3 association) tables defined within the DCDB database schema - they are:
- Attributes: sufi, created_date, modified_date, road_name, road_type, road_suffix, unofficial flag, asp_location
Description: This lookup table holds entries that would otherwise be replicated in the ADDRESS table, ROAD_CL table and ROAD_SEGMENT table. The only way road names can be entered into the DCDB is via a valid entry in the Authoritative Streets and Places (ASP) database. See Appendix 4.
- Attributes: road_lookup sufi and road_segment sufi.
Description: This association table resolves the many to many relationship between the ROAD_LOOKUP table and the ROAD_SEGMENT table. See Appendix 4.
- Attributes: road_lookup_sufi and road_cl_sufi.
Description: This association table resolves the many to many relationship between the ROAD_CL table and the ROAD_LOOKUP table. See Appendix 4.
- Attributes: address_sufi and parcel_sufi.
Description: This association table resolves the many to many relationship between the PARCEL table and the ADDRESS table to allow for multiple addresses. See Appendix 4.
- Attributes: sufi, created_date, modified_date, plan_type, plan_no, plan_suffix, datum, plan_description.
Description: This lookup table holds plan reference entries that would otherwise be replicated in the COVENANT table, PARCEL table and SURV_PLAN table. See Appendix 4.