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

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