Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[udig-devel] Re: Query w/ WFS 1.1 & Catalog ideas - rant mode on ; -) 
Hi Chris - thanks for chiming in ;-)
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.
Yes, they were open to it last time as well - for the wording and so on being in sync with the catalog Query is the way to go. 
What are these guidelines?

- http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Branch

Check out #5 and #6:


   1. FeatureCollection vs Filter
          * FeatureCollections are magic optimized datastore specific
            pearls of performance (so hold onto them rather then the
            generic Filter that created them)
          * FeatureCollection can do more then Filter, see
            subCollection(filter), sort( order ), ... and soon /join(
            collection )/
          * use feature collection methods to build up your "data
            model" and then use the filter "query model" to select the
            information you want out.
   2. The three DataStore specific FeatureCollection implementations
         1. Represents getFeatures( Filter.NONE ) - ie everything,
            count and bounds optimized based on metadata etc
         2. Represents getFeatures( Filter ) - represents a useful
            collection, may be implemented over random access rowset etc..
         3. Represents subCollection( Filter ) - used to temporary
            hold a Filter to paramartize an operation like clear()
          * If you can support an index or random access break out
            FeatureList




Does catalog query assume a sortBy?
It is more that for any startPosition implementation to work the data must be ordered data (rather then taking what is in the cache first and then tacking in the rest of the results as they appear from disk). There is nothing in the WFS getFeatures method that ensure data is always returned in the same order after all.
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?
Yes, and the FeatureList is already to go, and has a memory based implementation - I just want somebody to pick it up and make SQL with it ;-)
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. 
Yes you got, if I can sum up:
- Query should be a general data query based on WFS 1.0, WFS 1.1 and CSW ideas. - FeatureCollection / FeatureList should be the datastore specific implementation - iterator should be used for collection access (and will produces "copies" of the data) - visitor should be used for speed (say in rendering) and may just be lazy access over a result set 

Cheers,
Jody

Back to the top