[Requests] Rewrite the proposed ESRI web service specification (12-059)

Peter Baumann p.baumann at jacobs-university.de
Mon Jul 23 17:30:13 EDT 2012

Change Request


1. Evaluator:
     Peter Baumann
     p.baumann at jacobs-university.de

2. Submission:
     GeoServices REST API - Part 6: Image Service (12-059r1)


1. Requirement:
     All requirements, plus the specification as such.

2. Implementation Specification Section number:
     All sections

3. Criticality:

4. Comments/justifications for changes:

The documents proposed by ESRI for adoption at the OGC under the collective 
title "GeoServices REST API"
- is not in sync with several relevant OGC standards:
     * OWS Common
     * GML 3.x
     * GML 3.2.1 Application Schema - Coverages (GMLCOV)
     * Web Coverage Service (WCS)
     * WCS Application Profile - Earth Observation (EO-WCS)
The document introduces concepts, data structures, and services which are 
completely unsynced with the corresdonding adopted standards.

Re data, raster images are handled by this document - this is a coverage, and 
for coverages there are established data structures. However, the document does 
not at all rely on those, although terminology in many places heavily overlaps 
with OGC's coverage definitions. Additionally, the document lacks clear 
definitions of the terms used.

Further, there is an unfortunate mix and binding of services (here: catalog and 
imagery) which hampers modularity.

Finally, concepts appear rather low-level; for example, bands are numbered only, 
and pixel type does not contain rich enough information - eg, GMLCOV foresees 
the physical measure, like radiance in "W/cm2", while the new document just 
knows signed/unsigned int and float. What about pixels with different types, 
such as rainfall (int) and wind speed x/y (float)?

Re service, the Web Coverage Service (WCS) core and extensions, together with 
EO-WCS, establishes a set of functionality clearly transcending what is 
described in this RESTful interface. Rather, the interface described in the 
proposed document presents a monolithic block of functionality.

Some randomly picked extra functionality is packed in, such as colormap (what 
about WMS?) and NDVI (why exactl vegetation and no other differential index?). 
Functions are not described, but just named, such as "Slope". The WCS suite, for 
such tasks, offers a generic language for specifying any kind of such 
algorithms, with an unambiguous semantics.

It is suggested, therefore, to re-establish this document as an extension to the 
WCS where a RESTful interface fits in well and is compatible in terms of data, 
functionality, and protocol standards. The same holds for JSON as a coverage 
exchange format: it can be embedded smoothly into the GMLCOV / WCS orchestration 
of different image formats; note that GMLCOV allows to have mixed 
representations (XML + a binary format), so this is supported likewise and can 
be extended, eg, with JSON.

If adopted as is, OGC will have a new miniworld inside OGC which is isolated 
from and incompatible with OGC standards at large.

Dr. Peter Baumann
  - Professor of Computer Science, Jacobs University Bremen
    mail: p.baumann at jacobs-university.de
    tel: +49-421-200-3178, fax: +49-421-200-493178
  - Executive Director, rasdaman GmbH Bremen (HRB 26793)
    www.rasdaman.com, mail: baumann at rasdaman.com
    tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)

More information about the Requests mailing list