As someone who is both an ESRI services user /developer and an open source GIS developer I thought It was interesting enough to write a blog post about it:
http://blog.gisky.be/2013/05/should-geoservices-rest-api-become-ogc.html#more bottomline: So you would expect that I'd support the Geoservices REST API as an OGC standard? Well, no. Quite a large number of valid points have been raised: the name is bad, the existing reference implementation is commercial without available sources, ... But I'd like to raise a different point: there are too many different services involved: the proposed standard comes in _8 different parts_, all covering services which in my opinion _unrelated_. This is the opposite of the unix philosophy: have one tool for the job. This is what in my opinion services should be about: have one service for every job, so one standard for every service. I don't understand why a good feature service should also provide geocoding, maps or any other service. Yet these small tools will not be able to comply to the standard because they can provide only one service. So my proposal would be: break up the proposal. Check where new standards may be useful or where RESTFul implementations of existing services (and we already have a long list) are more appropriate. The services provided by ESRI prove that such an implementation really boosts productivity. Johan _______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
