Harmonised Data Model Version 1, 2000

Model Documentation

1.0: Harmonised Model and Dependencies on ISO Standards

Diagram 1.0

Diagram 1.0 is the highest level diagram for the HDM. It depicts the HDM as a single UML package named ICSM Harmonised Model. It also identifies the dependencies of the model on ISO 191xx Standards.

2.0: Thematic Packages, Common Elements and Interdependencies

Diagram 2.0

Diagram 2.0 depicts the dependencies between the four themes (cadastre, topography, place names, street address). It also depicts the dependencies between the themes and the ISO 191xx standards.

The following should be noted:

  • The themes are all represented as sub-packages of ICSM Harmonised Model.
  • The ISO 191xx standards are represented as UML packages.
  • A sub-package named Common has been established. Common contains classes that are referenced by two or more of the thematic sub-packages. Classes in the thematic sub-packages inherit attributes and associations from the classes in Common (reflected by the dependency relationships between Common and the themes). This approach ensures that the common attributes are applied in a consistent fashion across the model. It also simplifies future model maintenance.
  • There are dependencies between the four thematic packages. This reflects the desire to avoid replicating data structures throughout the model. For example, Topographic, Cadastral and Street Address all are dependent on the Place Names package, reflecting that each may model named features (for example, a river, a reserve, an address). The dependencies ensure that all three utilise same place name data structures rather than inventing three different data structures.
  • The thematic packages are dependencies on ISO standards, in particular ISO 19107 - Spatial Schema. This reflects the intention that all thematic packages should model their geometric components in the same way (rather than four different ways) and that the modelling should comply with international standards to facilitate wider exchange.

3.0: Common Elements to All Themes

Diagram 3.0

Diagram 3.0 depicts the classes that are common to all themes. The following should be noted:

Common Classes

  • A class named CommonElements has been established. This contains four attributes that that are needed by almost every class in every thematic sub-package, The attributes are a persistent identifier (persistentID), a dataset identifier (datasetID), a creation date (createDate) and a retirement date (retireDate).

Common Sub-Package Structures

  • There are two sub-packages within Common named FeatureTypeCatalogue and MetadataStructures.
  • The classes in FeatureTypeCatalogue provide a mechanism for classifying the features in a dataset. They allow for the definition of an authoritative catalogue of feature types (through classes FeatureTypeDefinition and Catalogue) and for references to catalogues that might hold alternative definitions for the same feature types (through classes AlternativeDefinition and Catalogue). The class FeatureTypeDefinition also provides for classification hierarchies (for example, Water Feature, Stream, Perennial Stream), the association FeatureTypeHierachy linking superordinate and subordinate classifications.
  • The classes in MetadataStructures allow for the inclusion of metadata for specific attribute instances (through AttributeInstanceMetadata) and for the inclusion of metadata regarding spatial accuracy (through FeatureInstanceMetadata). [Note - at the time of writing, these structures do not comply with any metadata standard.]

Root Classes

  • Four classes have been created to cluster the common attributes and associations for inheritance by classes in the thematic packages.
  • FeatureRoot is inherited by thematic classes that do not contain spatial attributes. The class itself inherits the attributes of CommonElements. It also establishes associations with FeatureTypeDefinition and AttributeInstanceMetadata.
  • SpatialRoot is inherited by thematic classes that contain only spatial attributes. The class inherits the attributes of CommonElements and establishes an association with FeatureInstanceMetadata (containing spatial accuracy information).
  • TopoRoot is inhered by classes in the Topographic theme that have both spatial and non-spatial characteristics. The class inherits the attributes and associations of FeatureRoot and establishes an association with FeatureInstanceMetadata.
  • DisplayRoot contains attributes for displaying text at a point, and is inherited by classes requiring that capability. The class inherits the attributes and association of SpatialRoot.

4.0: Cadastral - Cadastral Sub-Packages

Diagram 4.0

The classes in the Cadastral Package are clustered into four sub-packages as follows:

  • PrivateLawObjects - Contains non-spatial classes associated with the registration of land rights (Parcel, Title, Plan, Easement, Reserve, RoadReserve, SecondaryInterest).
  • PublicLawObjects - Contains non-spatial classes associated with the public administration of land (Property, AdminArea).
  • CadastralGeometry - Contains spatial classes providing the geometric representation of the cadastre, topology being provided through associations.
  • Survey - Contains classes associated with measurements obtained during field surveys and determined for the preparation of cadastral survey plans.

