Section 3 - National Topographic Database Production Information

1. Scope of this document

This document:

• defines the structure and structural rules of Geoscience Australia's TOPO250K and TOPO100K NTDBs
• lists the information that will be supplied for the production and maintenance of the NTDBs
• discusses cartographic principles which must be taken into account when producing or maintaining the NTDBs to allow easy production of the main output of the databases (1:250 000 and 1:100 000 National Topographic Map Series)
• lists the documentation and material that will accompany the revised data and/or map on submission to Geoscience Australia

The methodology process for both the updating and revision of the individual NTDBs may vary in the future, at the discretion of Geoscience Australia.

2. General Information

The TOPO250K and TOPO100K NTDBs are managed by the Oracle Relational Database Management System (RDBMS) and ESRI's ArcSDE software, and contain the relevant data tables and indexes.

These NTDBs:

• are used for the revision and maintenance of topographic mapping data at 1:250 000 and 1:100 000 scales. (Note: it is expected that Geoscience Australia will cease generating the TOPO250K and TOPO100K GEODATA Vector products during 2005)
• are used to revise and generate the National Topographic Map Series (NTMS) maps and associated customised mapping products
• must comply with the standards and rules set out in Sections 1, 2 and 3 of this specification and in the Appendices. The only exception is when a project instruction is issued specifically allowing a variation.

The appendices to this specification include important descriptive information for the databases. In particular, appendices A and H should be referred to obtain a full understanding of the NTDBs. Appendix A is the feature type dictionary. Appendix H lists the range of paper sizes and geographic limits for adjusted (ie. non-standard) map extents.

[back to top]

3. Revision

3.1 Revision sources

Information sources to allow revision of the features in the NTDBs may be supplied by Geoscience Australia. With the introduction of the NTDB models, it is expected that whenever possible the revision information will be supplied on a "change only" basis ie. Following initial NMD database review, those features subject to inclusion, change or deletion will be identified and will constitute the revision information supplied. Where this approach is not deemed to be either possible or practical, due to such factors as the quantum amount of change or complexity of errors, an overall "thematic" review etc may be requested of the producer. In this instance, appropriate reference information sources to allow revision of the features in the NTDBs will be supplied by Geoscience Australia, and these sources should suffice. Where producers have access to other information sources, they may be used; however, approval must be obtained from Geoscience Australia before use. All changed features visible on the imagery or contained in the other supplied information sources and meeting the criteria established in the feature type dictionary (see Appendix A) will be captured in the databases.

Guidance on resolving conflict between sources is given in Section 3 Chapter 5.5 Priorities in Use of References, Map and Imagery. Where there is an unresolvable problem it should be referred to Geoscience Australia. Where use of the source material creates an anomaly it should also be referred to Geoscience Australia. see Section 3 Chapter 3.4 Communication with Geoscience Australia in relation to data and map production

In instances where instructions are contained in Special Project Instructions or Action Requests issued by Geoscience Australia that take precedence over the Specifications, the Producer should provide a Production Note that references the source (i.e. Special Instruction or Action Request etc) and the subsequent change. These Production Notes should be populated in the ProductionNotePoints FeatureType in the Production Feature Dataset. see Section 3 Chapter 3.4 Communication with Geoscience Australia in relation to data and map production and Appendix A Production Note

3.2 Source Material and Information Supplied by Geoscience Australia

3.2.1 Documentation

3.2.2 Existing mapping

3.2.3 Satellite imagery

3.2.4 Revision data

NMD revision database clips will only be supplied where whole of theme review is required.

Refer to the publication, Documentation for National Mapping Division Databases and individual Project Instructions for up-to-date information regarding revision data clip description and supply.

3.2.5 Map marginalia information

[back to top]

3.3 Scanning Transformation Error Report

The scanning transformation RMS error report will give the difference between known control points and their scanned locations for each piece of material scanned. Points will not be accepted with a difference greater than plus or minus 50 metres at 1:250 000 and plus or minus 20 metres at 1:100 000.

