Difference between revisions of "Geoservices REST API"

From OSGeo
Jump to navigation Jump to search
Line 106: Line 106:
 
*** 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.
 
*** 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.
 
*** 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.
+
** 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.
  
 
== Methodological Concerns ==
 
== Methodological Concerns ==

Revision as of 08:41, 9 May 2013

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.

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 newcomer 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. 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.

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.
  • ESRI/OGC have specifically rejected requests to openly share their justifications document being selectively sent to OGC voters.

History

Todo: please expand

References

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

Retrieved from "http://wiki.osgeo.org/w/index.php?title=Geoservices_REST_API&oldid=70882"