The Clayoquot Sound covers a 264,000 ha area on the west coast of Vancouver Island, British Columbia. The government made a decision regarding what kind of land use will be permitted in various parts of the Sound. The study area refers to the entire Sound, as covered by the decision. It is broken into a series of decision units, each of which has an allowed use, such as integrated management, wildlife, recreation, etc. It was of interest to compare the decision units with present land use / land cover (PLU) as determined through a baseline thematic mapping program based on very recent satellite imagery and digital topography. For each PLU unit, the actual use category is given, as well as a summary of topographic statistics (average elevation, average slope, percent of area facing each compass direction, etc.).
On Figure 2-4 many of the class names are followed by two colons and the letters CS. The letters give the name of the schema. The schema name must always follow the class name (separated by two colons), if the class is not part of the SAIF data model or standard schema.
The figure shows that a PLU unit is considered as a spatiotemporal entity, that is, both a spatial entity and a temporal entity. Because it occupies a region of space, it clearly is a spatial entity. Because the PLU category pertaining to the unit is with respect to the date of the satellite imagery, the unit may be considered a temporal entity as well. In other words, only at the time the image was taken can we claim that the present land use is as specified. (The next day fires or logging may have altered it.) If time referred to anything other than mere existence, such as date of harvesting or replanting, then we would not consider the object in question to be a temporal entity. (In this case the object might have two explicitly stated attributes, harvestingTime and replantingTime, each of which would come from the domain Date.)
As shown on Figure 2-4, a PLU unit has an instance of SpatiotemporalObject. (Although not shown, spatiotemporal objects include geometry and time. For this project, geometry and time are restricted to come from the classes Polygon and Date, respectively.) Each PLU unit also has a value from the enumeration PLUCategory. A series of topographic attributes are given for the unit, including the percent of the area facing various aspect directions, the average slope, average elevation, etc. The domains for these attributes are not specified; because the attributes are given in the lower part of a box, they are all primitives of some type. A PLU unit also has two explicitly given attributes, pluArea and pluPerimeter.
On the left side of the figure can be found StudyArea. This class has only one instance, the entire Clayoqout Sound study area. It contains a series of instances of DecisionUnit. (Although not shown, for each decision unit the geometry is restricted to come from the class Polygon.) A decision unit also has a value from the enumeration AllowedUse, as well as the attribute decisionUnitArea.
The decision units were overlayed with the PLU units, creating a large number of resultant units, each a member of the class DecisionPLUOverlay. Objects in this class inherit all the attributes from the two parent classes, DecisionUnit and PLU. It might be expected that the new class would contain two attributes pertaining to geometry and two attribute pertaining to spatialReferencing, since both DecisionUnit and PLU should contribute one copy of each to this new class. However, because Decision Unit and PLU are both subclasses of the sampe parent (GeographicObject), virtual inheritance is automatically assumed. With virtual inheritance only one copy of an attribute is retained, even if it is inherited many times from a common ancestor.
(The class DecisionPLUOverlay has three area attributes: decisionPLUArea, decisionUnitArea, and pluArea. Only the first of these is likely to be considered of interest; the other two relate to the original polygons. Additionally, pluPerimeter is also inherited and is also of questionable value. To minimize such confusion, the attributes area and perimeter could have been added to a higher level class and then inherited by DecisionUnit, PLU, and DecisionPLUOverlay. By virtual inheritance, DecisionPLUOverlay would have only one area attribute. )
Another analysis on Clayoquot could involve comparing satellite images of various years to monitor the changes in the area. The resulting units from the overlay of the different snapshots might initially contain all the information of the parents, and in this case, the overlay would be comparable to what was described above. However, if the overlay involved change detection processing such that only changed areas are depicted, we would have a very different situation, since the resultant units would not be able to respond to all the queries which could be directed to the original units. Multiple inheritance would be inappropriate.
One way to model this change detection work would be as follows. All the PLU units for each time could be placed in a partitioned coverage, with position specified as a spatiotemporal object. For example, define a LandUseAtTimeX class in this way. The various coverages at different times (that is, instances of this new class) could then be placed in a geographic composite. Define LandUseThroughTime as a subclass of GeographicComposite.) This new composite can be visualized as a multilayer structure, where each layer is a time tagged coverage of the same area. The change decection process will determine that a number of areas have been altered. These areas belong to a new class, AlteredArea. The altered areas can be put into a final coverage containing all the altered areas. An instance of this new coverage belongs to the class DetectedChanges, defined as a subclass of PartitionedCoverage. The relationship between objects belonging to DetectedChanges and those belonging to LandUseThroughTime can be stated explicitly with the relationship DerivedFrom, a class in the SAIF standard schema, or a user-defined subclass of that class. Alternatively, appropriate metadata can be defined under the class Lineage in the SAIF standard schema.