data access design goals
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
Namerather a simple String - we are getting too many collisions. - Info: the info proposal went through; make
ServiceInfoandResourceInfoobjects 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