A sample report follows. The report layout may vary but area and coverage information, identification of the control points used, individual residual errors and RMS must be included. Producers will be required to supply a scanning transformation RMS error report for each repromat or equivalent hardcopy information scanned for raster to vector conversion.

  AFFINE Transformation Report Mon Dec 23 11:47:19 1996

  ********************************************************

  Units quoted are in MASTER UNITS unless specified.

  Datafile : C:\SUSIE\BETOOHYD.DGN Masterfile : C:\SUSIE\BETOOHYM.DGN

  ID Master Control Monuments (x,y) Data Transformed Monuments (x,y)

  --------------------------------------------------------------------------------------------

  1 [ 349872.300000 , 7123444.600000 ] [ 349873.929659 , 7123428.288025 ]

  2 [ 349242.300000 , 7178826.600000 ] [ 349237.220023 , 7178833.546668 ]

  3 [ 348623.700000 , 7234205.100000 ] [ 348626.543897 , 7234209.506276 ]

  4 [ 399086.600000 , 7234670.500000 ] [ 399094.244822 , 7234674.842476 ]

  5 [ 449544.500000 , 7234949.600000 ] [ 449550.005428 , 7234942.321504 ]

  6 [ 500000.000000 , 7235042.700000 ] [ 499992.392353 , 7235023.575531 ]

  7 [ 500000.000000 , 7179676.300000 ] [ 499998.063041 , 7179687.991801 ]

  8 [ 500000.000000 , 7124306.200000 ] [ 500002.834445 , 7124315.153958 ]

  9 [ 449960.600000 , 7124210.500000 ] [ 449969.185596 , 7124205.623738 ]

  10 [ 399918.800000 , 7123923.300000 ] [ 399914.162437 , 7123917.921840 ]

  11 [ 399498.900000 , 7179298.700000 ] [ 399490.300307 , 7179310.844932 ]

  12 [ 449750.700000 , 7179581.900000 ] [ 449749.517992 , 7179586.383251 ]

  List of Residuals

  *******************

  ID Weight X-Component Y-Component VectorNorm

  --------------------------------------------------------------------------------------------

  1 1.00 -1.629659414 16.311974859 16.393178874

  2 1.00 5.079977336 -6.946668010 8.605949464

  3 1.00 -2.843897290 -4.406276007 5.244332183

  4 1.00 -7.644821656 -4.342475807 8.792064279

  5 1.00 -5.505427580 7.278496484 9.126129733

  6 1.00 7.607646697 19.124468721 20.582069675

  7 1.00 1.936959281 -11.691800690 11.851160898

  8 1.00 -2.834445248 -8.953958160 9.391881952

  9 1.00 -8.585596244 4.876261763 9.873722280

  10 1.00 4.637563426 5.378159508 7.101520558

  11 1.00 8.599692800 -12.144931703 14.881333352

  12 1.00 1.182007866 -4.483250976 4.636451435

  Residuals (Sum) - X : -2.625165507E-08 Y : -1.862645149E-08

  Residuals (Sum of Squares - X & Y) : 1574.040141472

  Scaling - X : 1.250257 Y : 1.250349

  Translation - X : 338898.447172 Y : 7114096.609280

  Rotation - 0.351557 degrees

  Non-orthogonality - -0.004027 degrees

  End of report. Checked :............ .../.../...

  ********************************************************************************************

[back to top]

3.4 Communication with Geoscience Australia in relation to data and map production

Action Requests and Production Notes are an important means of communication available to Producers when they wish to query specific project or feature instructions (Action Requests) or document specific action they have taken during the production phase (Production Notes).

These forms of communication are important in that they provide Geoscience Australia in general, and Validation And Testing Unit (VAT) in particular, a clearer and more complete picture of the issues addressed by the Producer. These documents can then be used in the assessment and validation of the submitted data etc. It is in the interest of the Producer to supply this documentation (where deemed necessary), so that VAT can take these issues and decisions into consideration, particularly where a specific course of action has been sanctioned by Geoscience Australia.

It is important that the Producer follows the guidelines below on the use of Action Requests, Production Notes and general communication.

Action Requests should be used to:

• Clarify any feature revision instructions within the Project Instructions.
• Highlight any major anomalies with features in the data not identified within the Project Instructions.
• Request further information not provided in the Project Instruction or Delivery record.
• Seek guidance on feature editing or revision when a decision or course of action cannot reasonably be determined from the information/instructions supplied.
  
  Note: Action Requests submitted for this purpose should be used sparingly and only when unable to resolve the issue following investigation of supplied information.
  
  
• Inform Geoscience Australia of any issues with the data (e.g. quality/accessibility of data received, or notes on data generated and submitted by the Producer), or advice or explanation for any delays in delivery.
  
  Important: Hard copies of Action Requests (with the response by Geoscience Australia) should be placed on the Project File at submission, and preferably in a chronological order. Where an Action Request response is generic and applicable to a number of different Work Packages, the Action Request should be copied by the Producer and placed on each respective individual Work Package file.

