On Wed, Oct 26, 2011 at 3:24 AM, Michael Bedward
<[email protected]>wrote:
> Hello all,
>
> The javadocs for FeatureReader
> (
> http://docs.geotools.org/latest/javadocs/org/geotools/data/FeatureReader.html
> )
> include this note which I assume is ancient history:
>
> "Q: Can we include skip(int) - SeanG A: The order of the contents is
> not "known" or predicatable to the end user, so skip( int ) would be
> useless. For random access (a higher order of abstraction then
> FeatureReader) please look at FeatureList."
>
It is ancient history indeed.
OGR has a similar concept here:
http://www.gdal.org/ogr/ogr__api_8h.html#5bb3f366e3e6cd8cb586842193b4a7f9
But if you look at the description, it says it's implemented efficiently
only in
"rare circumstances" (which means, I assume, only if you are not filtering
or sorting and only on selected data sources).
>
> This caught my attention because I'm presently looking at the gt-swing
> FeatureCollectionTableModel class, used with a JTable. The current
> code loads all features into memory, which is fine for tutorial use
> but not for much else. It would be nice to have paging behaviour so
> that, for example, given a shapefile with a gazillion features the
> table only loads and caches a few hundred centred on the current
> JTable view.
>
> The Swing table model side of this straightforward, but while
> experimenting with it's become obvious that I don't know enough about
> the GeoTools DataStore / FeatureSource / FeatureCollection API. Is it
> possible to do sequential access of features from random start points
> at a high level in the API, or does that require dealing with the
> specifics of each type of DataStore ?
>
As far as I know data stores do not care to expose specific API, providing
support for the standard API is enough work already.
Paging is something that is optionally supported by the current api
if you use Query startIndex and maxFeatures along with a sort
making the iteration stable.
Optional is the keyword here, jdbc stores provide support for it,
lately and on trunk any store based on ContentDataStore does
(at the eventual price of having to read everything and sort it though),
shapefile data store does not support it right now but could be made
to support it eventually, WFS 1.0 and 1.1 simply do not have the
n
I guess the trouble with a data table is that, in order to get the normal
expected functionalities, you'll also have to expose column sorting
and row filtering, and I guess at that point you would like to be able
to ask if the store supports all the above with paging efficiently.
Right now that question cannot be answered.
One option to consider when the native store is not able to page/sort/filter
efficiently might be to roll your own, copy all the data locally and use
a secondary source that can do what you need.
One might be derived from the work I did to allow sorting on any data
source,
which serializes features on disk and then merge/sorts them, I guess adding
paging and filtering on top of it would not be trivial, but not impossible
either.
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
