I agree with Jordy adapters and feature factories are a great way to
switch between one model and another.
I built factories into my API with the added extra of using generics for
the factory. With this approach my factory returns the value using the
correct sub class of DataObject. In the case of JUMP features it would
return a DataObjectFeature which is both a DataObject and a Feature.
You can then (again using generics) pass this in when creating your
Reader (e.g ECSV or Shape Reader) so that it will in turn return
DataObjectFeatures. You can then use the same reader if you wanted
Feature instances or DataObject instances by just switching out the factory.
FeatureDataObjectFactory factory = new FeatureDataObjectFactory();
ShapeReader<DataObjectFeature> reader = ShapeReader.createReader(shapeFile,
factory);
for (Feature feature : reader) {
// Do something with feature
}
ArrayDataObjectFactory factory = new ArrayDataObjectFactory();
ShapeReader<DataObject> reader = ShapeReader.createReader(shapeFile, factory);
for (DataObject object : reader) {
// Do something with object
}
Paul
Jody Garnett wrote:
I have written adapaters a couple of times; it is a good way to approach
the problem. Allowing client code (ie OpenJump) to provide a
FeatureFactory is one of the ways you can ask GeoTools to make use of
your adapters.
In the past the GPL license (specifically on the open jump feature
model) prevented me from rolling out the adapters as part of uDig.
As for the feature model; all the java communities were contacted as the
work was started - and projects tend to follow the needs of those
contributing. In this case the people contributing (and paying for) the
effort were the ones not being helped by the existing projects.
Jody
Martin Davis wrote:
Excellent question, SS. I'm not surprised to see this come up.
Greater integration with GeoTools has often been suggested as the
ultimate goal for future JUMP design, but I've always been concerned
that GeoTools imposes an undesirable level of complexity. It would be
nice to find a good path forward between the Scylla of incompatibility
and the Charybdis of code complexity... (yes, it's Obscure Classical
Allusions day today...)
A couple of comments:
1. Your idea of "a small simple feature library" sounds like exactly
what the idea of defining the JUMP Core API was meant to address.
Does that sound right? (Are you familiar with this idea, or did it
not make it over to OpenJUMP?)
2. Is there any possibility of someone rolling up their sleeves and
developing an Adapter API which would map the GeoTools SF model in the
JUMP Feature API? Once this was done, perhaps it would then be much
easier to call GeoTools code? I realize this is probably a lot of
work, and it really needs to be done with great care in design, since
Adapter layers can get pretty tricky to code.
I'll cc this to Jody, since he's probably best placed to comment on
this from the GT perspective.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