Production Notes should be used to:

• Detail any interpretation of features that require further explanation.
• Detail any alteration of features that link back to a action request response.
• Provide justification or explanation for any revision or actions carried out where they are inconsistent with relevant Project Instructions or Specifications.
  
  Note: It will be assumed that the Project Instructions and relevant Specifications have been complied with, and Production Notes are only required to explain actions that deviate from them.
  
  

Production Notes should be created using the Production Note feature type within the Production Feature Dataset. For more information, refer to the Production Note feature type entry within Appendix A.

Action Requests should be created using the template supplied to producers by Geoscience Australia. This template is not part of the specifications but rather part of the general reference information provided to each contractor.

If instances arise where the Action Request/Production Notes system is not appropriate and the Producer feels it necessary to contact someone in Geoscience Australia, then please contact the Work Package Team Leader as your first point of call. The contact information for the Work Package Team Leader will be supplied within the project instructions.

[back to top]

4. The National Topographic Database Structure

The following table lists every NTDB Feature Dataset, their associated Feature Type, attribute fields and Spatial Object. The attributes are listed in the order required for the NTDBs.

Note:

· Feature Classes and their associated Feature Types are shown separately where their individual Attribute Items differ

· Those Feature Classes, Feature Types, and Attribute items applicable to specific scales (only) are indicated in parenthesis eg. (250K only)

·These specifications and the associated table below represents the Production geodatabase schema. This schema differs in structure and precision to the Distribution geodatabase schema supplied by Geoscience Australia to the public via on–line downloads and packaged products. A distribution schema to production schema cross reference is provided to assist in translation by users.

[back to top]

5. General Notes

5.1 Extents of maps generated from the NTDBs

NTMS Series and customised maps are generated from the TOPO250K (1:250 000 scale) and TOPO100K (1:100 000 scale) databases. NTMS and customised maps for a standard 1:250 000 sheet area will extend 4' to the north and 6' to the east beyond the standard area. For a standard 1:100 000 there will be no extension. However, initially many 1:100 000s will not be based on standard sheet lines - boundaries will be defined in the project instructions supplied and will take precedence over any stated boundaries in these specifications. The map extents are outlined in Appendix H, together with a complete list of adjusted sheet extents.

5.2 Annotation and Paper Trimming

Annotation will be placed within the extents of the associated map index such that it will not be clipped when the printed map is trimmed.

At 1:250 000 annotation will not extend past the 3' and 5' bleed edge limits, ie. not extend within 1' of the northern and eastern map index extents. Particular care should be taken to allow for the 'tilt' of the sheet. For example, trimming a sheet on the western edge of a UTM zone will cause a Bleed Edge of less than 5' at the south east corner.

5.3 Cartographic Generalisation,Selection and Overlap

The TOPO250K and TOPO100K are cartographically generalised databases. Features in the databases will at times be displaced from their true position on the ground and their position as shown in satellite imagery. Only in extreme cases should existing features in the databases be moved so as to better match their position on satellite imagery. Any discrepancy equal to or more than 200 metres at 1:250 000 and 80m at 1:100 000 between where a feature is shown in the existing data and as shown on imagery would constitute an extreme case. When adding new features to, or editing existing features in the databases, the cartographic generalisation should be maintained. For instance, new roads may have to be displaced so that they do not plot over the top of railways.

Selection of features may also be affected by the need for cartographic generalisation. The feature type dictionary in Appendix A gives minimum criteria for inclusion of features. However, in some areas the density of detail will result in features which meet the minimum criteria for selection being omitted to prevent clutter. The need for such selections will be the exception rather than the rule. When such selections must be made, the aim will be to preserve the essential character of the terrain the paper or digital map portrays. Priority should be given to features with high landmark value and to ensuring the connectivity of transport features. For example, major roads would take precedence over vehicle tracks or minor watercourses.

Along the sides of designated work area boundaries the digital data must be identical spatially and in its attribution.

The exceptions to this rule are:

• temporal changes in features since the earlier data was produced
• errors in the data structure (see Appendix J Chapter 2.1.1 Logical Consistency)
• changes in the selection rules as set out in Appendix A - Feature Type Dictionary .
• differences between versions of the specification (see Appendix J Chapter 3.2 Impact of Specification Changes)

