[Geoserver-devel] Extension points for FeatureSource and DataStore morphing (was Feature Source with vector generalisations)

Hi,
discussing the feature source with vector generalization topic
we came up with the need to have a way to alter what a datastore
or a feature source reports back to the rest of the system
by wrapping it somehow.

The use case in particular is having multiple feature types
that actually are a progressive generalization, geometry wise,
of a base type, and lump them togheter so that only one
is seen, and the proper generalization level is returned
based on a Query hint. This is a datastore level modification.

But the same could be done at the feature source level,
if one has multiple geometry columns generalized at different
levels (mainly a feature source level modification as far
as GeoServer is concerned, as the only thing that we really
use out of DataStore is getTypeNames and getFEatureSource).

It's also to be noted that in GeoServer we're already having
a feature source level wrapper that changes the name of a
feature type one the fly (a rw re-namer).

So, established there is a need for this kind of pluggable
extension point, how does it look like? And while we're at
it, can it benefit complex feature building? (complex
datastore is just a wrapper on top of other datastores, no?)

Justin proposed the following interfaces:

DataStoreWrapper {

  boolean canHandle( FeatureTypeInfo featureType, DataStore dataStore );

  DataStore wrap( FeatureTypeINfo featureType, DAtaSTore dataStore );

}

would we want to handle teh wrapping of FeatureSources as well? So adding perhaps a:

  FeatureSource wrap( FeatureTypeINfo featureTYpe, FeatureSource featureSource );

Hum, what about:

DataStoreWrapper {
   boolean canHandle( DataStoreInfo dataStore, DataStore dataStore );
   DataStore wrap( DataStoreInfo dataStore, DataStore dataStore );
}

and

FeatureSourceWrapper {
   boolean canHandle( FeatureTypeInfo featureType, FeatureSource source);
   FeatureSource wrap( FeatureTypeInfo featureType, FeatureSource
source);
}

Also, what is the expected behaviour for wrapping? The first wrapper
wins? Or we can have multiple wrapping levels?
I would go for the second, the first wrapper wraps, and the loop
on the available wrappers continues on using the newly wrapped ds
as the parameter in canHandle and canWrap.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

That is a strong argument for justin's combining for FeatureSource and
FeatureCollection. Right now when a wrapper is applied I need to
implement FeatureReader or Iterator wrapper; FeatureCollectionWrapper
etc... this tends to keep on exploding the further up you move the
wrapper.

Can FeatureStore wrapper be applied? Or is this limited to read-only.

Jody

On Mon, Apr 6, 2009 at 9:07 PM, Andrea Aime <aaime@anonymised.com> wrote:

Hi,
discussing the feature source with vector generalization topic
we came up with the need to have a way to alter what a datastore
or a feature source reports back to the rest of the system
by wrapping it somehow.

The use case in particular is having multiple feature types
that actually are a progressive generalization, geometry wise,
of a base type, and lump them togheter so that only one
is seen, and the proper generalization level is returned
based on a Query hint. This is a datastore level modification.

But the same could be done at the feature source level,
if one has multiple geometry columns generalized at different
levels (mainly a feature source level modification as far
as GeoServer is concerned, as the only thing that we really
use out of DataStore is getTypeNames and getFEatureSource).

It's also to be noted that in GeoServer we're already having
a feature source level wrapper that changes the name of a
feature type one the fly (a rw re-namer).

So, established there is a need for this kind of pluggable
extension point, how does it look like? And while we're at
it, can it benefit complex feature building? (complex
datastore is just a wrapper on top of other datastores, no?)

Justin proposed the following interfaces:

DataStoreWrapper {

boolean canHandle( FeatureTypeInfo featureType, DataStore dataStore );

DataStore wrap( FeatureTypeINfo featureType, DAtaSTore dataStore );

}

would we want to handle teh wrapping of FeatureSources as well? So adding perhaps a:

FeatureSource wrap( FeatureTypeINfo featureTYpe, FeatureSource featureSource );

Hum, what about:

DataStoreWrapper {
boolean canHandle( DataStoreInfo dataStore, DataStore dataStore );
DataStore wrap( DataStoreInfo dataStore, DataStore dataStore );
}

and

FeatureSourceWrapper {
boolean canHandle( FeatureTypeInfo featureType, FeatureSource source);
FeatureSource wrap( FeatureTypeInfo featureType, FeatureSource
source);
}

Also, what is the expected behaviour for wrapping? The first wrapper
wins? Or we can have multiple wrapping levels?
I would go for the second, the first wrapper wraps, and the loop
on the available wrappers continues on using the newly wrapped ds
as the parameter in canHandle and canWrap.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Jody Garnett ha scritto:

That is a strong argument for justin's combining for FeatureSource and
FeatureCollection. Right now when a wrapper is applied I need to
implement FeatureReader or Iterator wrapper; FeatureCollectionWrapper
etc... this tends to keep on exploding the further up you move the
wrapper.

Indeed, writing wrappers for the current datastore API is a royal
pain.

Can FeatureStore wrapper be applied? Or is this limited to read-only.

I don't see any reason to limit it to read only. I used FeatureSource
in the examples just because it's the base class.
Some wrappers will have the side effect of turning a FeatureStore
into a FeatureSource (the app schema datastore does it afaik)
but that's by no means the rule. The type renamer wrapper we
have to day, for example, is fully read/write

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.