I initially implemented support for defining the structure (mapping) of
EFeatureDataStore using a Eclipse extension point. However, since the
Eclipse plugin framework in not a integral part of GT, I have decided to
move this functionality to it's counterpart in uDIG: *
eu.udig.catalog.efeature* (not yet proposed, but this is in the works, the
main classes are implemented). This is a cleaner approach more inline with
other DataStore implementations.
Instead, I have implemented a algorithm (as proposed earlier) that is able
to build a EFeatureDataStore structure automatically from any EPackage
instance storing Geometry data. This algorithm adds every EClass containing
attributes storing Geometry instances. I have also implemented methods for
opening EFeatureDataStore instances with explicit defined structure. In both
cases, the structure acts like a mapping (or a "structure" filter) between
the actual EMF model structure and the structure exposed by
the EFeatureDataStore instance.
This is my remaining todo-list:
- EFeature writer classes.
- Serialize JTS Geometry instances to XMI (write).
- SimpleFeature to EObject data mapping (write).
- Test suite for all classes (started)
I'm soon ready to do my first commit to the "unsupported/efeature" folder
The wiki <http://docs.codehaus.org/display/GEOTOOLS/EFeatureDataStore> is
now updated to reflect these changes.