Software Project Management in Practice
3.1 Features and properties
GML is an XML encoding for geographic features. In order to correctly interpret a GML document it is necessary to understand the conceptual model that underlies GML, which is described in the OGC Abstract Specification. 3.1.1 Object Model
A geographic feature is essentially a named list of properties. Some or all of these properties may be geospatial, describing the position and shape of the feature. Each feature has a type , which is equivalent to a class in object modeling terminology, such that the class-definition prescribes the named properties that a particular feature of that type is required to have. So a Road might be defined to have a name , a surface-construction, a destination, and a centreLine. The properties themselves are modeled in UML as associations , or as attributes , of the feature class. The feature property type is given by the rolename from an association, or by the attribute name . The values of the properties are themselves also instances of defined classes or types. So the Road name is a text-string, the surface-construction might be a text token selected from an enumerated list, the destination is another feature of type Town, and the centreLine is a LineString, which is a geometry property . In UML it is partly a matter of taste whether a property is represented as an association or attribute, though it is common for a property with a complex or highly structured type to be modeled as an association, while simple properties are typically class attributes. If the value of a property only exists in the presence of the feature, such as the Road name, then it may use either a UML composition association or be represented as an attribute, as these two methods are functionally equivalent. However, if the value of a property is loosely bound to the object and the property value is an object that might exist independently of the feature, such as the Town that is the destination of a Road, then it must use a form of UML association called aggregation (see Figure 3.1). Figure 3.1. Composition and aggregation relationships
3.1.2 XML encoding of the object model
A feature is encoded as an XML element whose name is the feature type according to some classification. The feature instance contains feature properties, each as an XML element whose name is the property name. Each of these contains another element whose name is the type of the property value or instance; this produces a "layered" syntax in which properties and instances are interleaved. GML adopts a uniform coding convention to help distinguish properties from instances: element names that represent instances of GML classes start with an uppercase letter (e.g. Polygon), while tags that represent properties start with a lowercase letter; all embedded words in the property name start with uppercase letters (e.g. centerLineOf). 3.1.3 Functional view of the object model
From a functional perspective we can consider a property as a function that maps a feature onto a property value. A property is characterised by the input feature type and the type of the value that is returned. For example, suppose the feature type House has a String property called address and a Polygon property called extentOf . Using functional notation we can then write: address ( House ) = String extentOf ( House )= Polygon This approach can also be applied to feature collections that have features as members : featureMember ( FeatureCollection ) = Feature 3.2 Geometric properties
In general the definition of feature properties lies in the domain of application schemas. However, since the OGC abstract specification defines a small set of basic geometries, GML defines a set of geometric property elements to associate these geometries with features. The GML Feature schema also provides descriptive names for the geometry properties, encoded as common English language terms. Overall, there are three levels of naming geometry properties in GML:
The formal and descriptive names for the basic geometric properties are listed in Table 3.1; these names appear in the Feature schema to designate common geometric properties. The precise semantics of these geometry properties (e.g. "What does position of an object mean?" or "Are location and position synonymous?" ) is not specified. Table 3.1. Basic geometric properties
There are no inherent restrictions in the type of geometry property a feature type may have. For example, a RadioTower feature type could have a location that returns a Point geometry to identify its location, and have another geometry property called extentOf that returns a Polygon geometry describing its physical structure. A geometric property can be modeled in UML as an association class. Figure 3.2 illustrates how the geometryProperty relation associates an abstract feature type with an abstract geometry type. Figure 3.2. Geometric properties as instances of an association class
In Figure 3.2 we also see that a pointProperty is a concrete instance of GeometryProperty that links a feature instance with a <Point> instance. An important point needs to be emphasized here: GML uses property elements to carry the role name of an association; this preserves important semantic relationships that would otherwise be difficult ”or impossible ”to infer . Such a practice also helps to maintain congruence between a GML schema and its corresponding UML model (if one exists). 3.3 Application schemas
Three base XML Schema documents are provided by GML: feature.xsd which defines the general feature-property model, geometry.xsd which includes the detailed geometry components , and xlinks.xsd which provides the XLink attributes used to implement linking functionality. These schema documents alone do not provide a schema suitable for constraining data instances; rather, they provide base types and structures which may be used by an application schema . An application schema declares the actual feature types and property types of interest for a particular domain, using components from GML in standard ways. Broadly, these involve defining application-specific types which are derived from types in the standard GML schemas, or by directly including elements and types from the standard GML schemas. The base GML schemas effectively provide a meta-schema, or a set of foundation classes, from which an application schema can be constructed . User-written application schemas may declare elements and/or define types to name and distinguish significant features and feature collections from each other; the methods used to accomplish this are presented in section 4. A set of (normative) guidelines and rules for developing an application schema which conforms with GML are given in section 5. By following these rules and deriving the types defined in an application schema from components in the base GML schemas, the application schema benefits from standardised constructs and is guaranteed to conform to the OGC Feature Model. A number of complete examples appear in section 6. The GML Geometry schema is listed in Appendix A. The <import> element in the Geometry schema brings in the definitions and declarations contained in the XLinks schema. The GML Geometry schema includes type definitions for both abstract geometry elements, concrete (multi) point, line and polygon geometry elements, as well as complex type definitions for the underlying geometry types. The GML Feature schema is listed in Appendix B. The <include> element in the Feature schema brings in the definitions and declarations contained in the Geometry schema; like the geometry schema, the Feature schema defines both abstract and concrete elements and types. |