Projected changes for SAIF 3.2 per email from Mark Sondheim to Jean Anderson.

1       SAIF DATA MODEL
=======================
 
We might consider a change to the SAIF data model in Figure 2-2.
AbstractObject, Enumeration, and Primitive should all be derived from
Type. (This will allow for value to come from either ExternalReference,
or a bit- or octet string, as in the case below.)
 
Also, we might think about adding enumerate (or enumerated value) to the
list of primitive types. (Should this be done?)
 
------------------------------------------------------------------------
2       RASTER
==============
 
The definition of raster is altered slightly. Type is now used as the
domain of contentValues. (Also, we can eliminate the classes
StructuredData and ElementStructure, as they will no longer be needed.)
 

------------------------------------------------------------------------
3       GENERAL RASTER
======================
 
The case of the general raster, e.g. imagery, topography, etc. The
general raster could also include categorical data, as maybe the case
for example in an image analysis system. For example, in such a system,
an "image" might contain several bands of raw imagery, one or more bands
of calculate value (e.g. from ratios or PCA), one or more bands of
topography, and one or more bands of categorical data (such as the
results of a classification exercise, or some external data like soil
type). The general raster allows for any combination of these cases.
 
<Raster
  subclass: GeneralRaster
 
  attributes: [indexScheme]    IndexScheme
              channels         List(Channel)
 
  defaults:   indexScheme: sequentialArray
 
  restricted: indexingScheme: sequentialArray | interleavedArray
> 
 
 
<Tuple
  subclass: Channel
 
  attributes: [channelNumber]  Integer
              [name]           String
              [description]    String
              [units]          UnitMeaning   // digitalNumber gets added
                                             // to UnitMeaning
              [instanceType]   PrimitiveInstanceType
              [bitsPerValue]   Integer      // this is here for odd
                                            // cases, such as 18 bit
                                            // data
 
  restricted: instanceType:integer8|integer8Unsigned
                           |integer16|integer16Unsigned
                           |integer32|integer32Unsigned
                           |integer64|integer64Unsigned
 
  constraints: "channelNumber must be greater than 0.
               If both instanceType and bitsPerValue are given, their
               values must correspond."
 
  comments:    " "
> 
 
------------------------------------------------------------------------
4       CLASSES AND IMPLEMENTATIONS
===================================
 
The above classes should sufficiently handle the Sequoia 2000 examples.
It can be argued that "Image" (and "Pnt" as well) are simply
implementations (equivalent to some SAIF constructs) supported
effectively in Illustra. Thus, contentValues comes from
ExternalReference which is implemented as Image in Illustra. In this
case, one can say that ExternalReference is not really being followed,
but that is being far more rigid than I personnally would require.
 
In fact, if the data were being transferred as an image in a SAIF data
stream or file, the Illustra image would be copied or simply referenced
in a SAIF/ZIP file in such a fashion that ExternalReference would be
used. (If it were referenced and not directly provided, the actual data
would remain in Illustra as an image. If the data were being
transferred, then presumably it would be exported as an octet string or
bit string. If it is being exported, then the channel definitions must
include values for either instanceType or bitsPerValue.)
 
------------------------------------------------------------------------
5       CATEGORICAL RASTER
==========================
 
In a typical geographic information system, each partitioned coverage
may be stored or transformed into a raster where the data represent
categorical descripions of the landscape. For each such raster, a
separate description should be given of the code being used, the name of
the class or category, and a description of the class or category. For
example, a 6 may represent a mature doug fir forest, which might be
described as a stand containing more than seventy percent douglas fir
greater than sixty years old.
 
<Raster
   subclass: CategoricalRaster
 
  attributes: [indexScheme]    IndexScheme
              category         List(Category)
              [instanceType]   PrimitiveInstanceType
              [indexValueType] PrimitiveInstanceType // this refers to
                               // the type of integer used to indicate
                               // the number of times a given value
                               // occurs sequentially in a series of run
                               // length encoded values, or the value of
                               // an n-tree number in a quad tree or
                               // octree (ntree) series.
 
  defaults:   indexScheme: sequentialArray
 
  restricted: indexingScheme: sequentialArray|runLengthEncoded|nTree
              instanceType:integer8|integer8Unsigned
                           |integer16|integer16Unsigned
                           |integer32|integer32Unsigned
                           |integer64|integer64Unsigned
              indexValueType: integer8|integer8Unsigned
                              |integer16|integer16Unsigned
                              |integer32|integer32Unsigned
                              |integer64|integer64Unsigned
 
  constraints: "indexValueType must be completed if
               (i)  indexScheme is either runLengthEncoded or nTree, and
               (ii) the contentValues are within the SAIF data stream"
>
 
 
<Tuple
  subclass: Category
 
  attributes: categoryNumber   Integer
              name             String
              [description]    String
 
  constraints: "categoryNumber must be greater than 0."
 
  comments:    " "
 
>
 
If there were one raster for forest cover, another for soils, etc.,
these could be combined into a SpatialDataSet. They could use the same
object identifier to signify use of the same grid, if desired.
 
------------------------------------------------------------------------
6       GRID RASTER
===================
 
We should probably eliminate the class GridDEM. A gridded dem can be
handled under GeneralRaster or a user defined subclass of it. A user
might for example want to transfer elevation, slope, aspect and
curvature, with a value for each of these attributes for each pixel.
This would be interpreted as three channels, the values for which may be
either sequential or interleaved. If the data has been transformed to
fit into values ranging from 0 to 255 for example, this would be stated,
(with or without the equations), under "description". Here and
elsewhere, if Channel is not sufficiently rich, a user could define
subclasses of it.
 
However, raster DEMs are so common that it is tempting to define a class
RasterDEM, as follows:
 
<Raster
  subclass: RasterDEM
 
  attributes: [instanceType]   PrimitiveInstanceType
 
  restricted: position.geometry.orderAndOrigin.origin:sw
              position.geometry.orderAndOrigin.ordering:rowOrder
              position.geometry.positionOfOrigin.position:CoordXY
              contentValues:ExternalReference|OctetString
              instanceType:integer8|integer8Unsigned
                           |integer16|integer16Unsigned
                           |integer32|integer32Unsigned
                           |integer64|integer64Unsigned
>
 
This is a very simple structure, which is an advantage. The disadvantage
is the creation of another class, with a slightly different structure.
Also, unlike before, a digital elevation model which is irregular is
considered as a type of geometric object (DEM), whereas if it is
regular, it is now a type of geographic object.
 
------------------------------------------------------------------------