Message-ID: <405297419.1057.1410874661392.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1056_1019398455.1410874661392" ------=_Part_1056_1019398455.1410874661392 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.=20
The GeoTools data access layer has moved from its own Feature/Type syste=
m to the GeoAPI SimpleFeature/Type interfaces.
GeoAPI SimpleFeature/T= ype are extensions to the more generic Feature/Type interfaces, that provid= e for convenient assumptions over the Feature structures 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.=20
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:=20
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 &q= uot;topp:states_Type". They may even be in different namespaces!)= =20
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.=20
There were good debate, see the following email thread=20
Basically in term of approaches to cover the above goals we managed this=
Debate lead to people asking for actual code ex= amples so the three were spiked:
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 the
ones already in use and a superc= lass for DataStore)
3) introduces only one more interface, a pull up = of DataStore. This allows
for the separation of generic Feature capa= ble datastores and
SimpleFeature-only capable ones.
4) will br= eak 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) i= ntroduces 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:=20 =20
In this approach we try for a hybrid of (1) and (2) above.=20
Original idea: if we use one super class:=20
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.