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