[OSGeo-Discuss] Would you be concerned if the "GeoServices REST API" became an OGC standard?

Adrian Custer acuster at gmail.com
Sat May 4 09:43:21 PDT 2013

Dear Cameron, all,

There is indeed a massive conflict at the OGC related to this proposed 
standard and it may be useful to inform this list about that conflict 
and the process.

However, I am unsure how expanding the *discussion* here helps.

The proposed standard aims to document a series of web services and a 
JSON based data exchange format. The standard comes in eight parts

  12-054r2 	  GeoServices REST API - Part 1: Core
  12-055r2 	  GeoServices REST API - Part 2: Catalog
  12-056r2 	  GeoServices REST API - Part 3: Map Service
  12-057r2 	  GeoServices REST API - Part 4: Feature Service
  12-058r2 	  GeoServices REST API - Part 5: Geometry Service
  12-059r2 	  GeoServices REST API - Part 6: Image Service
  12-060r2 	  GeoServices REST API - Part 7: Geoprocessing Service
  12-061r2 	  GeoServices REST API - Part 8: Geocoding Service
and there are also
  12-068r2	  GeoServices REST API - JSON Schemas and Examples

The documents describe the functioning of a set of web services, 
developed originally by ESRI, and the JSON format for many objects, also 
defined by ESRI, and used by those services.

The OGC request for comments (now closed) is here:
with each of the documents.

Note that Cameron was either unclear or incorrect in his presentation of 
where the standard now stands.
   * The document was released for public comment. (see above)
   * A response to all the comments was issued. (however incomplete)
   * The document was then released for a vote.
   * The vote was suspended because two 'no' votes were heard.
   * A response was issued to the 'no' votes.
   * The vote was resumed
   * The vote was (re) suspended because two additional 'no' votes
     were heard, with new arguments.

   => the vote is current suspended awaiting
        (1) a response to the new reasons, and
        (2) a decision of what to do next by the leadership of the
            OGC technical committee (where all this work happens),
            since we have not yet faced such lack of consensus.

The proposed standard has been controversial from the start at the OGC. 
The controversy, as best as I can tell, centers on the following issues:
   * no backwards incompatible changes were allowed,
   * no work was done to integrate the proposed services with existing
     OGC services (W*S, ...),
   * the only implementations are by ESRI and its partners,
   * the name of the standard and services are not accurate or distinct.

Banning backwards incompatible changes is controversial both because it 
blocked collaboration at the OGC (which essentially had to approve the 
ESRI implementation as is) and because it prevented things like using 
GeoJSON where appropriate. Also, going forwards, backwards compatibility 
will have to be maintained giving the existing implementations (i.e. 
ESRI's) a huge advantage in defining extensions (ESRI already has a 
number in the pipeline).

The lack of integration with existing services is controversial both 
because they made no effort to work with the existing working groups and 
because it splits the work of the OGC into competing efforts. There is 
no clear path forwards towards harmonization despite the fact that most 
groups working on OGC Services are tackling issues in the same area 
(simple services, JSON exchange format, REST design).

The dominance of ESRI is controversial both because the working mode 
lacked any collaborative spirit and, perhaps most critically, because 
this is seen as a way through which ESRI can bring its own service onto 
an equal footing with the current, public OGC standards in the 
government procurement game. Governments are shifting towards requiring 
that all spatial software conform with published, open standards; the 
proposed standard, if adopted, would allow ESRI to push its own software 
as also an "Open Standard" and compete on an unequal footing with 
implementations of the software being worked on by everyone else.

The name of the standard 'GeoServices REST API' and the services are 
controversial for many reasons. The 'GeoServices' moniker is 
non-descript (many OGC standards are for geospatial services) and 
matches the current ESRI marketing terminology. 'REST' is a buzzword and 
implies a lot of design work which has not been done (and is happening 
elsewhere at the OGC); furthermore, if REST is about the design of a 
service's behaviour (that the service acts based on the transfer of 
representations of resources), then the word does not relate to an 
'API'. Finally, the 'API' word does not really describe the standard 
which is describing a number of services and data exchange formats. The 
names of each service, e.g. either 'Map Service' or 'GeoServices Map 
Service' is problematic: how do we make sure that people know the 
difference between the 'OGC Web Map Service' and the 'OGC GeoService Map 
Service' ?

However, despite these criticisms, note that a number of members of the 
OGC members feel that the OGC should be in the business of releasing 
standards and letting the marketplace decide which standards to adopt, 
implement, and use.

My personal feeling is that the name must be changed to clearly separate 
this set of services from the others. Beyond that, I am not against a 
new competing standard, even despite the huge advantage it gives ESRI in 
a market it already dominates. However, I would not mind seeing the 
standard fail, if only to show groups the consequences of trying to 
railroad documents through the standards group rather than building 
support for them through open collaboration.

Which brings us to OSGeo and what useful contribution it could make to 
the debate. Simply rehashing the issues above is not going to be useful 
to anyone. If new ideas arise, or a large, common position emerges on 
the issue, I'd be glad to inject them into the OGC discussion.

I suspect there is at least a week before voting resumes, although the 
rules going forwards are not yet clear.


On 5/4/13 7:46 AM, Cameron Shorter wrote:
> OSGeo Community,
> Currently, voting OGC members are to decide whether to accept the
> "GeoServices REST API" as an OGC standard. This is already a contentious
> issue, with 13 votes for, and 10 votes against, 72 outstanding votes,
> with voting halted temporally, being reopened again in a few days, and
> closing 2 weeks after that. [1]
> I'm wanting to hear whether people in the OSGeo community have strong
> opinions regarding this proposed standard, and whether we as a
> collective OSGeo community should make statements to the OGC, and voting
> OGC members, stressing our thoughts.
> If there is sufficient interest, I'll raise this issue with the OSGeo
> Board, with the intent of drafting a statement on behalf of OSGeo.
> As background:
> * "The API was initially developed by Esri and implemented on the ArcGIS
> for Server platform." [2]
> * The proposed GeoServices REST API specification overlaps with most OGC
> standards already deployed, including: WMS, WMTS, WCS, WFS, SE/SLD,
> CS/W. This effectively means that for most use cases covered by the
> GeoServices REST API, applications would now have two standards to
> support. Also, spatial infrastructure programs will be impacted, as OGC
> compliance won't necessarily equate to interoperability.
> * Most (all?) current OGC web service standards to date have an Open
> Source reference implementation, which was often (always?) part funded
> by OGC testbeds, and open source implementations were tested against
> proprietary implementations during OGC testbeds. As far as I'm aware,
> there has been very little up-take from the Open Source community of the
> "GeoServices REST API", and I'm unaware of any testing of non-ESRI
> applications during OGC testbeds. (Someone may be able to correct me here).
> [1]
> https://portal.opengeospatial.org/?m=projects&a=view&project_id=82&tab=5&subtab=0
> (OGC member login required. Votes counted as at 4 May 2013)
> [2] http://www.opengeospatial.org/standards/requests/89

More information about the Discuss mailing list