[Requests] GeoServices REST API - Extending current OGC WxS to support REST

ekeighan ekeighan at cubewerx.com
Fri Aug 17 15:07:18 EDT 2012


1.      Evaluator: Edric Keighan, Panagiotis (Peter) A. Vretanos, Jim 
Supple -- CubeWerx Inc.

2.      Submission: GeoServices REST API


1.      Requirement: All

2.      Implementation Specification Section Number: All

3.      Criticality: Major

4.      Comments/justification for changes: OGC Specifications are 
already being extended to support REST.

We recommend that OGC members continue to extend existing WxS standards 
to support REST, and decline the proposed standard entitled "GeoServices 

ALTERNATIVE A - Extend WxS to support REST
OGC members have already been active in introducing support for REST 
with the adoption of the OGC WMTS specification in June 2010. Currently 
the WFS working group is extending WFS to support REST, while continuing 
support for existing bindings (KVP-Get, XML-POST, and SOAP). See CR# 
157, OGC Document # 11-080 titled "A REST binding for WFS 2.0", dated 
2011-07-15 at https://portal.opengeospatial.org/files/?artifact_id=44852 
for more details. It is expected that the expertise gained from this 
effort through a standard and collaborative OGC consensus process will 
allow OGC members to introduce support for REST to all other WxS at a 
much faster pace than the time required to adopt the GeoServices REST API.


  * This enhancement process will produce acceptable REST standards that
    meet current REST requirements much sooner than the proposed
    specification, which is entirely new, redundant and incompatible
    with current WxS specifications.
  * These new WxS-REST extensions are simple and conceptually similar to
    the effort already undertaken by OGC members to introduce other
    bindings to OGC WxS.
  * It preserves OGC's investment into OGC core geospatial web services
    standards, vendors' investment into products using those standards,
    significant investments made by OGC Sponsors for commissioning such
    interoperable standards, and reduces overall financial risks for a
    world-wide geospatial community who has already deployed OGC-based
    SDI solutions.
  * It encourages product vendors to support richer products using more
    than one protocol within a single product, leading to better
    interoperability without increasing technical support costs.
  * It permits web services to support more than one protocol accessing
    the same content without duplicating storage or synchronize update
    transactions, and without increasing operational costs.
  * It supports an XML-based encoding.
  * It supports GeoJSON, a popular open data format encoding.
  * This approach, when extended in the decades to come to newer
    technologies, provides a graceful adoption of future innovations and
    protects investments in software & services & content.

We believe that none of the benefits from "Extending WxS to support 
REST" above would be possible with the proposed "GeoServices REST API", 
because of severe flaws in the concept, approach and implementation of 
the proposed specification.


After the initial comments received by the OGC REST SWG and over a year 
of effort to address them, the proposed "GeoServices REST API" still 
does not attempt to comply with, nor accommodate, existing OGC WxS 
standards; nor does it provide support for industry standard XML, nor 
GeoJSON. The proposed "GeoServices REST API", as proposed, is an 
inferior, confusing, single-vendor product that is incompatible and 
directly competing with existing OGC WxS standards in the same market.

The proposed "GeoServices REST API" is not necessary, given that current 
core OGC standards, and reference products based on them, are already 
being extended to support REST, probably with shorter delivery & 
approval times.

Edric Keighan, Panagiotis (Peter) A. Vretanos, Jim Supple
CubeWerx Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20120817/3c4ae6ef/attachment.htm>

More information about the Requests mailing list