Jody Garnett wrote:
Thanks for taking up the ideas Gabriel, I am going to rant for a bit
(because I think I just went through these ideas with Justin in person -
so if this is old news please forgive). I am only excited be cause I
care, and only care because I am excited.
Jessy and I were ranting about adding the ability to the GeoTools
DataStore api of being required for a page of data/features, rather
than
the whole dataset.
So first implement a FeatureList and tell me if you need more - grumble
grumble ;-) Seriously the support for paged queries is will
understood and is part
of the WFS 1.1 Query
I don't find where in the WFS 1.1 spec mentions paginated access. It
just seems to say that you could ask for the entire dataset or for
just the results count, but nothing to do with pagination.
If I'm wrong please point me to the right direction.
Gabriel you will find the paginated access in in the Catalog Query
specification.
The same construct is there in WFS 1.1, but does not seem complete. This
was a recommendation made for OWS-3 and you will HAVE to bother Chris
Holmes to make it again for OWS-4 (and ask GeoServer to lead the
charge). In short this is simple the OGC needing to be smacked around
for internal consistency. Darn I miss not being part of OWS-4 ...
WFS 1.1 definitely does not have the construct from Catalog. I'm not
sure what the recommendation you're referring to is. If it's to change
the spec then that would be for wfs 1.2, and would require a change
request. I can submit a change request for it, the WFS editor is
definitely open to it.
With respect to a sample implementation - I would *love* have it, I
really want feedback on the feature list construct. If it is not
sufficient for you I want some IRC time to break it down into an
acceptable manner. (Although I do suspect we are ready to go right now).
I also need to stress the guidelines made for the FM branch; I *do not*
want to see Query fancied up as we tried to do for reprojection and
forced CRS. The guidelines about the difference between
FeatureCollection methods and Filters I intend to take seriously.
What are these guidelines?
If that was too much architect speak let me be plane:
- Query:setStartPostion( int )
- Query.setMaxRecords( int )
Will only work when you are using SortBy, unless a natural ordering for
the data is known (we could assume sortBy FID as a default if we have to?)
Does catalog query assume a sortBy?
That is *fine* just please do not *use* that Query information in a
direct implemenation of FeatureSource.getFeatures( Query ) - let me
explain.
When implementing I need us to use FeatureCollection methods, specifically:
- featureSource.getFeatures( filter )
- featureCollection.sort( SortBy ) - you can specify a natural ordering
of FID here
- featureList.subList( startPosition, startPosition+maxRecords)
- subFeatureList.getBounds() - to obtain the bounds for your GML
- subFeatureList.iterator() - with a loop iterator.hasNext() and
iterator().next() when writing your content
- finally { featureList.close( iterator ) } - to not leak resources
Sorry for the rant, I really do not want to lose ground here on work
already accomplished. I believe we already have the API needed
for the implementation - I just need a DataStore writer to produce some
nicely optimized implementations so it works well.
So you're just saying that the implementation of using a Query with
those two additions should be implemented in an abstract class that
calls a featureList, yeah? That makes sense. I think having these
fields in the Query is more intuitive from a client code perspective,
instead of making clients learn about featureLists and the like, they
can just submit their query, just like a WFS query, which is the
inspiration for our Query.
Chris
Cheers (and thanks for putting up with me being inspired, gotta find me
a project or time to work on this stuff more closely)
Jody
PS. With respect to the above mention of Query reprojection and force
projection as a mistake, it was fine for the time when we were focused
on FeatureReaders. Now that I have a really good clue on what I want to
see I would like to make some FeatureCollection methods that manipulate
the model returned - say:
- attributes( List<AttributeType> )
- reproject( GeometryAttributeType, CRS )
- force( GeometryAttributeType, CRS )
Gabriel
!DSPAM:1003,44d3022c161712081064789!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
