Feature Subsystem Development
Status: alpha (2008/10/06)
1. Basic concepts
The object model of deegree 3 is a generalization of the deegree 2 feature model. Not only is it suitable for representing (simple or complex) GML features, but also for arbitrary object types that are defined by XML schema documents. This is mostly motivated by the finding that a class of data-centric OGC webservices exists (deegree featureService, deegree catalogueService or deegree sensorObservationService), that use objects (features, records or observations) in a very similar manner. In deegree 2, (persistent) objects are always represented using feature objects that are designed to match the original object structure closely. However, for some WFS application schemas, CatalogueService schemas or the SensorObservationService schemas, there's a gap between the possibilities of the deegree 2 feature model and the requirements of the application. That's why deegree 2 services often use XSLT-scripts to map between the original application schema and an internal WFS application schema. In deegree 3, we try to eliminate the need for these kinds of mapping by using a more general object model.
2. Use cases
Load a complex GML feature collection document with schema information and provide a convenient and type-safe access to the structure of the contained features. Programmatic modifications to features and properties can be checked for validity.
Load a complex GML feature collection document without schema information and provide a convenient access to the structure of the contained features. This is basically a feature-property view of the feature contents and a senseful representation of GML elements (geometries and other).
Load a generic XML document with schema information and provide a convenient and type-safe access to the document structure. Programmatic modifications to the contents can be checked for validity.
The loading of generic XML documents without schema information is not considered a use-case, because it is not possible to offer more functionality than a generic tree based XML API (DOM, JDOM, AXIOM, etc.).
Load a complex GML feature collection with schema and persistence information and store it in an SQL database.
- A collection of features is styled using SLD information to draw a map. This process involves the evaluation of filter expressions and the access to (geometry and non-geometry) properties. The necessary functionality is offered by the object model.
The object structure is usually defined by an XML/GML schema document. The class of processable schemas in deegree 3 is not restricted to follow the object/property model of standard GML application schemas.
- The objects usually contain (GML) geometries.
- It must be possible to filter collections of objects using OGC Filter-expressions (Common Query Language, CQL), therefore the evaluation of XPath-expressions must be supported by the object model.
- If the objects are stored in a datastore (persistent objects), there is the need for queries (based on CQL) and transactions (insert, update and delete). This is handled by the new datastore layer which is based on the new generic object model.
4. XML semantic
An important requirement is that the new object model must be capable of representing any kind of XML structure. We target this requirement by a very lean hierarchy of Java interfaces that describes the inherent XML structure of a deegree object.
Every "deegree object" (e.g. a feature or a catalogue record) implements this interface. This allows us to implement commonly needed functionality by writing generic code (that only works on this interface) for:
- Evaluating XPath-expressions
- Exporting a deegree object to its XML representation
5. Why DOM, JDOM, AXIOM, etc. are not suitable to represent our objects
It should be noted, that the above requirements are already fulfilled by general XML-APIs such as DOM, JDOM, AXIOM, etc. However, these requirements are not the only ones that our object model must to provide. The most important requirements that are not fullfilled by using a generic XML representation are:
It is often not feasible to describe the full XML structure explicitly (as a tree of nodes). Especially GML geometries require a more compact internal representation that also supports spatial operators. These geometry elements should be represented using the deegree 3 geometry model.
- The "XML view" (elements, attributes and text nodes) of a deegree object is not always suitable for a geospatial application. If the represented object is a GML feature, it is necessary, that the object class offers methods to access the content of it's properties directly. In other words, a "feature view" is needed for this major class of deegree objects.
- It is necessary to have access to the corresponding type information for each particle of a deegree object. Why? Support for constructing valid object instances, schema validation, persistence information, configurable representation,...
6. Feature API
A completely generic model that allows the representation of arbitrary XML structures with type (and persistence information) is very desirable, so non-feature structures can be represented and stored without the need to map between the external XML application schema and an internal feature-property structure (this is done in deegree 2 via XSLT).
However, the most common form of a geoobject is a (GML) feature. Thus, a convenient and powerful API that enables the easy processing of features and feature types is needed as well.
At the moment, it is not completely clear how the relation between the XML view and the feature view is realized best. It should be noted that a feature often has several equivalent XML representations.
6.1. Complex features
- Problem: Ambiguity in interpretation: featureMember / featureMembers properties.
- Respect differences between GML 2 / 3.1 and 3.2
- Resolving of XLinks
6.4. Retrieving feature types from GML application schemas
6.4.1. How to determine feature type declarations
It is important to realize that the term "type" is somewhat confusing in the context of GML schemas. A feature type declaration corresponds to an element declaration in XML schema and not the complexType declaration that actually defines the content model (the properties) of the feature type.
Also, there are some notable differences between different versions of the GML standard (core schemas):
GML 2 - 3.1.1: Corresponding complexType must use extension base="gml:AbstractFeatureType" (see ...).
GML 3.2: Corresponding element declaration must use substitutionGroup="gml:AbstractFeature" (see OGC 07-061, section 6.4).
6.4.2. Processing property declarations
Problem: GML schemas often restrict complex properties to be inline-only or external-only. How does this relate to the feature type information? It could either be stored with the FeatureType object or separately, i.e. in an object that holds such additional (maybe GML and version specific) information. There are other types of information that may be stored there as well, such as the GML specific geometry type. Maybe this could be used to handle other GML-version differences (standard properties) as well. gml:featureMember/gml:featureMembers?
6.4.3. Status of GMLApplicationSchemaXSDAdapter
6.4.4. Philosopher (standard example from deegree2)
Works fine out-of-the-box. However, it's better to use typesafe property declarations now that were not possible with the deegree 2 GML schema parser. Such property declarations look like this:
<xsd:element name="Philosopher" type="app:PhilosopherType" substitutionGroup="gml:_Feature"/> <xsd:complexType name="PhilosopherType"> <xsd:complexContent> <xsd:extension base="gml:AbstractFeatureType"> <xsd:sequence> ... <!-- feature property 'placeOfBirth', with typesafe definition (must contain 'app:Place' feature) --> <xsd:element name="placeOfBirth" type="app:PlacePropertyType"/> ... </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="PlacePropertyType"> <xsd:sequence> <xsd:element ref="app:Place" minOccurs="0"/> </xsd:sequence> <xsd:attributeGroup ref="gml:AssociationAttributeGroup"/> </xsd:complexType>
6.4.5. IMRO 2008
Works mostly. Some problems remain that are basically caused by some issues with the schema document itself.
The FeatureCollectionIMRO element declaration can not be recognized automatically as a feature collection or feature declaration, because it derives from "gml:_Object", not "gml:_FeatureCollection" or "gml:_Feature":
<element name="FeatureCollectionIMRO" type="imro:FeatureCollectionIMROType" substitutionGroup="gml:_GML"/> <complexType name="FeatureCollectionIMROType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence minOccurs="0" maxOccurs="unbounded"> <element name="featureMember"> <complexType> <sequence> <element ref="gml:_Feature"/> </sequence> </complexType> </element> </sequence> </extension> </complexContent> </complexType>
Feature properties are not recognized automatically as such, because the reference to the value feature element declaration is commented out:
<complexType name="Besluitsubvlak_APropertyType"> <attributeGroup ref="gml:AssociationAttributeGroup"/> <!-- <sequence minOccurs="0"> <element ref="imro:Besluitsubvlak_A"/> </sequence> --> </complexType>
6.4.6. IMRO 2006
Works fine out-of-the-box.
6.4.7. XPlanGML 2.0
Works mostly. The only observed problem is the definition of feature properties which uses an annotation to specify the value feature type:
<xs:element name="gehoertZuBereich" type="gml:ReferenceType" minOccurs="0"> <xs:annotation> <xs:appinfo> <adv:referenziertesElement>xplan:XP_Bereich</adv:referenziertesElement> </xs:appinfo> </xs:annotation> </xs:element>
This makes it impossible to determine the value feature types automatically.