Re: [Geotools-devel] FeatureCollection questions

[Bryce L N. <bno...@fs...>]

geo...@li... wrote on 12/05/2006 08:22:26
PM:

> Cool ideas!! Comments inline.

Yea me!

> A couple of thoughts...
>
> Often the attributes on the "Feature" part of the FeatureCollection are
> derived from the contents of the collection. For instance, in a
> GMLFeatureCollection, there is a "boundedBy" property on the feature,
> which corresponds to the bounds of the all the features in the
> collection. So... what does the api look like for keeping these things
> synced up? I imagine the Collection part we come up with will have some
> sort of event notification? Is it up to the person creating the
> collection to add a listener which keeps things in sync.

I don't know.  Java Collections Framework does not require hooks for
external synchronization.  Obviously, whatever internal data structures
necessary to the implementation need to be updated on every "add" or
"remove", but this is up to the implementation.  I don't think we need to
force every collection implementation to provide synchronization, but I do
see that we are writing a collection framework for an environment which is
concerned about synchronization.

Well there's really only two ways to approach it:

1] Add the event pattern to the interfaces directly (addXXXListener,
removeXXXListener); or

2] Add separate interfaces containing the event pattern
(NotifyingSpatioTemporalCollection), then implement the event firing code
_once_ as a wrapper.

I'm in favor of #2 because it's one less thing to deal with when writing an
implementation.  However, #1 means fewer objects.  I could live with either
option.


> Also, in geotools land, an important design principle has been that we
> want to promote data store implementors to write custom feature
> collections. For instance, for a jdbc based datastore, we want the
> collection to be closely wrapped around a "Result Set" for performance
> reasons. Which still seems consistent with this new FeatureCollection.
> The implementor will now have just have to extend the "Collection" part,
> providing a custom iterator of sorts.

Exactly.  In this case, the logic to sift thru the mountain of data will
reside in the remote data store.

I also think that we should eventually provide a default set of memory
resident implementations.  I don't think it's difficult to find a use for
these utility classes.

> So yeah ... i am liking this design. I also like that it is very
> non-intrusive toward geoapi, most of the details are geotools
> implementation.

I think we should strive to keep GeoAPI centered on standards, and make
GeoTools one particular implementation.  If we give GeoAPI too much of a
GeoTools flavor, no one else will want to play. :)

> What does Jody think of all this? He is really the mastermind behind the
> current FeatureCollection design, I am interested to hear what he has to
> say.

Hello?  Jody? :)

Bryce