Spatial Data Model

The Spatial Data Model includes two parts: an entity-relationship diagram (ERD), and a data dictionary. The ERD is a picture that shows all the "things" we want to collect information about, relating to spatial data. The data dictionary explains what the entity types from the ERD are, in detail. The Spatial Data Model was used as the preliminary design for our INCOSADA Spatial Data Dictionary. NOTE: as of April 1998, we are in the midst of developing two versions of ISDD, one for the future and one for today's data -- the Spatial Data Model available here relates to today's data version of ISDD, called ISDD1.

You can view the entire (unreadable) spatial ERD (18kb), and then see below for more readable quadrants. The data dictionary information is available for download: Entity type definitions (zipped Word 2 document, 8kb), and Attribute definitions by Entity type (zipped Word 2 document, 8kb).

Admittedly, it seems a bit non sequitur-ish to use an ERD for a spatial model, but the spatial tools industry is kind of in the position of delivering tools without a common underlying theory. Imagine what life would have been like in the early seventies if relational databases were available (they weren't) before Codd's paper on relational theory was published.

The spatial data model defines the underlying structure of metadata for spatial data. For example, we use Feature Classes to define common spatial features. We identify a Feature (e.g. "Lake Okanagan", "Forest Cover Polygon #1203") based on a Feature Class (e.g. "lakes", "Forest Cover Polygons").

Geographic features are classified using a feature class name (e.g. lake, road, trail, etc.) and are "encoded" using a Feature Code Number and a Feature Code. Feature Code Number and Feature Code both serve the same purpose - they are used to uniquely identify the "type" of feature and are more useful than a name which is more likely to change.

Feature classes and feature codes are useful in that they can be used to manage and reference groups of features in order to perform certain operations. They enable us to associate other descriptive information with a feature such as whether it's a point, line or polygon, a description for it, what symbology is used (e.g. level, colour, line weight, etc.) and so on.

The Feature Code Number is stored as a numeric value (e.g. 16025 might be the Feature Code Number for the "Resource Management Zone" feature class). The Feature Code is an 10-character alphanumeric value, starting with 2 letters, followed by 8 digits (e.g. AR24400000 might be the Feature Code for "Resource Management Zone").

The Feature Code is used government-wide and is generated in compliance with the Canada Council on Surveys and Mapping (CCSM) 1984 Draft Report on the classification of topographic features. A Government Feature Codes Database has been set up by the Ministry of Environment where users can query for feature codes maintained by the province.

The Ministry of Forests currently uses the Microstation platform for spatial data capture and the Microstation platform cannot use a feature code which has an alphanumeric value. For this reason, the Ministry decided to create the Feature Code Number - it has the same business use as Feature Code but is stored as a numeric value. The Feature Code Number exists only within the Ministry of Forests.

Back to the spatial model

To actually be able to read the spatial model described above, it's broken down into four quadrants. The quadrants generally follow the listed subject areas ( Feature Class, Spatial Data Type, Attribute Data & Future and Cartographic Output).