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

Mon May 6 01:43:35 PDT 2013

Adrian sums up the problems and the discussions that were happening
really well. I fully agree with the problems that arise.

I just want to add that from my perspective this isn't an anti-ESRI
campaign from some OSGeo fellows, but it's against one company pushing
something through the OGC that defeats a lot of the efforts from the
people that want to have open standards for the greater good.

I appreciate that ESRI publishes their specification of the product, so
that others don't need reverse engineer it in case you want to have
interoperability. Though it would make much more sense to me to have it
published on their website and not having it pushed through the OGC to
have some approval from a standardisations organisation. It really
describes their product and it's not about harmonisation/interoperability.

Cheers,
  Volker

On 05/04/2013 06:43 PM, 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