All concepts that are defined in this section relate to the data that FDO is designed to manage and manipulate.
A feature is an abstraction of a natural or man-made real world object. It is related directly or indirectly to geographic locations. A spatial feature has one or more geometric properties. For example, a road feature might be represented by a line, and a hydrant might be represented by a point. A non-spatial feature does not have geometry, but can be related to a spatial feature which does. For example, a road feature may contain a sidewalk feature that is defined as not containing a geometry.
A schema is a logical description of the data types used to model real-world objects. A schema is not the actual data instances (that is, not a particular road or land parcel), rather it is metadata. A schema is a model of the types of data that would be found in a data store. For example, a schema which models the layout of city streets has a class called Road, and this class has a property called Name. The definition of Road and its associated classes constitute the schema.
A schema override comprises instructions to override the default schema mappings. For example, an RDBMS-type FDO provider could map a feature class to a table of the same name by default. A schema override might map the class to a differently named table, for example, by mapping the "pole" class to the "telco_pole" table.
A Schema Mapping is a correspondence between a Schema Element and a physical object in a data store. For example, OSGeo FDO Provider for MySQL maps each Feature Class onto a table in the MySQL database where the data store resides. The physical structure of data stores for each FDO provider can vary greatly, so the types of Schema Mappings can also vary between providers. Each provider defines a set of default schema mappings. For example, OSGeo FDO Provider for MySQL maps a class to a table of the same name by default. These defaults can be overridden by specifying Schema Overrides.
What Are Elements of a Schema?
A schema consists of a collection of schema elements. In the FDO API, schema elements are related to one another by derivation and by aggregation. An element of a schema defines a particular type of data, such as a feature class or a property, or an association. For example, a feature class definition for a road includes the class name (for example, Road), and the class properties (for example, Name, NumberLanes, PavementType, and Geometry).
A class type is a specialization of the base FDO class definition (FdoClassDefinition). It is used to represent the complex properties of spatial and non-spatial features.
A feature class is a schema element that describes a type of real-world object. It includes a class name and property definitions, including zero or more geometric properties. It describes the type of data that would be included in object instances of that type.
A property is a single attribute of a class and a class is defined by one or more property definitions. For example, a Road feature class may have properties called Name, NumberLanes, or Location. A property has a particular type, which can be a simple type, such as a string or number, or a complex type defined by a class, such as an Address type, which itself is defined by a set of properties, such as StreetNumber, StreetName, or StreetType.
There are five kinds of properties: association properties, data properties, geometric properties, object properties, and raster properties.
Individual properties are defined in the following sections.
What Is an Association Property?
The FdoAssociationPropertyDefinition class is used to model a peer-to-peer relationship between two classes. This relationship is defined at schema creation time and instantiated at object creation time. The association property supports various cardinality settings, cascading locks, and differing delete rules. An FDO filter can be based on association properties and FdoIFeatureReader can handle associated objects through the GetObject() method.
A data property is a non-spatial property. An instance of a data property contains a value whose type is either boolean, byte, date/time, decimal, single, double, Int16, Int32, Int64, string, binary large object, or character large object.
Dimensionality, and the concept of dimension, has two different meanings in the discussion of geometry and geometric property.
The first is called shape dimensionality, and it is defined by the FdoGeometricType enumeration. The four shapes are point (0 dimensions), curve (1 dimensions), surface (2 dimensions), and solid (3 dimensions).
The other is called ordinate dimensionality, and it is defined by the FdoDimensionality enumeration. There are four ordinate dimensions: XY, XYZ, XYM, and XYZM. M stands for measure.
An instance of a geometric property contains an object that represents a geometry value. The definition of the geometric property may restrict an object to represent a geometry that always has the same shape, such as a point, or it could allow different object instances to have different dimensions. For example, one geometric property object could represent a point and another could represent a line. Any combination of shapes is permissible in the specification of the geometric types that a geometry property definition permits. The default geometric property specifies that an object could represent a geometry that is any one of the four shapes.
With respect to ordinate dimensionality, all instances of a geometric property must have the same ordinate dimension. The default is XY.
Geometric property definitions have two attributes regarding ordinate dimensionality: HasElevation for Z and HasMeasure for M.
A geometry is represented using geometric constructs either defined as lists of one or more XY or XYZ points or defined parametrically, for example, as a circular arc. While geometry typically is two- or three-dimensional, it may also contain the measurement dimension (M) to provide the basis for dynamic segments.
The geometry types are denoted by the FdoGeometryType enumeration and describe the following:
- Point
- LineString (one or more connected line segments, defined by positions at the vertices)
- CurveString (a collection of connected circular arc segments and linear segments)
- Polygon (a surface bound by one outer ring and zero or more interior rings; the rings are closed, connected line segments, defined by positions at the vertices)
- CurvePolygon (a surface bound by one outer ring and zero or more interior rings; the rings are closed, connected curve segments)
- MultiPoint (multiple points, which may be disjoint)
- MultiLineString (multiple LineStrings, which may be disjoint)
- MultiCurveString (multiple CurveStrings, which may be disjoint)
- MultiPolygon (multiple Polygons, which may be disjoint)
- MultiCurvePolygon (multiple CurvePolygons, which may be disjoint)
- MultiGeometry (a heterogenous collection of geometries, which may be disjoint)
Most geometry types are defined using either curve segments or a series of connected line segments. Curve segments are used where non-linear curves may appear. The following curve segment types are supported:
- CircularArcSegment (circular arc defined by three positions on the arc)
- LineStringSegment ( a series of connected line segments, defined by positions are the vertices)
There are currently no geometries of type “solid” (3D shape dimensionality) supported.
The FdoIConnection::GetGeometryCapabilities() method can be used to query which geometry types and ordinate dimensionalities are supported by a particular provider.
An object property is a complex property type that can be used within a class, and an object property, itself, is defined by a class definition. For example, the Address type example described previously in the Property definition. An object property may define a single instance for each class object instance (for example, an address property of a land parcel), or may represent a list of instances of that class type per instance of the owning class (for example, inspection records as a complex property of an electrical device feature class).
A spatial context describes the general metadata or parameters within which geometry for a collection of features resides. In particular, the spatial context includes the definition of the coordinate system, spheroid parameters, units, spatial extents, and so on for a collection of geometries owned by features.
Spatial context can be described as the “coordinate system plus identity.” Any geometries that are to be spatially related must be in a common spatial context.
The identity component is required in order to support separate workspaces, such as schematic diagrams, which are non-georeferenced. Also, it supports georeferenced cases. For example, two users might create drawings using some default spatial parameters (for example, rectangular and 10,000x10,000), although each drawing had nothing to do with the other. If the drawings were put into a common database, the users could preserve not only the spatial parameters, but also the container aspect of their data, using spatial context.
For more information about spatial context, see Spatial Context.
A data store is a repository of an integrated set of objects. The objects in a data store are modeled either by classes or feature classes defined within one or more schemas. For example, a data store may contain data for both a LandUse schema and a TelcoOutsidePlant schema. Some data stores can represent data in only one schema, while other data stores can represent data in many schemas (for example, RDBMS-based data stores, such as MySQL).