4.1: Cadastral - Non-Geometric Classes

Diagram 4.1

Diagram 4.1 depicts the classes in the PrivateLawObjects and PublicLawObjects sub-packages. The following should be noted:

  • All classes inherit the attributes and associations of the FeatureRoot class in the Common sub-package. Thus all instances have persistent identifiers, dataset identifiers, creation dates and retirement dates as well as associations with attribute metadata and a feature catalogue.
  • There is an association between the classes Parcel and Property reflecting the link between the legal and fiscal cadastres.
  • The class Plan is associated with the classes Parcel, Easement, Reserve, Road Reserve and SecondaryInterest, providing a link between instances of the latter classes and the plans on which they appear.
  • The class Plan is associated with the class SurveyRecord in the Survey sub-package, providing a link between a plan instance and its associated measurement data.

4.2: Cadastral - Associations with Polygon Representation

Diagram 4.2

Diagram 4.2 depicts the associations between the non-spatial classes in the PrivateLawObjects and PublicLawObjects sub-packages with their geometric representation as polygons in the CadastralGeometry sub-package. The associations reflect the decision to separate the spatial and non-spatial components of the model. The following should be noted:

  • The CadastralPolygon class inherits the attributes and associations of the SpatialRoot class in the Common sub-package. Thus all polygon instances have persistent identifiers, dataset identifiers, creation dates and retirement dates as well as associations with feature instance metadata.
  • The cardinality of the associations allows the non-spatial classes to exist without a geometric representation and the spatial class CadastralPolygon to exist without non-spatial attributes (as in the case of a background cadastral map).
  • The associations allow the attributes of any non-spatial class to be associated with any instance of CadastralPolygon. Thus the attributes from one or more administrative area instances (such as a local government area identifier and a state identifier) can be associated with the polygon representation of a parcel.

4.3: Cadastral - Associations with Area Point and Place Names

Diagram 4.3

Diagram 4.3 depicts the associations between the non-spatial classes in the PrivateLawObjects and PublicLawObjects sub-packages with the geometric representation of their representative points (geocodes) in the CadastralGeometry sub-package. The associations reflect the decision to separate the spatial and non-spatial components of the model.

The diagram also depicts the associations between the PlaceName class in the PlaceNames sub-package and certain classes in the Cadastral package. The associations accommodate instances of cadastral classes that have formal or informal names (For example, ‘Adelaide Oval’). In addition, through the associations in Diagram 4.2, they provide for recording the spatial extent of a named cadastral feature in a gazetteer.

The following should be noted:

  • A representative point provides the location for plotting/displaying any text associated with the relevant PrivateLawObjects and PublicLawObjects.
  • Representative points are instances of the AreaPoint class.
  • The AreaPoint class inherits the attributes and associations of the DisplayData class in the Common sub-package. Thus all representative point instances have persistent identifiers, dataset identifiers, creation dates and retirement dates as well as associations with feature instance metadata, text display parameters and geographic coordinates.
  • The cardinality of the associations allows the non-spatial classes to have more than one representative point.

4.4: Cadastral - Geometry and Topology, Associations with Survey

Diagram 4.4

Diagram 4.4 depicts the geometric and topological representation of cadastral points, lines and polygons.

The following should be noted:

  • The CadastralPolygon, Boundary and BoundaryPoint classes inherit the attributes and associations of the SpatialRoot class in the Common sub-package. Thus all instances have persistent identifiers, dataset identifiers, creation dates and retirement dates as well as associations with feature instance metadata.
  • CadastralPolygon, Boundary and BoundaryPoint all adopt representations from ISO 19107 Spatial Schema to describe the geometry of their respective spatial primitives (GM_Point, GM_Curve, GM_Surface).
  • Topology between CadastralPolygon, Boundary and BoundaryPoint is expressed through the associations.
  • An instance of Boundary may comprise a single line, arc, geodesic, spline, etc, or a string of such constructs (as described ISO 19107 Spatial Schema). If a string is to be used (for example, to represent a natural boundary such as a watercourse), only the first and last points will be used in topological relationships.
  • There are associations between classes in CadastralGeometry and Survey. In particular, CadastralPolygon is associated with Survey Polygon and BoundaryPoint with SurveyPoint. The associations represent the linkages between database representations of points and polygons, and their survey representations on one or more plans.

