Skip to end of metadata
Go to start of metadata



Module Maintainer:

Kenneth Gulbrandsøy


(red star)(red star)(red star)(red star)(red star)

Email Help:


IP Review:

none (not commited)



The EFeature module adds support for spatial read and write operations to EMF models. 

Why EMF models as spatial data store?

EMF is a Eclipse-based modeling and data integration framework. The development tool chain and runtime support offered by the framework
allow developers to rapidly implement data-driven systems from model specifications described in XMI or other XMI compatible modeling
languages like UML and SysML. EMF enables system modeling, which is one of the primary tools in the model-driven engineering toolbox.
Model-driven engineering focuses on developing and exploiting domain models in manners that increase productivity, which involves
developing software that are model-driven.

Model-driven decision support systems are first class citizens of the model-driven engineering application domain. The processes supported
by these systems span from off-line business dynamics analysis to supervision and control of time-critical field operations like search and
rescue. Implementing decision support for the latter, is particular hard because of the practical constraints in the field. When time is critical,
users become much more sensitive to ill-designed support systems than users who have more relaxed time-constraints. There is simply no
time to tinker with the system to make it work when people might dye if the response is to late. This translates into specific
software engineering requirements like flexible modeling tools which allow incremental development of decision support tools through short
development cycles.

In the domain of search and rescue, field operations are event-driven, asynchronous and distributed by nature, a problem which is both
spatial and temporal. The modeling tool-chain must therefore, in addition to be flexible, support development of both spatial and temporal
data-driven decision support tools.

So, how does EMF and adding spatial support to it fit in? EMF is event driven. It supports therefore the temporal domain by design. Each time
data changes, registered listeners are notified by the model instance that changed. It also enables interoperability between EMF-based
systems, adding support for the distributed nature of field operation. The tool-chain also support model validation, querying, persistence and
basic tools for implementing model viewers. It does not however, have native support for modeling and querying spatial data. This is why
this module is proposed.

Some EFeatureDataStore Use Cases

  • Storing off-line and real-time tracking of objects
    (multiple sources liked to same spatial object)
  • Storing spatially described tasks not easily described using RDBMS
    (multi-object, graph-like, user specified)
  • Storing results from multiple analyses on the same spatial data
    (from any spatial source)

Module architecture

Proposed packages

The following packages are proposed, but may change before initial commit:



GeoTools data interface implementations

OpenGIS filter interface implementations

EFeature EMF model implementation

EFeature EMF model utilities

JUnit test cases

EFeatureDataStore Structure Definition

The data structure compatible with the ContentDataStore/ContentEntry design pattern. Each EFeatureDataStore consists of a set of
EFeatureFolders containing the EFeature classes (equivalent to "tables" in the RDBMS world). The EFeatureDataStore structure can
be explicitly defined (statically using extension points or dynamically with code), or inferred from the EPackage of the EMF model
containing EFeature data. This gives the developer great control over which parts of the EMF model to include in the
EFeatureDataStore and which to exclude. 

The structure is represented by the following definition classes:

  • EFeatureDataStoreInfo (root)
  • EFeatureFolderInfo
  • EFeatureInfo (SimpleFeatureType)
  • EAttributeInfo (AttributeDescriptor, leaf)
  • EGeometryInfo (GeometryDescriptor, leaf)

Mapping EClass to SimpleFeatureType to EClass

SimpleFeatureType instances are wrappers around EFeatureInfo (filtered EClass) instances that implements EFeature or contains
EFeature compatible data. 

Mapping EObject to SimpleFeature to EObject

Efficient memory utilization is very important when working with spatial data. Encoding a SimpleFeature
for each EObject is therefore unwise unless every EObject is actively unloaded after the encoding (duplicate information
exist in memory). One obvious solution to this problem (thanks Jody) is to implement SimpleFeatures as wrappers around
each EObject. The challenge with this approach is less control of EObject life time, which impacts the unloading
policies of EMF.

EFeature Query capabilties

The goal is to add as much filter capabilities as EMF Query allows. EMF Query have two query statements. These are the 
SELECT and UPDATE statements. As in SQL, SELECT and UPDATE have both a FROM and WHERE clause. The FROM clause
defines a set of EObjects to be queried using the WHERE clause as filter to return a subset of EObjects. The UPDATE
statement extends SELECT by adding an additional SET clause which to perform some write operation on the selected
EObjects. Although similar to SQL, the capabilities of EMF Query is only a small subset of the capabilities of SQL. Most
importantly, EMF Query does not have any form for JOIN capabilities. Since this includes the implicit join notation of 
INNER JOINs found in SQL WHERE clauses, filters generated by GeoTools containing predicates comparing two attributes 
(properties), are not supported by EMF Query. EFeature throws an IllegalArgumentException if any implicit inner join 
predicates are found. Put in plain terms, the EFeature module only support filters that compare attributes values with Literals. 

Literals supported (data types)

  • All primitive Java data types and their object counterparts
  • Boolean, Character, String and java.util.Date
  • All JTS simple features
  • (One-dimensional arrays of all above)

Module Status

This module is still in the RnD stage.







Static definition of EFeatureDataStore structure.

Eclipse plug-in extension point. Experimental.



EFeature EMF meta-model

EFeature API. Enables easier inference of structure from EPackages.



EFeature data store factory (SPI).




EFeature data store.

Based on AbstractDataStore for now. Is changeing to ContentDataStore.



EFeature reader classes.




OpenGIS filter to EMF Query encoder.




EClass to SimpleFeatureType structure mapping (read).

Implemented as delegate class



EObject to SimpleFeature data mapping (read).

Implemented as delegate class



Inferred definition of EFeatureDataStore structure from EMF Model EPackage.




Serialize geometries to XMI.

It turns out that JTS Geometry is serializable.



Opening EFeatureDataStore with explicitly defined structure.




EFeature writer classes.




SimpleFeature to EObject data mapping (write).



Test suite for all classes.

Only some minor tests remain to be implemented.

For more information, see: EFeatureDataStore Build.

Outstanding Issues

The module maintainer will take care of assigning these issues to developers:

Type Key Summary Assignee Reporter Priority Status Resolution Created Updated Due

Remember that the module maintainer is a volunteer, and if you can help test this module please jump on the developers
list and help out. Patches may be attached to the above issues for review by the module maintainer.

Although not the responsibility of the geotools module maintainer additional or related issues may be found in the the
geoserver or udig bug trackers.

Gold Star Quality Assurance Check

(red star)  IP Check: no
(red star)  Releasable: no
(red star)  Quality Assurance: no
(red star)  Stability: no
(red star)  Supported: no

IP Review

Not committed yet.

  • No labels