Skip to end of metadata
Go to start of metadata

Motivation:

Support GetGMLObject operation of WFS 1.1

Contact:

Justin Deoliveira

Tracker:

http://jira.codehaus.org/browse/GEOT-XXXX

Tagline:

This page represents the current plan; for discussion please check the tracker link above.

Status

This proposal is closed and has been implemented.

Voting has not started yet:

 

Vote

Alternative 1

Alternative 2

Andrea Aime

 

 

 

Ian Turton

 

 

 

Justin Deoliveira

+1

(tick)

 

Jody Garnett

+1

(tick)

 

Martin Desruisseaux

 

 

 

Simone Giannecchini

 

 

 

dynamictasklist: task list macros declared inside wiki-markup macros are not supported

Description

WFS 1.1 comes with the addition of a new operation called GetGmlObject. This is relatively simple in nature. Given the identifier of a "GML object" (be it a Feature or a Geometry) return that object.

The following is an example of a GetGmlObject request in which an individual feature with the id "PrimitiveGeoFeature.1" is being requested:

The response to this request is the feature encoded in gml:

The GetGmlObject operation can also be used to retreive individual geometries. The following is an example in which an individual point with the id "point.1" is being requested:

The response is the point encoded in gml:

Providing support in Geotools for this operation is broken out into two alternatives which will be explained in greater detail in the following sections. The first alternative requires a DataStore api extension which will provide additional datastore api for querying specifically for an object. The second alternative requires is implemented entirely with existing api and hints.

Proposal

Alternative 1: Extending the DataStore API

As stated above, the first alternative is centered around an extension to the DataStore api. An additional interface called GmlObjectStore is added:

The interface adds a single method which takes a GmlObjectId (from the filter model), and produces an object. The object being a Feature, or a Geometry.

The idea is that a DataStore which is capable of providing these lookup operations can implement this additional interface. A client wishing to use this functionality must do an instanceof check against the interface.

As an example consider the implementation of the GetGmlObject operation in GEoServer:

Alternative 2: Hints

An alternative to extending the datastore api is to use a combination of the old api and the hint system. A hint called "GML_OBJECT_ID" is added:

A client must supply this hint to a data store via a Query object. Again consider the implementation of the GetGmlObject operation in GeoServer:

At this point it is up to the particular data store implementation to honor the hint passed in. Now this is where things get a big fuzzy. In the case where a particular Feature is being requested the answer is simple. Just return a single feature:

However, what about the case where a particular Geometry is being requested? The existing data store api limits us to returning features. So for this case we must wrap the geometry in a feature.

It gets a bit more complicated in that the client code must know which type of object corresponds to the requested id, since it needs to know if it should unwrap the feature or not. A possible solution to this is to use "user data" for the data store to report back the type of the object:

API Changes

Alternative 1

Addition of the GmlObjectAware interface above.

Alternative 2

Addition of the GML_OBJECT_ID hint.

  • No labels