4.5: Cadastral - Survey and Associations

Diagram 4.5

Diagram 4.5 depicts the classes in the Survey sub-package. The objective of the sub-package is to provide a common model for the electronic lodgement of data. The following should be noted:

  • The SurveyAngle and SurveyLine classes inherit the attributes and associations of the CommonElements class in the Common sub-package. Thus all instances of both have persistent identifiers, dataset identifiers, creation dates and retirement dates.
  • The SurveyPoint class inherits the attributes and associations of the SpatialRoot class in the Common sub-package. Thus all polygon instances have persistent identifiers, dataset identifiers, creation dates and retirement dates as well as associations with feature instance metadata.
  • There are associations between classes in the CadastralGeometry and Survey sub-packages. In particular, CadastralPolygon is associated with SurveyPolygon and BoundaryPoint with SurveyPoint. The associations represent the linkages between database representations of points and polygons, and their survey representations on one or more plans.
  • The class Plan is also associated with the class SurveyRecord in the Survey sub-package, providing a link between a plan instance and its associated measurement data.

5.0: Topographic - All Feature Classes, Associations with Place Names

Diagram 5.0

The Topographic classes are clustered into a single sub-package, represented on diagrams 5.0 and 5.1. Diagram 5.0 depicts the non-geometric classes in the Topographic sub-package. The following should be noted:

  • The NamedTopo class inherits the attributes and associations of the TopoRoot class in the Common sub-package. It therefore inherits the persistent identifier, dataset identifier, creation date and retirement date attributes as well as associations with attribute metadata, feature instance metadata and a feature catalogue.
  • NamedTopo also has an association relationship with the PlaceName class in the PlaceNames sub-package. The association accommodate situations where instances of topographic classes have formal or informal names (For example, ‘Mt Lofty’, ‘River Murray’) and therefore need the place name data structures. The association also provides, through the associations in Diagram 5.1, the mechanism for recording the spatial extent of a named topographic feature in a gazetteer.
  • The GeneralFeature, EarthSurface, InlandWaterFeature, Tank, Utility, Road and Railway classes all inherit the attributes and associations of the NamedTopo class. Instances of these classes therefore inherit the persistent identifier, dataset identifier, creation date and retirement date attributes as well as associations with attribute metadata, feature instance metadata, a feature catalogue and place names data structures.
  • The RouteSegment and Route classes inherit the attributes of the CommonElements class in the Common sub-package. Instances of these classes therefore inherit the persistent identifier, dataset identifier, creation date and retirement date attributes.
  • The classes GeneralFeature, EarthSurface, InlandWaterFeature, Railway, Road and Utility have hierarchies of sub-types defining specific topographic features (for example, beach, airport, etc). These are listed below and are defined in the ICSM Feature Catalogue. The individual sub-types are not depicted in the data model. However, they inherit all attributes and associations from their respective supertypes (GeneralFeature, etc).

General Features

  • Airport
  • Bay
  • Beach
  • Beacon
  • Breakwater
  • Building Complex
    • Education Facility
    • Fire Station
    • Homestead
    • Hospital
    • Power Station
  • Built-Up Area
  • Cape
  • Cliff
  • Dam
  • Desert
  • Embankment
    • Levee
  • Ferry Route
  • Flat
    • Foreshore Flat
    • Mangrove
    • Saline Coastal Flat
    • STI (Subject to Innundation)
  • Gap
  • Ice Field
  • IslandLandcover
    • Timber
  • Mine
    • Open Cut
  • Mountain
  • Mountain Range
  • Park
    • Golf Course
    • Sports Field
  • Peninsula
  • Place
  • Plain
  • Plateau
  • Pondage
    • Salt Evaporation Pond
    • Settling Pond
  • Reef
  • Rock
  • Runway
  • Sand Ridge
  • Sea
  • Shoreline
  • Tower
    • Communications Tower
    • Fire Tower
    • Water Tower
  • Valley
  • Wharf

Earth Surface

  • Contour
    • Depression Contour
  • Spot Elevation

