Message-ID: <1402626833.598.1369174568848.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_597_1638774344.1369174568847" ------=_Part_597_1638774344.1369174568847 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Over the years a number of efforts wanted to provide complex feature sup= port with different levels of success, and lead to the definition of the ne= w GeoAPI interfaces and an implementation sitting as an unsupported module = for some time now.
The GeoTools data access layer has moved from its own Feature/Type syste=
m to the GeoAPI SimpleFeature/Type interfaces.
GeoAPI SimpleFeature/Type are extensions to the more generic Feature/Type i= nterfaces, that provide for convenient assumptions over the Feature structu= res being flat.
Now we need to be able of dealing with complex features, genera= lly coming from WFS instances such as the USGS Framework Web Feature= Services, as well as to finally give GeoServer a transition path to se= rve complex features.
And we need to do it in a way that leverages all the knowledge put throu=
gh the years in the current GeoTools infrastructure and allows a smooth int=
Feature, both for new code to be built upon it, as=
for existing code (both internally and library client wise) that want to t=
ransition to support complex Features.
I'm trying to figure out a way to smoothly introduce
Feature with no detriment of all the work spent in
SimpleFeature up =
till now. That is, enable complex feature support from now on, with no even=
need to deprecate all the SimpleFeature stuff, as that's working well and =
serving a bunch of use cases, yet enabling for new developments to leverage=
the use of both new complex-capable data stores as well as the existing si=
mple-feature ones through the more generic Feature/FeatureType.
The big blocker factor is the lack of an appropriate data access= API. All the GeoTools code that deals with features is settled up= in terms of SimpleFeature and its assumptions. So the current DataStore AP= I. During the work on the community-schema modules, the main glitches found= with the DataStore API are:
At a Source level: Identification should be handled with with a qualifie= d name rather than a "TypeName". We are getting too many collisio= ns. For the GeoAPI Feature to be located correcly we need to get rid of the= idea that TypeName =3D=3D FeatureName (eg, "topp:states" !=3D &= quot;topp:states_Type". They may even be in different namespaces!)
We want current code to keep backwards compatible. This means the librar= y won't break all the code written with the SimpleFeature assumptions. And = we want all the format drivers written in simple terms to be used as the mo= re general Feature/Type out of the box.
There were good debate, see the following email thread
Basically in term of approaches to cover the above goals we managed this=
Debate lead to people asking for actual code examples so the three were spi= ked:
Introduce a superclass for
DataStore and parametrize Featur=
eSource, FeatureCollection etc, based on the type and content it serves (
1) cleaner abstract api
2) does not incur in naming conflicts (no need to find good names beyond t= he
ones already in use and a superclass for DataStore)
3) introduces only one more interface, a pull up of DataStore. This allows=
for the separation of generic Feature capable datastores and
SimpleFeature-only capable ones.
4) will break some existing client code when upgrading to geotools 2.5 due= to
the runtime erasing of generics. Yet, its easily fixable with a regular
expression search and replace.
Introduce a full hierarchy by pulling up parametrized versions of
FeatureCollection but keep the current interfaces with no generics (ie,
ends DataAccess<SimpleFeatureType, SimpleFeature>,
reSource extends Source<SimpleFeatureType, SimpleFeature>, etc=
1) cleaner concrete api for the DataStore case (ie, SimpleFeature)
2) Incurs in naming hell since the good ones are already taken
3) introduces a full layer of abstraction over DataStore,
FeatureSource/Store/Locking, FeatureReader/Writer, FeatureCollection
4) Breaks less/no existing code. Only requires the addition of Name vs. String (ie. DataStore.getNames():List<Name> vs
Introduce a full hierarchy by pulling up non parametrized versions of
atureCollection and keep the current interfaces as they are, relying=
on Java5 return type narrowing to specialize the return types for the Simp=
leFeature/Type case, and pay the cost of new overloaded methods in the subc=
ie, DataStore implementations get two new methods each, which are overlo= aded versions of the originals:
In this approach we try for a hybrid of (1) and (2) above.
Original idea: if we use one super class:
The idea is nice, problem being that once you get to code you find yours= elf being forced to parametrize, at least, Query, FeatureCollection and Fea= tureReader, the last two ideally being present only in FeatureStore, but fo= rced to propagate back to FeatureSource and DataStore to avoid type safety = warnings.------=_Part_597_1638774344.1369174568847--