Revision as of 01:13, 8 May 2013

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:

The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
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.
This will result in a diminished importance of OGC, as the "OGC standards" stamp of approval will not equate interoperability.
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.
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.

Political Concerns

Commercial Concerns

Technical Concerns

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

@@ Line 26: / Line 26: @@
 == Summary ==
-To do: Add a brief 3 paragraphs or so summarising the issues.
+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:
+# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
+# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
+# 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.
+# This will result in a diminished importance of OGC, as the "OGC standards" stamp of approval will not equate interoperability.
+# 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.
+# 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.
 == Political Concerns ==

Difference between revisions of "Geoservices REST API"