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:
http://www.opengeospatial.org/standards/requests/89
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.
cheers,
~adrian
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
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
