[OSGeo-Standards] [OSGeo-Discuss] Would you be concerned if the "GeoServices REST API" became an OGC standard?
Cameron Shorter
cameron.shorter at gmail.com
Sat May 4 14:21:10 PDT 2013
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
> Discuss at lists.osgeo.org
> 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
More information about the Standards
mailing list