The FDO feature schema provides a logical mechanism for specifying how to represent geospatial features. FDO providers are responsible for mapping the feature schema to some underlying physical data store. The FDO feature schema is based somewhat on a subset of the OpenGIS and ISO feature models. It supports both non-spatial features and spatial features.
The Schema package contains a collection of classes that define the logical feature schema. These classes can be used to set up a feature schema and to interrogate the metadata from a provider using an object-oriented structure. The logical feature schema provides a logical view of geospatial feature data that is fully independent from the underlying storage schema. All data operations in FDO are performed against the classes and relationships defined by the logical feature schema. For example, different class types in the feature schema are used to describe different types of geospatial objects and spatial features.
All classes in the feature schema support the concept of base properties, which are properties that are pre-defined either by the FDO API or by a specific FDO feature provider. For example, all classes in the schema have two base properties: ClassName and SchemaName. These properties can be used to query across an inheritance hierarchy or to process the results of heterogeneous queries. FDO feature providers can also predefine base properties. The following base properties are predefined by the FDO API:
Some FDO feature providers may support multiple schemas. For these providers, the feature schema supports the concept of cross-schema references for classes. This means that a class in one schema may derive from a class in another schema, relate to a class in another schema, or contain an object property definition that is based on a class in another schema.
Parenting in the Schema Classes
The feature schema object model defined in the FDO API supports full navigation through parenting. That is, once a schema element is added to an FdoFeatureSchema class, it can navigate the object hierarchy upward to the root FdoFeatureSchema and, from there, to any other element in the feature schema. This parenting support is fully defined in the FdoSchemaElement abstract base class.
When inserting features that have object collections, the parent object instance must be identified when inserting the child objects (for example, a parent class “Road” has an object property called “sidewalks” of type “Sidewalk”). For more information, see Data Maintenance.
Each feature provider maps the logical feature schema to an underlying physical data store. Some feature providers may provide some level of control over how the logical schema gets mapped to the underlying physical storage. For example, an RDBMS-based feature provider may allow table and column names to be specified for classes and properties. Since this is entirely provider-dependent, the FDO API simply provides abstract classes for passing physical schema and class mappings to the provider (FdoPhysicalSchemaMapping, FdoPhysicalClassMapping, FdoPhysicalPropertyMapping, and FdoPhysicalElementMapping, respectively). The implementation of these abstract classes is up to each feature provider.