This page aims to collate community concerns related to the adoption of the "Geoservices REST API" document as a standard of the Open Geospatial Consortium (OGC). The page has been collaboratively edited, and delivered by the board of the OSGeo Foundation (OSGeo) to the OGC and OGC voting members on Friday 17 May 2013.
The board of the Open Source Geospatial Foundation (OSGeo) is presenting this letter to the OGC. The letter highlights concerns about the "GeoServices REST API" from many people within the OSGeo community. As always, if there is anything the OSGeo board can do to help, then please let us know.
We, the undersigned, have concerns that approving the "Geoservices REST API" as an OGC standard, will 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. These concerns are described below.
Mark Lucas, Founding member and board of directors for OSGeo foundation, Principal Scientist for RadiantBlue Technologies Inc.
Landon Blake, GIS Department Manager/Land Surveyor at KSN, OSGeo California Chapter Board Representative.
Daniel Morissette, President at Mapgears, OSGeo Board member, core contributor and PSC member of Mapserver and GDAL/OGR. Former OGC TC member and involved in the implementation of several OGC WxS specs in MapServer.
Bob Basques, GIS Systems Developer at the City of Saint Paul, MN. Public Works GIS (GISmo), Technical Director at SharedGeo, OSGeo Charter Member, OSGeo TCMUG local chapter member, Co-founder and PSC member of GeoMoose project.
Pedro-Juan Ferrer Matoses, PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
María Arias de Reyna, software engineer at GeoCat, Spain, member of OSGeo Spanish Local Chapter.
Anne Ghisla, OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
Olivier Courtin, Oslandia co-founder, core contributor or/and PSC member of Mapserver and PostGIS. OGC TC member.
Anita Graser, GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
Sandro Santilli, OSGeo Charter Member, PostGIS and GEOS PSC member and core hacker.
Carlos Krefft, GIS software developer at CSTARS - University of Miami, OGC and OSGeo Member.
Benni Purwonegoro,Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
Alan Boudreault, Developer at Mapgears, contributor to Mapserver and GDAL/OGR.
Kumaran Narayanaswamy, CEO & Managing Director of kCube Consultancy Services Pvt Ltd India., Member of India OSGeo Chapter.
Luis Fernando Bueno, Professor at Federal University of Rondonia, researcher and GIS analyst, Brazil.
Bob Bruce, FEC, P.Eng., Geomatics Engineer, Winnipeg, Manitoba, Canada.
Gavin Fleming, OSGeo Charter member, owner of AfriSpatial.
Massimo Di Stefano , OSGeo Charter Member, Italy, founder-member of OSGeo Italian Local Chapter.
The OGC candidate standard titled "GeoServices REST API" is currently, in May 2013, being considered to be approved as an Open Geospatial Consortium (OGC) standard. The vote to accept the document as a standard is unusually contentious. The controversy is the cause of this open letter.
The candidate standard was previously released for public comment and can be found on the request for public comment page (though public comment has been closed for now).
The candidate standard attempts to standardize a suite of web services such as a service which provides map images, a service which provides geospatial feature data, and a service which performs geospatial processing. The candidate standard focuses on interactions via a defined hierarchy of URLs and using predominantly a particular set of JSON schemas for the exchange of geospatial data.
the lack of implementation diversity which is thought to give the vendor of the one complete implementation an unusual commercial advantage on top of the vendor's already dominant position in the domain.
These issues have potential impacts on the use of 'Open Standards' by governments and companies, on the interoperability of software interacting with standards compliant OGC services, on the costs to developers and users of standards compliant software, on the understanding of 'Open Standards' by the public at large, and, possibly, on the reputation of the OGC as a champion of interoperability.
The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
Sponsors (such as governments) who require compliance with OGC standards will discover that applications don't communicate together, due to applications supporting different OGC standards that essentially do the same thing.
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 to follow. To date, the OGC has provided this leadership.
there are alternative implementations for some of these services.
The authors also stress that the existence of a large user base shows the service is useful, and that the standardization of the services at the OGC may encourage new implementations.
The SWG has published two documents in response to various comments.
OGC 12-646 Response to RFC Comments presents the responses from the Standards Working Group to the comments received from the public during the public Request for Comments (RFC).
OGC 13-031r1 Response to 'no' votes presents the responses from the Standards Working Group to the reasons given by the organizations voting _no_ during the adoption vote.
Both are available through the links above, or via the public page of the Standards Working Group.
The discussion raises a number of issues, many based upon complex technical concepts and implications. This makes it difficult for voting OGC members considering whether to support (or not) the "Geoservices REST API" as a standard. The following provides one analysis of the positions on the vote, aimed to simplify and summarize key points. However, it does not necessarily represent the opinions held by all signatories above.
The OGC should be in the business of developing good standards, not in choosing which standards should be implemented.
The proposers of the document want to make a standard and have followed all the rules of the OGC. The work of any such group of members deserves serious, good faith consideration.
The need for an integrated suite of services using simple data, which is addressed (partially) by the document, is real. The proposed document is pushing the OGC on this issue.
The proposed document could be useful to a number of people.
"I know how totally impossible it is to write a good standard, so the weaknesses in the existing document seem more acceptable."
The OGC actually is, whether it should be or not, in the position of recommending interoperable standards for geospatial services. The proposed document is not good enough, has implementations dominated by one vendor's server implementation, and not publicly supported enough, to be considered at the same level as existing standards.
Adopting a standard implies a desire to maintain the standard, but OGC's desire to support this approach has been questioned by some. In particular, the lack of collaboration and willingness to accept recommendations from the community on this version of the "Geoservices REST API" document bodes ill for the future.
The overlap in functionality between the proposed services and the existing services, notably with the ongoing work to modularize the existing services, is almost 100 percent. However, compatibility is low.
There is already a published document: http://www.esri.com/library/whitepapers/pdfs/geoservices-rest-spec.pdf so there is no need for the document to be adopted as an OGC Standard merely for interoperability with the ESRI implementation.
The document, as a new, separate effort, repeats mistakes which were made and since solved by the other services.
The document focuses on the past (notably with backwards compatibility and use of only GET/POST) not on the future.
The document needs a comprehensive editorial review and substantial rewriting for clarity.
Both simple answers are bad.
A simple acceptance of the standard would introduce a new set of 'OGC approved' open services. The OGC approval might enable governments to buy a XXXX-new-name-here-XXXX solution instead of a W*S or a S*S solution. The path forwards towards harmonizing the services is unclear. Fixing this document in addition to fixing the W*S services will be a pain.
Simply rejecting the solution would be bad for the OGC. It would place the OGC in the position of picking winners and losers in the standards business. It would mean that the OGC is stuck on the project of fixing the W*S standards to meet some nebulous future functionality without having any path to get there. It would discourage innovation and progress.
Is there any third way?
Well, actually, there is a different way of thinking of the issue. Overall, there appears to be a shared desire for an integrated suite of geospatial services, originally focused on a simple data model, built on the exchange of well defined resources in simple formats including JSON, accessible and usable using the core HTTP verbs, and discoverable through following HTML links and patterns of URL paths. The hope is that such a suite can be designed based on the best expertise of the OGC, can be widely supported by the community, and can be implemented and tested by multiple groups. Neither the proposed document, nor the current services meet this vision. So the work, ultimately, is on improving all the services at the OGC, first to modularize them, then to enable simple implementations, and finally to link those implementations into a functional suite. Since this is the work that is already happening, perhaps the vote is an unfortunate distraction and the productive way forward is merely to redouble the efforts to create the next versions of the standards.
Beyond the controversy described above, there are issues with the Geoservices REST API document itself. Even if the standard deserves support, these issues could be considered blockers to the adoption of the current, May 2013, document.
The critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort and is beyond the scope and intent of this Open Letter.
The critique can be found at: http://wiki.osgeo.org/wiki/Geoservices_REST_API_critique.
Note that some of these critiques hold the document to OGC's current, standards writing guidelines. The OGC has been striving to develop better standards so new standards must meet higher requirements than past standards. The lack of clarity in the proposed document is not substantially worse than many published standards but ought to be resolved in new standards.
In summary, the ESRI "Geoservice REST API" Imaging part is at a technological level where WCS departed from some 5 years ago. Inconciseness of the specification at large will make it difficult for third parties to come up with interoperable implementations. The components making up the ESRI "Geoservice REST API" provide natural blocks assignable to the matching SWGs. As for Part 6 of the ESRI "Geoservice REST API", if to become a standard it needs to be discussed in the WCS.SWG for harmonization, clarification, and improvement.
The Geoservices REST API can not be amended (other than editorial changes in the specification document), because of a requirement for backward compatibility with the ESRI implementation. This has limited improvements in this version of the candidate specification.
Cameron Shorter's Will OGC’s standards meet government purchasing guidelines?
After delivery of this open letter, there were similar considered concerns raised by some members within the OGC community. As a result, the GeoServices REST API was withdrawn as a proposed OGC standard. The OGC then initiated an Ideas4OGC review, to rebaseline OGC priorities and processes in order to address weaknesses that had been identified in OGC processes.
This page was last modified on 30 July 2015, at 14:00.