Geoservices REST API

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard.

Open Letter to OGC and voting members

Please don't edit this "Open Letter" statement, comments and discussion should go below.

May 2013

We, the undersigned, have concerns that approving the "Geoservices REST API" as an OGC standard, would have detrimental impacts on interoperability within the spatial industry.

We strongly urge that the proposed "Geoservices REST API", as it stands in May 2013, be rejected as an OGC standard.

People have listed different reasons for concern. They are described below.

Signed

Please add your name here if you agree with the above statement. Include name, work title (if appropriate), very brief title/involvement in OSGeo if appropriate. (Link to OSGeo profile if appropriate). You may sign as a group, such as the Project Steering Committee of XXX project if you wish, or as Your Name on behalf of YYY company.

• Cameron Shorter, Geospatial Solutions Director at LISAsoft, core contributor & coordinator of OSGeo-Live
• Stephen Woodbridge, Director of iMaptools.com, Contributor and/or PSC of Mapserver, pgRouting, PAGC, and PostGIS

Concerns

--- DRAFT ____

Please add concerns as bullet points below. Try to be concise. Where appropriate, link to external web pages (such as email achieves)

Summary

As at May 2013, OGC members have been asked to decide whether to accept the "GeoServices REST API" as an OGC standard. This is a contentious issue, with many people arguing that introduction of the “GeoServices REST API” will have costly, far reaching, negative impacts on interoperability, and significantly tarnish the OGC's reputation as a champion of interoperability.

The key points of contention revolve around the fact that the proposed “GeoServices REST API does not build upon or extend existing OGC standards, but rather addresses similar requirements using an alternative API. In particular, the overlap and/or duplication of existing standards is widespread: OGC's core standards of WMS, WMTS, WFS, SE/SLD, WCS, CS/W are all duplicated to a significant extent. This defeats the purpose of having standards in the first place.

Duplication of standards will likely result in a combination of the following:

1. The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
2. Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
3. Sponsors (such as governments) who require compliance with OGC standards will discover that applications don't communicate together, due to applications supporting different variants of OGC standards.
4. This will result in a diminished importance of OGC, as the "OGC standards" stamp of approval will not equate interoperability.
5. After a while, in order to solve interoperability issues, a respected international organisation or program will likely take the initiative to mandate one standard as the preferred standard for all agencies will follow. To date, the OGC has provided this leadership.
6. One standard taking prominance over the other will likely lead to the other being neglected or deprecated, resulting in many OGC compliant systems becoming legacy systems in the process. This should be considered an undesirable outcome for a standards organisation.

History

Todo: please expand

• Explain how this standard came to be
• Based on Arc GIS Server API
• Attempted but failed to go through OGC fast track process
• Recent voting history: refer to: http://lists.osgeo.org/pipermail/discuss/2013-May/011602.html

References

Todo: Link to key external docs, such as the proposed standards