grid coverage exchange design - STEMLab/geotools GitHub Wiki

Overview

This is a implementation for Grid Coverage Exchange used as a driver for GeoTools 2.1. This work is now complete.

A followup project is available here: Community Discussion

Initial Idea for an API

GridCoverageExchange

  • peer of DataStoreFactoryFinder locates CoverageStore?

GridCoverageStore

  • peer of DataStore allows access to reader/writers
  • does this have metadata?

GridCoverageReader

  • access one file or wms request
  • access metadata as map or dom
  • accesss 1 or more grids defined by a file?
  • is metadata associated with each grid?

GridCoverageWriter

  • write one file or ?
  • write metadata

Initial proposed API

GridCoverageExchange

GridCoverageReader getReader( source, format )
GridCoverateWRiter getWriter( source, format, GridCoverage )

GridCoverageReader

GridCoverage read( name, params )

Format

ParameterInfo getReadParameterInfo()
ParameterInfo getWriteParameterInfo()

  • needs input params in addition to output params

Questions on API

Q: (Jessie): use of listSubNames is confusing - could this be implemented as just another parameter (the original spec did not have input parameters and could not make use of this idea).
Q: (Jody): subNames and read( name, Params) are inconsistent, how does one access the "root" (non sub) name? (or is that name=null?)
Q: (Jody): I assumed Source was filename/url Jessie asks about source being an inputStream? What can we do? Do we need a lower level api that works against inputstreams? Reading the javadocs others are expecting an input stream or file channel here? Confused - does this make GridCoverageReaders a one shot deal (this would allow dependency to constrain subname processing!)

Catalogish

Does the API provide a "discovery" mechanism - the GridCoverageExchange assumes a file system that can be navigated independently to provide the "name" or source parameter.

This kind of thing should really be provide by something based on a Catalog api. I am thinking of making a separate interface for the same that could be shared between implementations of DataStore and GridCoverageExchange.

Catalog Abstract Specification:http://www.opengis.org/docs/99-113.pdf

Web Map Server Workflow

This workflow assumes that multiple that Multiple GridCoverageExchanges are in play:

GridCoverageExchangeFinder

  • created by user
  • locate GridCoverageExcahnge instance based on URL

WMSGridCoverageExchange

  • created with a get capabilities URL (found by GridCoverageExchangeFinder when provided with a get capabilities url)
  • makes use of a single format: WFSFormat
  • implements a Catalogish getContents() method that lists a single entry "getMap" (or possibly two - one for a post getMap and one for a get getMap request?).
  • contains a getReader( source, Format ) method - where source has been chosen from the getContents() method

GridFormatFinder:

  • locate Format (can we call it GridFormat?) based on URL
  • not really useful for WMS ( more aimed at filesystem)

WMSFormat:

  • contains required Params (like bbox)

  • contains dynamic params from get capabilities request (like roadVisibility, roadStyle, riverVisiabley, riverStyle )

    WMSGridReader

  • created with a base getMap URL source object, and the WFSFormat described above

  • listSubNames() is empty

  • read(ParamList) creates a WMS getMapRequest based on the params, name is not required (could be used for a user supplied request "handle"?)

  • read( index, ParamList ) only works for the root aka 0 index

  • read(subname, ParamList ) is not implemented (or could select a single layer)

WMSGridCoverage

  • combines request information (bbox, crs)
  • with image from getMap request (may be png, jpeg, or wathever getCaps allows)

We can almost get to the "Single GridCoverageExchange" apprach. When WMS is provided as a Format, it could be sloted in right next to ArcGridFormat and friends. The downside is that Params represent our only oppertinuty to dynamically serve up the contents of the WMS getCapabilies request as parameters.

Idea This could be avoided by use of the separation between: getReader( source, Format ) and the resulting Reader.

If we assume that a call with getReader( url, WMSFormat ) we do not have to ensure that resulting reader actually uses the format as provided We can instead generate a new one with additional parameters (based on the url). Client code will have to call GridReader.getFormat() to retrive the correct reader - this extra level of indirection is complicated.

FileSystem based GridCoverageExchange Workflow

This is the workflow the origional spec was intended for, assumes multiple GridCovageExchanges are in play:

FileSystemGridCovergeExchange:

  • requires a directory URL (provided by a GridCoverageExchangeFinder)

  • provides several formats: ArcGridFormat, GeoTiff, etc...

  • implements a Catalogish getContents() method that lists a single entries for "recognized" files in the directory

  • contains a getReader( source, Format ) where Format may be null (in which case it is guessed by extension), and source has been chosen from the getContents method

    ArcGridFormat:

  • contains required Params (like isGRASS?)

    ArcGridReader

  • created with a complete path "directory/filename" source object and the ArcGridFormat described above

  • listSubNames() is empty

  • read( ParamList ) creates a ArcGridCoverage for the directory/filename

  • read( subname, ParamList ) is not implemented, can throw exception since client code should consult getSubNames

DataStore Extension

The following steps may be taken to "intergrate" the DataStore api with the new GridCoverageExchange API.

DataStoreFactorySpi

  • make use of ParameterList (rather than internal Param class)?

    DataStore:

  • getContents() is the Catalogish API that replaces getTypeNames()

  • getTypeNames() becomes convience method for iterating through each CatalogEntry and retriving each "name"

The idea here is to be able to drive the same UI screen(s) from both DataStore implementation and either of the GridCoverageExchange implementations above. Note Catalogish API is completly separate from both DataStore and GridCoverageExchange - the subclasses just implement both. This would make just DataStore API incomplete, the same manner of incomplete that GridCoverageExchange is incomplete. Client code would need to "know" what typeName to select, or look it up using the Catalogish API.