The Spatial Data Model has been updated as of January 11, 1999. The links below
are to the new version.
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:
definitions (zipped Word 2 document, 8kb), and
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
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
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