Skip to end of metadata
Go to start of metadata

This is the subject of (minus) active development on the GeoAPI Feature Model interfaces.

For details of the API please review the nice pictures 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.

  1. 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
  2. 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
  3. 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)
  4. 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
  5. Use of Builders
    • Builders should only ever be a local variable, or used in one synchronized method.
  6. 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.
  7. 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 (smile)
Example

All of Data basically fails and will need to be fixed. You can see this failure when ever you see a FeatureBuilder (or any Builder) passed around as a parameter between classes, or stored for reuse). This is hard to test as the problem will only occur when the DataStore is being used by two threads (or if a FeatureCollection is being used by
two threads).

Active Development

com.atlassian.confluence.macro.MacroExecutionException: JIRA project does not exist or you do not have permission to view it.

You can also track change requests against the GeoAPI interfaces here:

com.atlassian.confluence.macro.MacroExecutionException: JIRA project does not exist or you do not have permission to view it.

Since the GeoServer community is championing this effort most of it shows on on the following timeline:

com.atlassian.confluence.macro.MacroExecutionException: JIRA project does not exist or you do not have permission to view it.

The specific jira item is GEOS-585 above.

History

For background reading please review the following documents:

For solid use cases please review the results of the ComplexDataStore project, especial the uses cases in Community Schema Support and Complex Types.

  • No labels