[Geotools-devel] Query w/ WFS 1.1 & Catalog ideas - rant mode on ; -)

[Jody G. <jga...@re...>]

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 ...

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.

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?)

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.

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
>