DATAISSU.TXT - 7th of 19 digital documentation files distributed
               with the "Forest Fire Chronology of Saskatchewan"
               (FFCS) dataset.


<Document overview>

     Describes data handling and GIS issues pertinent to the FFCS
     dataset such as database normalization, use of regions,
     vertical integration, and derived data.


<Normalizing the dataset>

     The year-by-year coverage nomenclature currently employed
     with this dataset is not reflective of a normalized
     database.  A normalized dataset would have the fire year as
     a field in the master coverage rather than in the coverage
     name.  Alternatively, GISs that have functionality similar
     to that of Arc/INFO version 7.X "regions" could be used:

          'Regions can be used like polygons, but they more
          efficiently represent complex area features that
          overlap, composite area features composed of many
          polygons, and multiple classes or area features that
          share common boundaries.' (Source: ESRI, Arc/INFO
          v7.0.3 on-line documentation)

     Thus, "regions" would allow combining all fire coverages
     into sub-regions of one comprehensive coverage.  There are
     several reasons against using a normalized or "region"alized
     database approach for distributing the FFCS.

     First, many GIS packages or geographic data viewing
     utilities lack "region"-like functions.  Second, a
     normalized database would result in awkward data handling:
     if all fire year coverages are placed into a single
     coverage, then the resultant master coverage would have a
     large number of tiny polygons.  Each of these wedges would
     replicate information for every fire fragment that they
     depict.  Simple analyses such as area to perimeter ratio
     calculations for a given fire could therefore not be
     performed easily.

     Hence, the data are distributed in the individual coverage
     per year format.  Users have the option of converting the
     individual coverages into GIS "regions" or they can
     normalize the database themselves.  However, the data are
     best distributed in non-normalized form.


<Derived data>

     Database purists state that databases should not contain
     information derived from other data.  In principle, this
     approach is worthwhile.  For example, if the source data are
     altered and the derived data are not re-calculated, then the
     derived data are erroneous.  Use of derived data has other
     data management implications which are not discussed further
     here.

     The attribute database for the FFCS intentionally contains
     three derived data fields: GIS_HECTARE, GIS_SQKM, and
     NTS250.  The first reason why derived data are used is that
     this is a static database.  Other than annual updates, the
     data are not revised.  Another reason is that the derivation
     places spatial data into an aspatial database.  Those who do
     not have a GIS at their disposal can thus use the aspatial
     database that has pseudo-spatial data.  Another reason for
     use of derived data in the SK_FIRES database is that the
     derived database summarizes data out of 50 coverages.  If
     these data were not summarized, then one would have to
     search all 50 coverages for an overall picture.  Finally,
     area totals in the derived database are converted from a
     near meaningless square meter format in the source format to
     more meaningful area measurement units.

     Database purists might question the above reasoning, but
     given the relatively small size of the database, the rule of
     no derived data has been intentionally broken.  Sometimes
     theory does not satisfy practical application.


<Overlapping fire boundaries>

     As the fire chronology spans a fifty year period, many of
     the fire boundaries overlap due to repeat burns of given
     areas.  Some overlaps however, are resultant from inaccurate
     mapping of fire boundaries.  In some instances, fires
     occurring in the same year had significant boundary
     overlaps.  These fires were usually merged into one fire
     with multiple fire names stored in the database.  For
     example, fire number 1981-030 represents two fires:
     IRA/ISAAC.

     As part of their record keeping scheme, Forest Fire Management
     Branch merges fires that ignited from different sources ONLY if
     those fires are still considered active.  In a single fire season,
     however, a new fire can loverlap fires from the same season that
     were considered as "out".  This results in many fire names in the
     FFCS database containing multiple fire names.  In these situations,
     the NR22_HECTARE totals in the SK_FIRES attribute database
     usually reflect the largest fire size.


<Vertical integration with NTS 1:250,000 linework>

     At one point in the fire chronology project, the notion of
     vertically integrating fire boundaries with 1:250,000 lake
     boundaries was seriously considered.  This would have:

       1) Enabled generation of higher quality plots, as
          land/water slivers occurring due to digitizing error
          could be eliminated.
       2) Reduced database inconsistencies for analyses with
          other datasets.

     However, the vertical integration idea was rejected for
     three reasons:

       1) Water levels are not consistent from 1945 to 1995.
          Using an arbitrary snapshot in time for water
          boundaries for a 50+ year database would result in
          incorrect portrayal of water conditions at the time of
          some fires.  Inserting waterbody lines as fire
          perimeters may therefore distort the boundaries rather
          than improve them.

       2) Adjusting some burn boundaries and not others
          introduces correction inconsistencies.  Compensating
          for burn-in-water overlaps adjusts only those fire
          boundaries that are adjacent to water.  Burns that are
          not adjacent to water are not adjusted.  It is
          difficult to justify adjustments for but a subset of
          the database.  No corresponding adjustments are made
          due to other sources of error.  Area totals are
          therefore no longer consistent with other fire
          boundaries.

       3) Some slivers between fire boundaries and waterbodies
          are genuine.  To determine which slivers are real and
          which ones are not will require consulting the source
          maps.  Yet, the source maps may have been inaccurate in
          their own right.

       4) Data licensing restrictions.  SERM is prohibited from
          distributing any portion of the digital NTS250 dataset
          to non-crown agencies.



This document prepared by:

Ott Naelapea
Wildlife Branch
Saskatchewan Environment & Resource Management
Box 3003, 800 Central Avenue
Prince Albert, SK.  S6V 6G1
CANADA
(306)953-2671 - Tel.
(306)953-2750 - Fax.

November 28, 1996


Revisions:

March 31, 1997
  -added last paragraph in <Overlapping boundaries> section.
