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