Here are the examples.
Build a Feature: Simple Case:
-----------------------------
//schema: {name:String, classification:Integer, height:Double,
//location:Point}
FeatureStore fs = ...
SimpleFeature f = fs.createFeature( null, new Initializer<SimpleFeature>() {
public void initialize( SimpleFeature prototype ) {
prototype.createProperty( "name" ).setValue( "Canada" );
prototype.createProperty( "classification" ).setValue( 1 );
prototype.createProperty( "height" ).setValue( 20.5 );
prototype.createProperty( "location").setValue(new Point(-124, 52));
}
});
(Java8 should allow to cut down two lines of code)
Note that client code does not have to deal with FeatureType or FeatureBuilder.
I'm not quite sure if createFeature() should already create the Feature in the
store or if every modification has to be send to the store via
updateFeatures().
Both seems to be feasible. (?)
The above code assumes that there is a version of createProperty() without an
Initializer. Another way is to keep this straight and introduce a value
Initializer so that creating a Property would be:
prototype.createProperty( "name", new Value( "Canada" ) );
Copy Features (addFeatures())
-------------------------------
FeatureStore srcFs = ..., destFs = ...
srcFs.getFeatures().accept( new FeatureVisitor() {
public void visit( Feature feature ) {
destFs.createFeature( null, new CopyInitializer( feature ) );
} }, null );
Java8 should allow something like: (not tried yet)
fc.accept(f -> destFs.createFeature(null, new CopyInitializer(feature),
null);
Modify a Property
-----------------
FeatureCollection fc = fs.getFeatures( ff.id( id ) );
Feature f = fc.iterator.next();
f.getProperty( "name" ).setValue( "Indonesia" );
fs.updateFeatures( fc );
getProperty() throws an NPE if the Property is not yet initialized (aka
null/nil). So the client code can (and has to) check/handle null values! This
good IMO as 'nillable' is part of the model.
Create a ComplexAttribute
-------------------------
ComplexAttribute address = (ComplexAttribute)
f.createProperty( "address", new Initializer<ComplexAttribute>() {
public void initialize( ComplexAttribute address ) {
address.createProperty( "city" ).setValue( "Leipzig" );
}
};
Here I'm not sure if this is the way ComplexAttribute is meant to be used. At
least I would expect it to be used like this. (?)
Create a Collection
-------------------
Collection<Property> props = f.getProperties( "synonyms" );
if (props does not contain value) {
f.createProperty( "synonyms" ).setValue( "new value" );
}
Of course several createFeature()/updateFeatures() operations can be wrapped in
a transaction as usual.
Am 20.09.2014 02:07, schrieb Jody Garnett:
> I like the direction your ideas are heading. We have not used Functor before -
> instead returning features to the user that they can then "fill in" with
> appropriate values. Trusting they are filled in before commit() is called.
>
> One question for you is the handling of Commit. A WFS Commit operation is
> supped
> to return the FeatureIds of any content that was created during the
> Transaction.
>
> In GeoTools each addFeature operation returns a java.util.List<FeatureId>.
> These
> FeatureId instances are updated with their actual value when
> Transaction.commit() is called - we also send out a BatchFeature events (so
> that
> any user interfaces can be advised on the change).
I'n not sure that I'm getting the point.
First, Transaction API keeps untouched.
Second, my first idea was to let createFeature() actually create the feature in
the store (see above). With Transaction.AUTO_COMMIT createFeature() *is* a
transaction then and so it could ask the backend store to create a correct
FeatureId and set it in the returned Feature. With a Transaction set
createFeature() can do this as well. No need to update FeatureId at all. Client
code could always trust FeatureId no matter where is comes from.
-Falko
--
Falko Bräutigam
http://polymap.org/polymap3
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
