From: Chris H. <ch...@op...> - 2006-08-04 22:32:05
|
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 |