Adrian,
Thankyou, I was hoping that someone such as your self with insights into
the standard would explain the details. You email has been a great help.
I'm also hoping that someone will provide a more detailed comparison of
the similarities / differences, to help the rest of the community
understand what is happening.
On 05/05/13 02:43, Adrian Custer wrote:
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
[email protected]
http://lists.osgeo.org/mailman/listinfo/discuss
--
Cameron Shorter
Geospatial Solutions Manager
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254
Think Globally, Fix Locally
Geospatial Solutions enhanced with Open Standards and Open Source
http://www.lisasoft.com
_______________________________________________
Discuss mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/discuss
