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

[bruce.bannerman.osgeo]

Cameron,

My personal opinion is that if this proposal was accepted, it would be a bad move for OGC.

Remember that OGC is a community and its Technical Committee membership are the people who vote on the acceptance of Standards. The TC comprises many different organisations.


I do understand that OGC are trying to be inclusive in their processes and to try and cater for alternative approaches to a problem, much the same as OSGeo does in supporting multiple projects that essentially handle similar use cases (e.g. GeoServer, MapServer and Degree).

I have also personally witnessed ESRI's commitment to helping to further the development of Open Spatial Standards through their work on OGC Working Groups and at OGC Technical Committee meetings.

ESRI also have made a valid point in their response to the 'NO' vote for the GeoServices REST API that the OGC has already allowed alternate approaches with the acceptance of netCDF as a data format and KML as a combined data/presentation format.

With the GeoServices REST API, I think that the approach proposed:

- is very divisive for the OGC community.
- essentially appears to propose an alternate way for working with spatial services that does not utilise or build on the W*S suite of services that have been developed through robust community processes for in excess of a decade.
- does not provide REST bindings to the W*S suite of standards that have been widely implemented in a range of software.
- will result in confusion within the user community that are trying to utilise 'OGC' services.


If this approach were to be adopted, I believe that OGC will go too far down the alternate solution approach and will risk losing its public acceptance as one of the key leaders of open spatial standards.


I'm interested in hearing other OSGeo members opinions as to how this proposal would affect their projects.

Would you consider implementing the GeoServices REST API within your projects?

If you did, would you maintain support for both it and traditional W*S services?

Bruce

On 05/05/2013, at 7:27 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