[FrontPage] [TitleIndex] [WordIndex] 

Feature Subsystem Development

Contents

  1. Basic concepts
  2. Use cases
  3. Requirements
  4. XML semantic
  5. Why DOM, JDOM, AXIOM, etc. are not suitable to represent our objects
  6. Feature API
    1. Complex features
    2. FeatureCollection
    3. Parsing
    4. Retrieving feature types from GML application schemas
      1. How to determine feature type declarations
      2. Processing property declarations
      3. Status of GMLApplicationSchemaXSDAdapter
      4. Philosopher (standard example from deegree2)
      5. IMRO 2008
      6. IMRO 2006
      7. XPlanGML 2.0

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

3. Requirements

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.

xml_semantic.png

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:

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:

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

6.2. FeatureCollection

6.3. Parsing

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):

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.

CategoryDeegree3

2018-04-20 12:04