Apparent errors in attributes along a work area boundary or difficulties in identifying the continuity of features where they extend beyond/ or into the work area should be referred to Geoscience Australia.

[back to top]

5.4 The Use of Satellite Imagery and Aerial Photography

As a general rule a feature should not be captured solely from satellite imagery or aerial photography. These sources are generally used to position new features, and other information is used to verify existence and attribute the features. Guidelines for the use of satellite imagery and aerial photography will be issued to producers so that its use will be consistent.

5.5 Priorities in Use of References, Map and Imagery

As listed in Section 3 chapter 3.2, Source Material and Information Supplied by Geoscience Australia, information for production, revision and maintenance of the TOPO250K and TOPO100K NTDBs are drawn from a wide range of sources. Appendix A - Feature Type Dictionary includes specific rules for the use of some sources. Supplementary guidelines for resolving conflicts between sources will be issued to producers so that use of sources will be consistent.

5.6 Datum Shift

TOPO250K Series 1 GEODATA, which may be supplied to revise spot elevations, is in the AGD66 datum. In addition, some revision information may be supplied to producers in paper, repromat or digital form situated on the AGD66 datum. It would be unusual for producers to be supplied digital data in AGD66 but if this does occur the tape will be labelled as such. Producers need to be aware of the source datum and projection of all information supplied.

Any information in AGD66 will need to be shifted into the GDA94 datum before merging/inclusion into the TOPO250K and TOPO100K databases.

The following diagrams illustrate the effect of the datum shift on the position of the tile edges and the features that cross those tile edges. Additional information on GDA94 can be found in Appendix M.

Where data is digitised from repromat or generated from AGD66 source material, data from the adjacent tiles to the south and west will need to be included to allow for the datum shift. This is illustrated by the diagram below:

Graphical mismatches that were not resolved within source material/data will also manifest themselves within the new tile boundaries as shown below. These mismatches become internal to the tile when in the new datum, and must be resolved.

[back to top]

5.7 Direction of Digitising

For some features, such as cliff, embankment, and reserve boundary line, the direction of digitising is important. For reserve boundary line the direction of digitising will be anti-clockwise, as shown in the following diagram. This will place the verge of the symbol on the correct side of the digitised line.

Where direction of digitising is used in symbology it is noted in the feature type dictionary, see Appendix A.

5.8 Feature Width Attribute

The feature width attribute may be used to control three aspects of symbology:

• The width of a symbol, where the attribute controls the line weight of the symbol, for example, the line weight of roads under construction.
• The internal gap between two sides of a symbol, where the attribute controls the distance between two elements of a symbol, for example the distance between the two sides of a bridge to accommodate road symbols of varying width.
• The offset of a symbol from the feature's position where the attribute controls the distance a symbol is displaced from the feature's location. For example, a reserve boundary line may be coincident with a road but the symbology will be displaced to allow for the width of the road symbol. The direction of digitising dictates the direction the symbol is offset. The symbol will move to the left when viewed from start node to end node.

Example:

The usage of the feature width attribute for particular features is given in the feature type dictionary, Appendix A.

5.9 Orientation Attribute

The angle of orientation is anti-clockwise and as illustrated on the following diagram. The axis of oriented symbols is shown in the symbol dictionary, Appendix S.

The following diagram illustrates the effect of orientation on the plotting of a bridge symbol.

[back to top]

5.10 Type, Name and Text Note Attributes and Annotation Features

All type displayed on the face of the map will be stored as annotation features. Where the type relates to an entity feature, the text held in the blob element of the annotation feature must be consistent with the data stored in the relevant attributes of the entity. For example, description, height and TextNote attributes are all relevant attributes for a Vertical Obstruction - tower. Note: that the text that appears on the face of the map may be a combination of several attributes in the databases. The Dtext items will not be updated but exist only to assist in populating annotation from an ArcInfo coverage format.

Annotation should not exist on the map face that is not associated with a feature contained within the digital data except where that annotation is a general descriptor of the area (e.g. 'numerous bores and wells').

Annotation should not exist on the map face when its associated feature is not symbolised (note: Polygons may be symbolised/represented by a shading, by their boundary line or a combination of both). The following exceptions exist for this rule:

• Airports
• Dams (when coincident with roads)
• Fords
• Fences (non printing where follows state border or road)
• Grid Lines (when follows the central meridian)
• Localities(non-printing)
• Offshore rocks (in close proximity to lighthouses)
• Pipelines (non printing when adjacent to another pipeline)
• Waterfalls

