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
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Reply via email to