Message-ID: <980480772.3817.1369400951821.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3816_1994853048.1369400951820" ------=_Part_3816_1994853048.1369400951820 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The uDig project (an OpenGIS based gt2 client w/ WFS+WMS support) is exp= ected to provide an influx of JUMP developers used to an Array based in mem= ory Feature model.
Our streaming approach will threaten to isolate them, and in general it=
terators are "harder" to quickly hack with then arrays. We do
know we are stuck with them - iterators (or visitor) is requ=
ired when dealing with large data sets.
I think we can get 90% of the way there with convience methods. Similar = to getBounds(), getCount() the idea is to provide for common opperations we= want to optimize.
The idea is that users can keep fids rather than array indexs (requires = a simple getFeature/setFeature API). The other mode of use I see people usi= ng is bounding box queries, providing optimized access to based on BBox wou= ld solve a lot of woes.
So FeatureSource would add the following methods:
And FeatureStore would add the following methods:
And an extension to FeatureResults that handles writing .... FeatureSet = (peer of result set):
With the above api we can provide optimized implementations based on ran= dom file or database result set access while maintaining iterator based imp= lementations.
Any GIS based data solution worth it's salt provides spatial indexing al= lowing the BBox based queries to really move. I would also assume that the= choice of FID aligns well with something that is quickish (like row based = access for shapefile, or primary key for a database).
The split between FeatureResults and FeatureSource is bluring on me as p= eople try and construct FeatureSources that are limited by a Query. If thi= s continues we may need to smuch them together (in which case we lose the v= isiablity of optimiations), or rename FeatureResults to FeatureView to make= it more obviously useful.
IanS: so for a ds which doesn't provide random access, you can iterate o= ff a file or use an in-memory cache (taking the appropriate performance hit= )
I have set up ResourceCollection and AbstractResourceCollection to be th= e following:
Use is as expected:
And purge is used to clean up after others:
All of this is in the Javadocs.
Please note as it stands right now the existing implementation of DataFe= atureCollection is a second class citizen, may of the traditional collectio= n methods are still just stubbed. By extending DataFeatureCollection to ex= tend AbstractResourceCollection everything will just work, but this is not= something I will have time for ... if there are any volunteers it would be= a great review of my work.
Also implemented two FeatureIterators directly wrapping FeatureWriter an= d FeatureReader respectively. Change made to DataFeatureCollection.
As it stands I am subclassing AbstractResourceCollection to implement ..= ..
In addition the following will be set up:
I have "gasp" introduced two constants SortBy.NATURAL and Sort= By.REVERSE that intended to reveal the "Natural Order" (or revers= e it) of the datastore, this is the order that is most likely based on FID = or a database Key, and thus most likely to be fast.
As for capturing the FeatureList ... most likely implemented as a TreeMa= p by FID, order based on the ID so random access but O(lg N) rather then O(= C). I may consider tag teaming a TreeSet of FID with a HashMap on the groun= ds that Shapefile would be better able to reuse the code.
All other sorted orders will be on permutations of a copy of the TreeSet= of FIDS, shapefile with support for attributes indexes can produce their o= wn SortedFeatureList ...
The final bit of the puzzle is this - FeatureCollection ISA Feature, and= that has some consequences. Rather then rewrite the same boiler plate code= seen duplicated in DataFeatureCollction and DefaultFeatureCollection I am = isolating it out in to FeatureState, derrived collections (both sorted and = sub) will make use of an alternate implemntation that delegates attribute h= andling up to the origional, while maintain their own cached idea of size a= nd bounds (cache to be managed using using FeatureEvents).
Finally the existing implementations of DefaultFeatureCollection and Dat= aFeatureCollection advertise themselves as AbstractFeatureCollection to the= XML world, and offer up a single attribute (in index 0) which is a normal = List containing all of their contents.
Aka stuff I won't be able to work on right now - but I would like to adj= ust FeatureState at a later time to:
This would have consequences for the XML writing code, we have not seen = FeatureCollections with attributes thus far, and we reference Feature.getBo= unds() directly, rather then relying on it to be picked up as an normal Att= ribtue.
As you can see by isolating these decisions to FeatureState we will have= less work patching up FeatureCollection later.------=_Part_3816_1994853048.1369400951820--