As previously discussed, the actual use of the SAIF data model (and SAIF standard schema) to represent a specific application requires extensions through subclassing. As with the SAIF standard schema, a user defined schema must be expressed in a text based language. This section explains how to define a schema using the Class Syntax Notation. Further detailed information about CSN is available in Chapter 4.
The following material focuses on examples taken from the TRIM schema, which describes types defined for 1:20 000 topographic data in British Columbia. The examples include the definition of subclasses of GeographicObject and GeographicComposite, as well as various types of enumerations.
The first line in the example begins with an angled bracket and gives the name of the superclass from which it is derived, in this case GeographicObject. The angled brackets are used to indicate the beginning and end of a class definition. The second line in the example provides the name of the subclass being defined and the name of the schema containing the class definition. In this case the subclass is Feature and the schema is TRIM, and they are separated by two colons. The complete name of the subclass is considered to be: Feature::TRIM.
In general, the next step in subclassing would be to define attributes for the objects belonging to the Feature subclass; however, in this example there are no object attributes. Note that as a subclass of GeographicObject, Feature inherits all of the characteristics associated with a GeographicObject. (See Chapter 3 for the definition of GeographicObject.)
Feature also has the class attributes validDEM, positional and representational. Since Feature is the class from which all feature classes in the TRIM schema are subclassed, these class attributes and their values are implicitly carried by virtually all the TRIM classes. As with defining ordinary attributes, classAttributes require a domain to be supplied for each attribute; in this case each domain is Boolean.
This sample definition also has a restricted clause, which as previously described, can be simple or complex. The restriction referring to space.spatialReferencing is necessary because, as a subclass of spatialEntity, Feature inherits this attribute through the complex domain SpatialObject.
The latter three phrases in the restricted clause refer to a specific format that must be used for the storage of numeric coordinates, regardless of the specific geometry. They state that wherever the class CoordXYZ is used by geometry, then the x, y, and z values are given as 32 bit integers. If the specific geometry were known, then the same domain restriction could be stated by providing a complete path with the variable, instead of using the wildcard approach with the asterisk. For example, if the geometry was specified as from the class Point, then the phrase involving x could be stated as: position.geometry.position.x: Integer32. The formal syntax of the restricted clause is described in detail in Chapter 4.
The values for the class attributes validDEM, positional, and representational are each set to true in the classAttributeDefaults clause. These values will be passed to every subclass of Feature, unless explicitly overridden in the definition of a subsequent subclass. If the classAttributeValues clause had been used instead of the classAttributeDefaults clause, the values could not be overridden.
The final clause in this example is the comments. Comments are provided as a means to document the intended use of the classes that have been defined and to explain the semantics of the information encoded within the class structure. In the example the comments provide some background regarding the structure of TRIM and help to explain the restricted clauses. The comments must be enclosed in double quotation marks ( ) . The class definition ends with a closing angled bracket (>>).
The example that follows concerns the class Road, a subclass of Feature. Two enumerations are defined first, as they are required as domains of attributes in the Road definition. SurfaceType and TravelDirection illustrate how to create new enumerations by subtyping directly from Enumeration. As before, class and enumeration definitions start and end with angled brackets. Also as before, the schema containing the types must be specified, as TRIM is an external schema.
After the subclass clause (and tag clause, if used) in an enumeration comes the values clause, listing the possible descriptions which may apply to an object. In our first example the descriptions represent the surface types that a road may have, according to the TRIM schema. As with every subtype there is also a comments component which is used to clarify the enumeration and the terms within it.
The definition of Road begins with an opening bracket and the name of the superclass, in this case Feature::TRIM. The subclass name follows. Again the subclass name must include the schema. As a subclass of Feature::TRIM, Road::TRIM inherits all the attributes, restriction and defaults from its superclass. An attributes clause is used to specify new attributes and their associated domains. The first new attribute is surfaceType and the domain specified is SurfaceType::TRIM, as previously discussed. Syntactical concerns include: the use of a lower case letter to begin the name of the attribute and the use of an upper case letter to begin the domain. Also, the attribute name is enclosed in square brackets ([ ]), indicating that entry of values for the attribute is optional.
All of the new attributes for Road::TRIM are considered as optional, as indicated by the brackets. Note that the attribute travelDirection has a domain defined within the TRIM schema (TravelDirection) while the remaining attributes have primitive domains defined within the SAIF data model. Integer8 is any integer of 8 bits in length (with possible values ranging from -128 to +127), while Boolean identifies a logical value (true or false).
If specific values for these attributes are not supplied, the default values defined in the next clause of the definition apply. This means that unless otherwise specified, surfaceType will be paved, numberOfLanes will be 2, travelDirection will be twoWay, and the road will be considered as not divided and not under construction. Each of the default values supplied must come from the appropriate domain defined above. If values are not given for an optional attribute, no values are encoded, regardless of whether or not defaults are specified. The receiver of the data will understand the implied values through the definition of the class.
The first restricted phrase (position.geometry:^Arc) requires that the geometry attribute must be a direct instance of the class Arc, and not one of the subclasses of Arc. The second restricted phrase (position.geometry*Coordinate:^CoordXYZ) further specifies that the coordinates which define the position of the Arc must be direct instances of the class CoordXYZ. The third restricted phrase refers to the attribute, numberOfLanes; the restriction applies to possible numeric values which may be applied to the attribute. The vertical line, ( | ), separates valid alternative values, in this case, 1, 2, 3, 4 or 6. Any other values are not legal.
As previously noted, restricted clauses have a very rigid formal syntax. The next statement is the constraints clause. which does not have a formal syntax and is meant to convey the meaning of information that may be too complex for expression in the restricted clause. In this case the constraints, given in double quotes, are related to the way in which the data were captured. The constraints clause contains the information that in TRIM digital files, cart tracks are not captured unless their length exceeds 400 metres. The last clause in the example, the comments, provides a general understanding of what a Road is and gives an example of how this class of objects may typically be used.
The remaining two examples illustrate the use of GeographicComposite, a subclass of GeographicObject. Instances of this class are geographic objects which contain other geographic objects. Instances of a composite class may be considered as containers, which may or may not have other attributes provided. The following example shows the definition of a spatial composite class dealing with land transportation.
As with all subclass definitions, this one opens with an angled bracket and the name of the superClass. The subclass name including the schema follows (RoadsAndRailways::TRIM). The subclass RoadsAndRailways has no new attributes but it has inherited position (geometry and spatialReferencing) from GeographicObject, as well as components from GeographicComposite. (See Chapter 3 for the definition of GeographicComposite.)
Most of the information in the definition is given in the restricted clause. The first restriction sets the value for position.geometry to nil. (This may not be the case, for example, if the spatial composite were of the class Park consisting of spatialComponents of lakes, forest stands and rivers. A park could have a position defined independently of the components it contains.) The attribute spatialReferencing is restricted in this case to Georeferencing::TRIM which provides a mapsheet indicator and the coordinate system being used ( UTM in the case of TRIM).
In the class definition of GeographicComposite, components has a domain defined as Multiset(GeographicObject). The next restriction (components:Set) states that a set is used to contain the geographic objects, and not a list, isolist, isoset, or relation. Because there are different types of objects in the components, Set may be specified, but not IsoSet. Set is used instead of List because the order of objects within the multiset is not meaningful. (Note that a SAIF profile may state that a certain order of objects must be used in order to ensure efficient processing. Nevertheless, in class definitions with a multiset domain for an attribute, the multiset should only be defined as a list or isolist if the order is inherently meaningful in terms of an understanding of the objects belonging to the class.)
The next restriction ( components{}: Bridge::TRIM.... ) provides the types of GeographicObject that may serve as the domains for objects included in components. Six types are specified: Bridge, RailLine, Road, Snowshed, Tunnel, and Turntable. The braces ( {} ) after the word components represent the syntax for referencing the members within the multiset.
Mapsheet, the final example, is a subclass of SpatialDataSet. An attribute called metadata is specified from the domain MapsheetMetadata::TRIM. Each mapsheet in the TRIM database has its own metadata object which is an instance of MapsheetMetadata::TRIM. MapsheetMetaData::TRIM provides quality assurance information and other information pertinent to a particular mapsheet.
The comments clause tells us that each object belonging to this class represents all the data pertaining to a given mapsheet in the British Columbia 1:20 000 topographic mapping program. Although not shown here, subclass of SpatialDataSet is defined, consisting of all such data for the entire province; at that level we have a single geographic object which contains all 1:20 000 topographic data for British Columbia.
In this particular example, the concept of a mapsheet is emphasized, as the 1:20 000 topographic data is currently being managed on a mapsheet basis. Whether or not a user wishes to do this is entirely a modelling decision. The user may wish to define a series of composite or coverage classes based on other criteria, or may find that her requirements are met without composites or coverages.