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. It is being collaboratively edited, targeting completion before the end of May 2013.

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
• Even Rouault, Geospatial developer, OSGeo Charter Member, core contributor and PSC member of GDAL/OGR, contributor of Mapserver, PROJ.4, libgeotiff, shapelib, libtiff
• Gerhard Triebnig, Managing Director at EOX IT Services GmbH
• Brent Wood, Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
• Stephan Meissl, CTO at EOX IT Services GmbH, contributor to Mapserver, PSC chair of EOxServer
• Jeroen Ticheler, Director of GeoCat, project founder and PSC chair of GeoNetwork opensource
• Just van den Broecke, Director at Just Objects, contributor to Heron Mapping Client, secretary of OSGeo Dutch Local Chapter, member at OpenGeoGroep
• Milo van der Linden, member at OpenGeoGroep
• Landon Blake, GIS Department Manager/Land Surveyor at KSN, OSGeo California Chapter Board Representative.
• Daniel Morissette, President at Mapgears, core contributor and PSC member of Mapserver and GDAL/OGR. Former OGC TC member and involved in the implementation of several OGC WxS services 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.
• Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
• 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.
• Micho Garcia, Freelance and member of geomati.co, Spain, member of Spanish Local Chapter
• Margherita Di Leo, OSGeo Charter Member, Italy
• Jorge Sanz, GIS Consultant at Prodevelop, OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
• Pablo Sanxiao, CTO and co-founder at iCarto, OSGeo Spanish Local Chapter Member, Spain
• Frank Steggink, GIS software developer at Vicrea, The Netherlands, member of the Dutch Local Chapter
• Olivier Courtin, Oslandia co-founder, core contributor or/and PSC member of Mapserver and PostGIS. OGC TC member.
• Wladimir Szczerban, OSGeo Spanish Local Chapter Member, Spain
• Anita Graser, GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
• Volker Mische, geospatial software engineer, creator of GeoCouch
• Iván Sánchez, OSGeo Spanish Local Chapter Member, head of OpenStreetMap Spain, OpenStreetMap Foundation member, Humanitarian OpenStreetMap Team member, Spanish SDI working group member
• Gabriel Carrión, Strategy Manager at gvSIG association
• Sandro Santilli, OSGeo Charter Member, PostGIS and GEOS PSC member and core hacker.

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 OGC standards that essentially do the same thing.
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 to 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. Backward compatibility to the existing WxS standards is important in this respect.
7. Given backwards compatibility with the ESRI Restful implementation is mandated, this is not an Open Standard, and should not be ratified as if it was.

Political Concerns

• Adopting the standard will expose the OGC to a strong suspicion of acting as a rubber stamp organization under ESRI weight, and will be detrimental to its recognized position as a reference organization for geospatial standards.
• It is a dubious practice that a standardization organisation promotes competing standards, without explicitely obsoleting (or at least recommending) some of them. How is a new comer to the industry supposed to select the appropriate standard if several ones share the same scope : WFS or GeoServices REST API Feature Service, WMS or GeoServices REST API Map Service, etc. ?

Commercial Concerns

• Promoting standards from an existing implementation made by a single vendor leads to an obvious bias in competition.
• Supporting multiple overlapping standards greatly reduces usability while it increases complexity and cost of development and maintenance.
• Many SME's have invested in supporting existing OGC standards in their products. They will be forced to choose the standards they support (and can explain), resulting in decreased interoperability, confusion and frustration for clients.
• Confusing customers with new, overlapping OGC standards will lower the credibility of companies and of OGC, reducing business opportunities.

Technical Concerns

• The Geoservices REST API overlaps in large proportion with existing OGC standards such as WMS, WCS, WFS, WMTS, CSW, with no effort made to reconcile with those standards.
• The standardization of WKT for Spatial reference systems is unfortunately currently quite weak in OGC standards. Geoservices REST API is tied with ESRI's version of WKT, which is not properly specified in the Geoservices REST API documents, and is known to be incompatible with other OGC documents, which will lead to a larger confusion. See the following comment for more details on this issue.
• The Geoservices REST API is not particularly RESTful - it's a thinly disguised service call, not an address space for RESTful objects that can be operated on.
• At least as far as "imagery" is concerned, OGC standards arguably are substantially more mature, powerful, flexible, and modular then the ESRI "Geoservice REST API" Part 6 (and some design principles suggest that scalability may be hampered as well):
  • data model:
    • the ESRI "Geoservice REST API" appears constrained to 2-D imagery, plus optional time stamps. OGC has established a unified coverage model which fully supports n-D spatio-temporal data. It allows use and exchange of coverages between different services, such as WCS, WCPS, WPS, and SWE.
    • OGC coverages support both regular and irregular grids; the ESRI "Geoservice REST API" supports only regular grids, more specifically: only rectified grids with quadrilateral pixels.
    • the ESRI "Geoservice REST API" lacks support for temporal data; it only offers timestamps, measured in milliseconds; this is inconvenient for users and immediately excludes, e.g., geological dates. OGC has established uniform handling of horizontal, vertical, and temporal coordinate reference systems (CRSs), following a deep consensus process with GIS science and backwards compatible with EPSG. The ESRI "Geoservice REST API" specific way of handling coordinates is not known to support this, thereby excluding appropriate timeseries handling in remote sensing, air traffic, MetOcean, etc.
    • OGC coverages provide a concise, versatile model for supporting different binary formats; the ESRI "Geoservice REST API" supports only very few selected 2-D formats, excluding, e.g., JPEG2000, NetCDF, HDF, etc.
    • the ESRI "Geoservice REST API" lacks a clear model of their data structures, it can be deduced only implicitly from the operation mechanics.
  • service model:
    • The ESRI "Geoservice REST API" Part 6 lacks conciseness, thereby opening up ways for implementations that are not interoperable. For developers of alternative implementations this may mean they have to acquire ESRI licenses for finding out the intended behavior.
    • Functionality in the ESRI "Geoservice REST API" appears randomly chosen, with no clear concept visible; this burdens implementers while still leaving holes of functionality. For example, this functionality appears restricted to mapping applications and does not easily extend into other domains.
    • It has been said that the ESRI "Geoservice REST API" can be seen as a "wrapper around OGC W*S" services. This is not true for WCS (and WCPS), at least: the ESRI "Geoservice REST API" Part 6 is too poor in functionality and too different in mechanics to accomplish this.
  • 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. Therefore, Part 6 of the ESRI "Geoservice REST API", if to become a standard, needs to be discussed in the WCS.SWG for harmonization, clarification, and improvement.

Methodological Concerns

• No public response (nor private to the authors of the comments) has been made to the various comments sent on the OGC Requests mailing list in [July 2012] and [August 2012] during the 30 day public comments period.
• The Geoservices REST API can not be amended (other than editorial changes in the specification document), because of a requirement of backward compatibility with ESRI implementation. Consequently, the standard is unlikely to improve, or its evolution will be only lead by ESRI.
• OGC standards normally require interoperability experiments and a richer process to ratify a standard such as this one. No explanation has been forthcoming as to why a simplified process is appropriate in this case.

History

Todo: please expand

• Explain how this standard came to be
• Based on ArcGIS 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