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

Reply via email to