Where the name attribute exists, it is used to store the name of a feature. The name must be stored against each spatial object making up the entity, for example, each chain along the course of a river.

TextNote is intended to provide additional textual information for the map face. The TextNote field will not duplicate text in other data attribute fields. A TextNote should be applied to each feature requiring clarification on the map face regardless of whether the resultant derived annotation is generalised into a plural form (e.g. 3 vertical obstruction features within close proximity in the data, should each have a TextNote "water capture net" but will result with a singular piece of generalised annotation on the map face "water capture nets"). Where the Map rules in Appendix A, Feature Type Dictionary, require or allow the naming of a feature and there is no name field the name will be held in the TextNote field. One TextNote or Name may be divided between two or more annotation features.

Examples:

Name attributes will be in upper case. TextNote and blob element text attributes will be in the case in which they appear on the map. Parentheses will not be included in TextNotes. In the case of Vertical Obstruction features where the height is shown on the face of the map the abbreviation for metres ('m') will not be included in either the height or TextNote attributes.

All annotation will be held in the annotation feature type, except for annotation for the mapgrid values and 100 000 metre identification letters which will be in the Grid Annotation feature type and for graticule values which will be held in the Graticule Annotation feature type. All grid values, including those outside the neat line will be included in Grid Annotation feature type. All graticule values, including those outside the neat line will be included in the Graticule Annotation feature type.

For additional information on Font and text sizes for annotation see Section 2 Chapter 8. 1:250 000 Scale Type Specifications and Section 2 Chapter 9. 1:100 000 Scale Type Specifications.

[back to top]

5.11 Spatial Coincidence

The spatial object for some feature types have a physical or assumed link to the spatial objects of other feature in the database. There are four types of linkages:

• Cloned features
• Coincident features
• Node on Chord
• Vertex on Chord

5.11.1 Cloned features

A feature is cloned when its spatial attributes are to be exactly the same as those of another feature. Cloned features are of the same geometry type, that is, a line will be cloned to a line, a point to a point. The following table lists some example clone relationships. The data rules sections of the feature type dictionary indicate where a feature is cloned from another - see Appendix A.

5.11.2 Coincident Features

Features are coincident when they share one or more coordinate pairs. For example, a point feature may need to be coincident with a linear feature, or two linear features may be coincident sharing a number of points. Point features may need to be coincident with a node rather than a vertex, for example a road junction needs to be coincident with the nodes of intersecting roads. Where linear features are coincident one line may leave the other part way down a chord. However, at the point where one line deviates from the other the vertex of the deviating line must be within one 1metre of the chord in both geographical and MGA coordinates.

Examples:

When point features are required to be coincident with a node in a line feature they must have exactly the same coordinates as the node in the line feature.

The following table lists some of these point-over-node coincidence relationships. The two inter-relationship rules sections of the feature type dictionary give a more complete listing of relationships - see Appendix A.

When point features are required to be coincident with a vertex in a line feature they must have exactly the same coordinates as the vertex in the line feature.

The following table lists some of these point-over-vertex coincidence relationships. The two inter-relationship rules sections of the feature type dictionary give a more complete listing of relationships - see Appendix A.

The following table lists some of the linear feature to linear feature relationships. The two inter-relationship rules sections of the feature type dictionary give a more complete listing of coincidence relationships - see Appendix A. Where a feature in the right column of the table falls within 50 metres of a feature at 1:250 000 scale and 20 metres at 1:100 000 scale in the left column, then it should be made coincident with the feature in the left column.

5.11.3 Node of Line Feature on Chord of another Line Feature

In the databases, some features are required to end exactly on another. For instance, connectors are often required to end on a junction feature, even though the junction feature resides in a different layer. When one feature is required to end on another feature the coordinates of its end node are required to be exactly the same as the coordinates of a vertice in the cross feature, or to be within 1 metre in both geographical and MGA coordinates of a chord in the cross feature.

The following diagram illustrates this relationship. The two inter-relationship rules sections of the feature type dictionary give a more complete listing of these relationships - see Appendix A.

[back to top]

5.12 Nodes and Vertices on the Limit Of Data

Where the Limit Of Data forms a polygon boundary it is important that a node is present where the polygon meets the Limit Of Data

All Limit Of Data features should be densified so that there is a vertice at least every 0.002 degrees, which is approximately every 200 metres. Limit Of Data features in different layers will be coincident with each other where they overlap, such that their vertices are coincident.

