org.geotools.data

All DataStores (e.g. PostGIS, Shapefile(tm), GML...) must provide implementations of the DataStore interface and the DataStoreFactorySpi interface. These interfaces allow new types of datastore to be plugged into applications which use geotools without the need to modify any code.

Example:

FeatureStore postgis = new PostGisDataStore( ... );
Query all = Query.ALL;
FeatureType roadType = postgis.getFeatureType( "roads" );

// reader 1 streams over all roads
FeatureReader reader1 = postgis.getFeatureReader( roadsType, all, Transaction.AUTO_COMMIT );

// allRoads = featureResults is a prepaired query of all roads
FeatureSource roads = postgis.getFeatureSource( "roads" );
FeatureResults allRoads = roads.getFeatures( all );

// reader 2 & 3 streams over all roads in the same manner as reader 1
FeatureReader reader2 = allRoads.reader();
FeatureReader reader3 = allRoads.reader();

// bounds1 returns the bounding box of roads, may be null depending on expense
Envelope bounds1 = roads.getBounds( all );

// bounds2 returns the bounding box of roads, may actually calculate by going over the entire dataset
Envelope bounds 2 = allRoads.getBounds(); 

The goal is to have this class provide everything else if you can only provide:

• String[] getFeatureTypes()
• FeatureType getSchema(String typeName)
• FeatureReader getFeatureReader( typeName )
• FeatureWriter getFeatureWriter( typeName )

• Filter getUnsupportedFilter(String typeName, Filter filter)
• FeatureReader getFeatureReader(String typeName, Query query)

All remaining functionality is implemented against these methods, including Transaction and Locking Support.

This class assumes the DataStore represents a single source, represented by a URL.

This query is used to retrive all Features.

The basic idea is to have simple, very general interface to access and query data that is in some way or another spatially enabled.

This class was used back in Java 1.3 before the initCause() method was available for IOException.

The source of data for FeatureTypes.

An instance of this interface should exist for all data stores which want to take advantage of the dynamic plugin system.

Please optimize this class when use with your own content. For example a "ResultSet" make a great cache for a JDBCDataStore, a temporary copy of an original file may work for shapefile etc.

Used to implement In-Process Transaction support.

The "Source" FeatureEvents is taken to be a FeatureSource, rather than DataStore.

Features from individual shapefiles, database tables, etc.

Individual Shapefiles, databases tables , etc.

Individual shapefiles, database tables, etc.

Capabilities:

• Similar API to FeatureReader
• After aquiring a feature using next() you may call remove() or after modification write().

An experimental method for doing FIDs.

This query is used to retrive FeatureIds.

This interface includes some new functionality, and acts as a method of discovery for DataStoreFactories which support singular files.

Most of this code was copied from DataStoreFinder.

This implementation writes out content furing the hasNext() method.

The query object is used by the FeatureSource.getFeatures(Query) to encapsulate a request.

Access to the spatial information in a filtered/queried or not.

First draft of a Store interface based on brain storming session with Jody, Thomas, Stefan and Cory in Refractions on November 24th.

Shapefiles, databases, etc.

The parameters found in the file should be as follows:

1. size of pixel in x direction
2. rotation term for row
3. rotation term for column
4. size of pixel in y direction
5. x coordinate of centre of upper left pixel in map units
6. y coordinate of centre of upper left pixel in map units

It is worth to point out that various data sources describe the parameters in the world file as the mapping from the pixel centres' to the associated world coords.