GeoTools : Enhancement requirements

Enhancement requirements

Supporting all the features mentioned above seems like a lot of work. We have, though, a driven specification that will help limit scope. Actually it's an OGC discussion paper, but is what the project stakeholders are interested in for the short time: Level 0 Profile of GML3 for WFS.

Minimum requirements: Level 0 Profile of GML3 for WFS

The intent of that document is to specify the encoding of application schemas sufficiently so that WFS client implementations do not need to deal with the entire scope of XML-Schema and GML but only need to understand a restricted subset of both specifications in order to be able interpret schema document s
generated in response to a DescribeFeatureType request.

Among other things, it defines the essential geometry and simple types that a system must support to achieve a minimum level of interoperability.

From the mentioned discussion paper, table 4, page 21, the following are the allowed geometry types:

GML Geometric Property Type

Defined in GML Schema File







only LineString allowed as value



only Polygon allowed as value



only MultiLineString allowed as value



MultiPolygon and MultiSurface allowed as value; MultiSurface can use only linear (sub)geometries



this was missing in GML- 2 and has justifiably been added to GML- 3



only LinearRing or Ring with LineStrings can appear as value

That's good, we already handle most of them.
As for simple types, section 7.5.2 Basic Data Types, page 26, limits the set of available basic types to a smaller subset. The rational being that a smaller common set of supported basic data types is likely to be more interoperable.

The list of supported basic data types is:

  1. Integers, limited to integer data type with no limit on applyable facets
  2. Reals, limited to decimal, float and double and totalDigits and fractionDigits facets
  3. Character strings, to string type and maxLength facet
  4. Date, limited to date and dateTime data types with no restriction on facets
  5. boolean data type
  6. Binary data, both base64Binary and hexBinary, with no restriction on facets, and the aggregate of the attributes url, mimeType, and role, as specified in the following fragment:
    <xs:element name="propertyName" minOccurs="0|N" maxOccurs="0|N|unbounded">
       <xs:extension base="xs:base64Binary|xs:hexBinary">
        <xs:attribute name="url" type="xs:anyURI" use="optional"/> <!-- when referenced from an external URI -->
        <xs:attribute name="mimeType" type="xs:string" use="required"/> <!-- must be specified to indicate the type or format of binary data that is being
    referenced -->
        <xs:attribute name="role" type="xs:string" use="optional"/> <!-- can be used to assign a user-defined 
    role to the data. The role attribute allows complex binary format s like HDF/EOS, 
    which contains multiple independent binary component s, to be supported. -->

(lightbulb) so we may be able of coming back with a flexible design that addresses this essential requirements and leaves place for the wider implementation of the rest.

Be careful


GML Level 0 profile is about simple features, so the explanation above aplies only to the simple attributes support requirements. We still need to support multiple geometric attributes, related features, and complex attribute types.

Requirements break down:

Simple support for simple types

It is not a requirement (at least for this phase of the project) to cover all the mappings between simple types to the predefined XML Schema simple types.
It is enough to count with a well known set of java to xml bindings, like Integer->xs:int, String->xs:string, Date->xs:date, etc.

There is no need of having mappings to XML Schema list and union simple types.

Keep it simple.

The majority of available data sources are producers of Simple Features. So the API shuold be kept simple enough that it adds no significant complexity for simple cases.

Separation of concerns

We have discovered that the current approach has difficulties to express, in a single type hierarchy, what the valid structure of a type instance is, and what's the exact type of each of the components of such an instance.
The new model must be able of:

  1. specify the type (name, value range, nillability) of a property
  2. state the content model of a type (multiplicity and tree structure)
  3. provide an unambiguous containment model

Multiple namespaces

A type always belongs to a namespace. A nested object type may belong to a different namespace than its parent.

Identity beyond Feature

Not only Feature instances has identity (for Feature, it is its FID). It should be possible to define a type hose values has a unique identifier inside its namespace. These are always complex types.
A common case are Geometries. Two or more Features may share the same Geometry. In GML, Geometries are allowed to have an id. So both Features may share the same geometry value, by reference.

Make explicit the association type pattern.

A Feature property follows the association type pattern. A Geometry property too. In fact, all Feature attributes whose type is defined externally to the feature's type, or internally but may have identity, should be referenced by an association element. That's what will allow to reference a remote value instance.

Derived types

All the types that can be defined are derived from another one. If it is a simple type, it derives from a primitive type. It is a complex type, either it derives from gml:_Object, or if it may have identity, derives directly or indirectly from gml:AbstractGMLType.
There are some well known abstract supertypes for well known type hierarchies, like for Geometries and Features.

Type hineritance is limited to single hinherintance.

Setting a requirement for a type to return its super type (i.e. getParent():Type) may be overkill, since due to cross namespace hinheritance, it would be the task of a repository of types to obtain a type instance. But due to the use of qualified names to identify types, a given type may be able of returning the qualified name of its parent.

Keep expressions out, make an easily navigable model.

Do not stick the modeling power of the API to XPath. XPath is an expression language and there can exist others.
We must provide an API that makes easy the implementation of an expression language against it.

Give FeatureCollection its place

FeatureCollection is a well known construct, with a well known type, as well as Geometry and its derivatives are.
The same way you can define your own type to hold features, you could define your own type to hold a geometry. Instead of having to do that, GML provides thes e predefined constructs to easy the job of GIS users, so lets integrate FeatureCollection in the modeling system in a way that it is not needed to have a special treatment to deal with them, but simply using its Feature API.

Make restrictions implementation independent

The restrictions on the value space of a simple type is given by its "facets".
The restrictions on the value space of a complex type is given by its "content model".
By the other hand, the idea of directly expressing these restrictions through the Filter API may or may not satisfy the whole spectrum of needs. It it does, predefined function names should be defined to treat facets, and the Filter API may need to be extended to deal with validation of the content model for complex types. More than that, it would be desirable to validate a type instance without having a complete Feature instance, which the current Filter API does not allows.
This may impose an unacceptable burden to the API making it very hard to implement.

Instead, the restrictions on a type's value space could be expressed by a simple API and give implementations the freedom to validate them as they like.