Data Access Design Goals - STEMLab/geotools GitHub Wiki

This section is usually a waste of space in a change proposal; but we are including it here so that additional data access APIs can be introduced into the library in a consistent fashion.

Goals:

• Name: Identification should be handled using Name rather a simple String - we are getting too many collisions.
• Info: the info proposal went through; make ServiceInfo and ResourceInfo objects avaiable; extend if extra data is needed for your service
• Admit to Reality: something like FeatureReader and FeatureWriter exist; make them available even if it does not fit with some grand vision

We would like all of our data access interfaces to have a similar approach and operate in a similar style.

An interface should be defined to represent the service being offered. To be consistent with the info proposal it should have the following methods (by convention).

Method

Description

getInfo(): ServiceInfo

describe the service as a whole

getNames(): List<Name>

list of available resources

getInfo(Name): ResourceInfo

describe the contents

There should be explicit methods to access the resources served up by the service; if the service offers multiple levels of support then several methods may be needed.

Where possible the methods should be based on the OGC counterparts. As an example the WFS was used to generate:

Method

Description

DataStore.getFeatureSource( Name ): FeatureSource

with methods based on minimal compliant WFS

getFeatureStore( Name ): FeatureStore

With methods based on the operations for WFS-T

GetFeatureLocking( Name ): FeatureLocking

With methods based on optional locking support

As an example ArcGridAccess could implement:

• GridAccess - an interface based on WCS specification (ie raster access)
• CoverageAccess - an interface based on ISO defintion of coverage (ie give me a record for this location)
• DataStore - serve up read only access to all the pixels; as a bunch of square features