Package org.opengis.feature.type

Captures the generic feature model from ISO 19109 with allowances for usability.

See:
          Description

Interface Summary
AssociationDescriptor Indicating a named association.
AssociationType Association information, immutable.
AttributeDescriptor Indicating a named entry for a prescribed AttributeType.
AttributeType Declaration of attribute type.
ComplexType Represents an AttirbuteType with interesting internal structure made available as properties.
FeatureCollectionType Represents a FeatureCollection The following restrictions are used: C is the Collection of Attributes for the FeatureCollection itself, these usually are derrived from the members (ie.
FeatureType Describes the contents of a Feature, basically a ComplexType with at least a Geometry and CRS.
GeometryType Represents (explicitly) the binding of an AttributeType to Geometry information.
Name Represents a Name, with respect to a Namespace.
Namespace A collection of 0 or more names, with no duplicates.
OperationDescriptor Indicating an implementation of an operation for a specific type.
OperationType Operation information, immutable.
PropertyDescriptor Describes how a ComplexType may be composed of types, associations and operations.
PropertyType PropertyType information, captured as AttributeType, AssociationType and OperationType.
Schema Allows for type discouverability and reuse.
StructuralDescriptor Containment information for a complex attribute.
TypeFactory Factory interface for the typing system.
TypeName Represents a scoped type name.
 

Package org.opengis.feature.type Description

Captures the generic feature model from ISO 19109 with allowances for usability.

This feature model has been produced after review of the ISO 19109 specification, and a review of several java implementations. The goal of this package is to capture the type information for the "general feature model".

The following goals have been set:

Type System

The following ideas are central to the functioning of this package as a feature model:

There are some open questions:

Differences from ISO 19103 with respect to Naming

We have explicilty made the following break with ISO 19103:

As indicated above we have removed the "back pointers" required to navigate from Name to its "context", instead we have provided a URI which should be used with your lookup system of choice. This choice may in fact be Namespace (and is when working with TypeNames in a Schema), however the actual implementation should be provided by the hosting language in many cases.

There is room for improvement - If possible we would prefer to use the javax.naming.Name API and keep even less API around for these concerns. As it is we offer this as a recommendation.

For more details of this change please review the Name and Namespace interfaces which covers this in more detail.

Differences from ISO 19109 with respect to General Feature Model

We have explicitly made the following break with ISO 19109:

Numerous other changes have been made to leverage Java collection API where appropriate. These represent a direct mapping onto the language constructs and may or may not prove significant to those arriving from an ISO 19109 background.

Relationship to ISO 19109 Primer

This work is greatly informed from a proposal included in the ISO 19109 primer - written by Bryce. In particular the requirement for operations, associations and detailed review of ISO19109, and EMF was a great asset. This primer also served as the only public documentation of the ISO 19109 material available for open development.

Differences from Bryce's proposal:

The definition of Record and Name were unresolved at the time of this work and has not been integrated. In particular the definition of Name was taken as "too complicated".

We also disagreed with one of the goals of the proposal: convention that the creation of objects inside an application schema is the responsibility of the schema author. This goal is in conflict with our need to allow applications to create instances of their own devising. This need is particulary apparent when an application needs to ensure the use of a specific base class (for example to work with a persistence system Jaxtor, or modeling system like EMF).



Copyright © 1994-2008 Open Geospatial Consortium. All Rights Reserved.