Development projects that have a spatial component have slightly different
requirements for data modelling in that there is both spatial and attribute data
to consider. The following document provides a draft checklist intended to guide
a spatial development project through the modelling exercise. In the absence of
fully documented standards, it is the Data Administration group's normal
practice to work with a project team to:
- help the project understand and work through any difficulties, and
- develop reasonable, workable standards or guidelines on the fly.
When in doubt, ask us!!
The Spatial Project Checklist includes:
See Also:
A feature class is defined to classify and describe a geographic
feature. A "feature" differs from a "feature class" in that the feature is an
instance of the feature class. For example, "Lake" is a feature class while "Nitinat
Lake", "Christina Lake" and "Lake Okanagan" are features. Other examples of
feature classes are: Opening, Forest Cover, Range Unit, Recreation Trail,
Resource Management Zone, Biogeoclimatic Zone, Forest District, etc.
The business staff should know what feature classes are necessary and within
the scope of the development project. There is usually some discussion as to
whether a feature should be "attributed" or stored as separate spatial entities.
For example, there could be one feature class called "Ski Trail" and all ski
trails could be stored spatially as one entity with information stored in the
attribute database to say whether a trail is "planned", "active" or
"deactivated". On the other hand, this could be managed with three separate
feature classes, "Ski Trail-planned", "Ski Trail-active" and "Ski
Trail-deactivated", with each of these stored as separate spatial entities. The
latter method could potentially mean duplicating the spatial information but
there may be valid business or technical reasons for doing so. In any case, this
is the kind of discussion that must go on to decide what feature classes are
appropriate.
We encourage attributed design as much as possible to avoid duplicating work.
Minimal Requirements in defining Feature Classes
The following information is the minimal requirement for defining a new
feature class.
- Feature Class Name - a unique name given to identify the feature
class. Existing examples are: Christmas Tree Permit, Cave, Grazing Licence,
Heritage Trails, etc.
- Description - a brief explanation of what the feature class is.
- Spatial Data Type - identifies the type of spatial data the
feature is stored as. These are fully defined in the document,
Standard
Positional Spatial Data Types and their representation in IGDS Format.
The standard spatial data types are:
- Point -- normal, polygon inside point, DEM;
- Text
- Linear Feature;
- Polygon -- overlapping or non-overlapping
- Positional Capture Standards- the symbology used to digitize and
store the positional data. This includes information such as level, line
weight, line code, colour, text weight, justification, etc. Note that the
positional capture symbology differs from the symbology used to represent
spatial information on a map - only the positional symbology is required for
the feature class definition.
Once the business staff has identified and defined the required feature
classes (ideally with the assistance of the Data Custodian), these should be
documented. The feature class definitions should be forwarded to the
Data Administration group in ISB.
The Data Administration group is responsible for assigning the MoF Feature
Code Number and CCSM Feature Code (which uniquely identify a polygon, for
example, as a "Forest Cover Polygon" or a "Lake") to the new feature class
definition and will enter it into the Integrated Spatial Data Dictionary (ISDD).
Ministry staff should first use ISDD to see if an existing feature class can be
used rather than creating a new and possibly duplicate one (Data Administration
staff can assist with that investigation).
As a reminder (just as in other systems development projects), the
Data Custodian must be involved when defining Feature
Classes (the exception is for corporate data which is
extended). Data Custodians (defined as a branch
director) may delegate the day-to-day decisions to data standards managers
within their line accountability. Contact Data
Administration staff for assistance in determining who the proper Data
Custodian (or delegate) is.
The Spatial Data Model (draft version) is also
available and is our definition of what technical information must be collected
to develop spatial systems, prior to analysing business information needs.
All other "modelling" can be done using normal relational standards, such as
Entity-Relation Diagrams (see Guide S7).
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 GIS users 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.
Storing Feature Code Number in IGDS Files
The technical information for storing the Feature Code Number in IGDS Files
is provided by the INCOSADA document,
Standard Positional
Spatial Data Types and their representation in IGDS Format.
Storing Feature Code Number in Attribute Databases
The Feature Code Number is stored as an unsigned 32-bit integer (e.g. with
values ranging from 0 to greater than 4 billion). The Feature Code is stored as
a 10-character alphanumeric string in the format, AANNNNNNNN (where 'A' =
alphabetic, 'N' = numeric). Storing the feature code number and/or feature code
in the attribute database is optional and will depend on how the business
decides to model its data (unlike the Feature ID which is mandatory and
described in the following section).
The following standard names and datatypes should be used to represent the
two feature code values:
- Feature_Code_Num - 32-bit unsigned integer
- Feature_Code - 10-character alphanumeric text string
In order to uniquely identify features stored by the Ministry it is important
that each feature have a unique key. Historically, spatial and attribute data
have co-existed in separate worlds - attribute data is typically stored in
relational databases and spatial data is captured and stored on CAD or GIS
platforms. The only way of linking the two together was by storing unique
identifiers as labels in the spatial data, generating a map and then manually
associating the labels with unique identifiers stored in the attribute database.
One of the initial goals of the INCOSADA project was to provide a physical
link between the spatial and attribute databases and to accomplish this, a
unique key, known as the Feature ID (FID), was created.
To ensure the province-wide uniqueness of the FID, a universally unique
identifier (UUID) will be used. The UUID is a computer generated number that is
designed to never be generated the same twice.
The UUID will be encoded into a single column as a 32-byte hex string. In
MS-Access, this will be represented as TEXT(32), in Oracle this will be
represented as VARCHAR2(32) and in SQL/DS this will be represented as CHAR(32).
The HEX characters ('A' - 'F') will be stored in upper case.
Storing Feature ID in the Spatial Data (in IGDS files)
The technical information for storing the Feature ID in IGDS Files is
provided by the INCOSADA document,
Standard Positional
Spatial Data Types and their representation in IGDS Format.
Storing Feature ID in Attribute Databases
Wherever there is a one-to-one relationship between a table in the attribute
database and a spatial feature class, a FID will be used to link the spatial and
attribute data together. A FEATURE_LINK table will be created for the feature
class, storing both the FID as well as the business key from the attribute
database.
For example, spatially, Opening is recorded as a polygonal feature class.
Attribute data is also stored for each opening in a Silviculture Database table
named Opening (currently, the ISIS application records attribute information for
Opening). The business key for the Opening table is: Opening_Number +
Admin_District_No. To link the spatial and attribute opening data together, a
table called FEATURE_LINK_OPENING will be created, storing the FID
(automatically generated when the polygon is digitized) and the business key.
When the Opening polygon is digitized, the user will be prompted to enter the
business key so that it can be stored along with the FID in the
FEATURE_LINK_OPENING table.
The last step in validating a data model for a spatial development project is
to have it reviewed by the Spatial
DataBase Administrator. The Spatial DBA will review the design looking for
things like:
- does the design make it feasible to do unreasonable things with the
spatial data (e.g. can a forest cover polygon with standing timber be drawn
over a lake)
- are appropriate data structures used for technical effectiveness (e.g.
is a polygon defined as continuous when it should be non-continuous)
- how the Feature Class or Feature Code can be implemented technically on
the core GIS toolsets currently available, and whether they will fit future
technical needs.
- are the positional capture standards (level, line weight, line code,
colour, text weight, justification) reasonable and not in conflict with
others.
Discussion continues on the following issues and decisions made will have
future impact on the spatial data modelling process:
- Spatial Metadata: Part of the business analysis step is
identifying what is the "business metadata", (i.e., information about who
collected certain data, how it was collected, etc). It does not make sense
to have common standards per se for modelling business metadata -- it
depends on the particular business needs of the area in question. This is
therefore a project-specific analysis activity, not a "should already be
included in the data modelling standards" activity. A brainstorming session
was recently held at an INCOSADA meeting at Mesachie Lake, producing the
following list of spatial metadata possibilities (this list is by no means
complete):
- identity of the person who captured the data
- identify of the person who entered the data
- method used and accuracy
- before and after feature creation
- date/time of collection, capture
- data source (e.g. air photo)
- version of data source
- data photo scale
- RIC standards
- equipment used (e.g. GPS)
- Spatio-Temporal Information: adding time (or history, or
versioning) to the model is another example of a business-specific
requirement (i.e. there is no one data modelling standard for adding time).
Currently, this is resolved through project-specific analysis.
- Topology: the current spatial model does attempt to support
topology by including a table where "rules" could be stored to say, for
example, that a road cannot intersect a lake (notwithstanding a bridge or
flooding) or perhaps that two forest district boundaries must be adjacent.
The idea, however, is to provide structures which could be used to build
topology and provide a check for spatial data integrity.
For more information, contact
Jeremey Janzen in the Data Administration group, or
Bill Unwin, the Spatial Database
Administrator..
|
