[Requests] Rewrite the proposed ESRI web service specification (12-059)
p.baumann at jacobs-university.de
Mon Jul 23 17:30:13 EDT 2012
p.baumann at jacobs-university.de
GeoServices REST API - Part 6: Image Service (12-059r1)
All requirements, plus the specification as such.
2. Implementation Specification Section number:
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