Inland Water Feature

  • Major Watercourse
    • Major Watercourse Connector
  • Minor Watercourse
    • Minor Watercourse Connector
  • Swamp

Railway

  • Railway in Tunnel
  • Railway on Bridge

Road

  • Road in Tunnel
  • Road on Bridge

Utility

  • Pipeline
    • Gas Pipeline
    • Oil Pipeline
    • Waste Pipeline
    • Water Pipeline
  • Power Line

5.1: Topographic - All Feature Classes, Geometric Representation

Diagram 5.1

Diagram 5.1 depicts the geometric classes in the Topographic sub-package. The following should be noted:

  • There are no explicit topological relationships between instances of topographic classes. The model is intended to support map compilation rather than GIS network analysis. [This may change in future revisions.]
  • Four (spatial) classes have been established to accommodate the geometric representations of point, curve, compound-curve and surface features (TopoPointElements, TopoSimpleCurveElements, TopoCompCurveElements and TopoSurfaceElements respectively). Each of the four adopt schema from ISO 19107 Spatial Schema to describe the geometry of their respective spatial primitives (GM_Point, GM_Curve, GM_CompoundCurve and GM_Surface).
  • Instances of the GeneralFeature, EarthSurface, InlandWaterFeature, Tank, Utility, Road, Railway and Route classes may be represented by more than one spatial classes, thereby catering to scale-dependent portrayal requirements (for example, a river segment may be represented as a curve and surface at small and large scales respectively).
  • The model permits the sharing of spatial primitives. Thus a bridge being an instance of GeneralFeature and a road segment being an instance of Road can be represented by the same instance of TopoSimpleCurveElements should the two features be coincident.

6.0: Place Names - All Classes, Associations with Cadastral and Topographic

Diagram 6.0

Diagram 6.0 was prepared in consultation with Permanent Committee on Place Names (PCPN). Its principle purpose is to identify data structures for the preparation of place name gazetteers. Most of the attributes, however, can be considered optional, enabling the structures to be more widely applied.

The following should be noted:

  • The PlaceName class inherits the attributes and associations of the FeatureRoot class in the Common sub-package. Thus all instances have persistent identifiers, dataset identifiers, creation dates and retirement dates as well as associations with attribute metadata and a feature catalogue (if needed).
  • The DisplayPoint class inherits the attributes and associations of the DisplayData class in the Common sub-package. Thus all display point instances have persistent identifiers, dataset identifiers, creation dates and retirement dates as well as associations with feature instance metadata, text display parameters and geographic coordinates.
  • The diagram depicts associations between the PlaceName class and the AdminArea, Property, Reserve and RoadReserve classes in the Cadastral package. The associations accommodate instances where cadastral classes have formal or informal names (For example, ’Adelaide Oval‘). In addition, through the associations in Diagram 4.2, they provide for recording the spatial extent of a named cadastral feature in a gazetteer.
  • The diagram depicts an association between the PlaceName class and the NamedTopo class in the Topographic sub-package. The association accommodate situations where instances of topographic classes have formal or informal names (For example, ’Mt Lofty‘, ’River Murray‘) and therefore need the place name data structures. In addition, through the associations in Diagram 5.1, it provides for recording the spatial extent of a named topographic feature in a gazetteer.

7.0: Street Address - All Classes, Associations with Cadastral and Place Names

Diagram 7.0

Diagram 7.0 was prepared in consultation with the ICSM Street Address Working Group. Its principle purpose is to identify data structures for the preparation of geocoded street addresses that conform to the draft National Street Address Standard.

The following should be noted.

  • The Address class inherits the attributes and associations of the FeatureRoot class in the Common sub-package. Thus all instances have persistent identifiers, dataset identifiers, creation dates and retirement dates as well as associations with attribute metadata and a feature catalogue (if needed).
  • The AddressGeocode class inherits the attributes and associations of the SpatialRoot class in the Common sub-package. Thus all geocode instances have persistent identifiers, dataset identifiers, creation dates and retirement dates as well as associations with feature instance metadata.
  • Instances of place names that form part of an address (building name, road name, and locality name) are held in data structures defined in the PlaceNames package.
  • The diagram depicts associations between the Address class and the Parcel and Property classes in the Cadastral package. The associations accommodate instances where cadastral classes have street addresses.