5.13 Precision

The precision of the NTDB is 0.000001 degrees, which equates to approximately 0.1 metres on the ground. This value is determined by dividing 1 coordinate system unit (degree) by the scale of the data. 1 degree / 1000000 = 0.000001 degrees.

The scale of the geodatabase is inversely related to its Spatial Domain. The Spatial Domain determines the extent of the data and is described in coordinate system units.

In the NTDB the Spatial Domain is set as:

Minimum X: 108.000000
Minimum Y: -48.000000
Maximum X: 2255.483645
Maximum Y: 2099.483645

Scale: 1000000.000000

The coordinate precision of all features in the source geodatabase supplied for production purposes should be maintained i.e. coordinates will not be rounded in the supplied geodatabase or following subsequent feature editing. (Note: The previous GEODATA requirement to round coordinates does not apply to the NTDB geodatabase model.)

5.14 Maintaining Unique Feature Identifiers (TOPO250K Only)

Except where the loss of unique feature identifiers is unavoidable, the attribute values in the UFI field should be maintained. Loss of the UFI will be unavoidable when:

• Two features with different UFIs are combined into one feature.
• A single feature is split into two or more features.
• A polygon where the area has changed.
• A feature changes feature class.

Where a feature changes spatial attributes, such as in a road realignment, the UFI will be maintained (as long as the start and end nodes are the same).

Where a feature changes other attributes, such as a change in a road classification, it will maintain the UFI.

5.15 Printing and Non-printing Features

Some features do not print on the map. Others may or may not print depending on their attributes, the type of feature they bound or other criteria. For example, waterbodyboundaries, when bounding areas of land subject to inundation, swamp, saline coastal flat, does not print, whereas, when bounding watercourse areas or lakes, it does print. When a feature does not print it has a symbol attribute of 0. The symbol attribute description in the feature type dictionary defines when the feature prints, see Appendix A. The following diagram illustrates this.

[back to top]

5.16 Merging Features

Merging of features should occur when all attributes other than those listed below are identical:

• MapNumber (unless related to a cartographic feature)
• FeatureReliability
• FeatureSource (TOPO100K only)
• AttributeReliability
• AttributeSource (TOPO100K only)
• PlanimentricAccuracy
• ElevationAccuracy
• Source (TOPO250K only)
• UFI
• Creation Date
• Retirement Date
• PID
• EDITCODE (Note: This attribute will not be supplied for NTDBs production purposes)
• Edit Date (Note: This attribute will not be supplied for NTDBs production purposes)

When two features are merged to form a single feature the following items will be populated with the values held in the component feature with the most recent FeatureReliability Date:

• FeatureReliability
• FeatureSource (TOPO100K only)
• AttributeReliability
• AttributeSource (TOPO100K only)
• PlanimentricAccuracy
• ElevationAccuracy
• Source (TOPO250K only)

The ufi value from the component feature with the most recent FeatureReliability Date will have precedence unless it is NULL, in which case the populated ufi value will be used. The following items will be given a NULL value when merged:

• Creation Date
• Retirement Date
• PID
• EDITCODE
• Edit Date

5.16.1 Creating Multi-polygon Features

This involves grouping multiple polygons with the same attribute values into a single feature. The polygons will not be adjacent to each other. This applies to Built Up Areas, Reserves (Feature Class), and Islands. Built Up Area polygons that have the same name should be merged into a single multi-polygon feature. The same logic applies to Reserve polygons and Island polygons which have identical attributes other than those listed in Section 3 Chapter 5.16 Merging Features. Unnamed islands and Reserves will not be made multi-polygons.

[back to top]

5.17 Guidelines for defining the Feature Type value for polygon bounding lines

The definition of polygon bounding lines will be determined using Table 1: Polygon Bounding Line Feature Type Priorities, below. Where feature dataset polygons abut, the bounding lines will be classified using this table. Priority will be given to the feature type highest on the list.

Where boundary lines are applicable according to the scale of the NTDB, they must be an exact clone of the polygon edge to which they surround.

Where a polygon is imported into a NTDB feature dataset, any tile edge associated with that polygon should be imported into that dataset's Limit Of Data representation.

Table 1: Polygon Bounding Lines Feature Type Priorities

The following diagrams further clarify these priorities.

5.17.1 Administration

5.17.2 Hydrography

[back to top]</