This is the subject of active development on the GeoAPI Feature Model interfaces.
For details of the API please review the nice pictures here:
Consult Primer here:
Quality Assurance Guidelines
One of the big problems the FM branch has run into is inconsistencies in the GeoTools library... needing factories to be used correctly, allowing them to be injected where needed etc.
So far in talking to Justin I have found a few ground rules that when I
screw up has me fail a code review. These are hard to capature .. but I
gotta try anyways.
- Builder vs Factory
- XFactory does what it does exactly with no logic
- XBuilder maintains state and can do the logic you wanted to put in the factory
- DataStore and its Factories
- AbstractDataStore is focused on "simple" features
- AbstractDataStore "owns" types and thus needs a SimpleTypeFactory in order to create them
- FeatureSource "owns" data and thus needs a SimpleFeatureFactory in order to create data
- Iterators and FeatureReaders/FeatureWriters
- FeatureReader and FeatureWriter are no longer a focus of interaction
- Iterators "create" content, so each pass through the data will need its own FeatureBuilder)
- Iterators and Visitors
- Iterators are used to hack at data (isDirty checks, or cloning may not be fast)
- FeatureVisitor are used for blinding fast (possible concurrent) access
- Use of Builders
- Builders should only ever be a local variable, or used in one synchronized method.
- 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.
- The three DataStore specific FeatureCollection implementations
- Represents getFeatures( Filter.NONE ) - ie everything, count and bounds optimized based on metadata etc
- Represents getFeatures( Filter ) - represents a useful collection, may be implemented over random access rowset etc..
- 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
You can also track change requests against the GeoAPI interfaces here:
Since the GeoServer community is championing this effort most of it shows on on the following timeline:
The specific jira item is GEOS-585 above.
For background reading please review the following documents:
- Feature Model Proposal
- Feature Model Design Discussion
- Evaulating Modeling Options
- some pdf into ISO 19109 from Bryce