Tuesday, May 7, 2013

Should the "Geoservices REST API" become an OGC standard?

ESRI recently submitted their ESRI server REST standards to the OGC. Currently, the voting members have to decide whether they accept the proposal or not. As one of the contributors to the OSGEO-Live dvd, Cameron Shorter invited me to the discussion at Osgeo discuss list.
This discussion comes at an interesting time. Just a few weeks ago I did a session on geospatial web services in my company. The actual reason that we covered this topic is that there are two interesting (and diverting) trends happening at the same time:

  1. The current OGC standards are finally taking off. Ever since our governement started serving their large-scale reference maps as publicly available WMS services, I see them being used  by many of our customers
    At the same time, I managed finding interesting data sets using CSW services for the first time, and the fact that view and metaservices have to be provided for INSPIRE III themes by the end of the year will probably mean that the shift to using services is finally taking off. 
  2. On the other hand RESTful GIS services  have started popping up everywhere. ESRI's proposed Geoservices REST API is one, GeoREST is another one which I've enjoyed using. 
Actually my first thoughts when using ESRI's api was a sense of relief: I really enjoyed using these services. The fact that I can just tinker using an URL rather than having to use a special SOAP client was nice. My productivity as a programmer increased enormously. I couldn't figure out why anybody would want  to use SOAP-like services (without going in a semantic discussion).

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. 


  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
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. 

One tool for every job? Image source


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.

And actually while doing this, perhaps we should immediately consider using binary data where appropriate. I started off by saying that web services are finally being used. I did not mention WFS. This is logical. Nobody likes WFS. It is too slow. If WMS would contain an xml record for every pixels with an attribute for every color nobody would use it either. No, WMS sends a binary image. Why isn't  WFS doing the same and sending vector data in a binary form? 

4 comments:

  1. About WFS and binary output, you can already specify the OUTPUTFORMAT of the GetFeature request to something different from GML. Mapserver or Geoserver can for example output shapefiles.

    ReplyDelete
    Replies
    1. That's definitely nice and I could find many uses for it, but ... it is not a standard. So most clients don't support it.

      Delete
  2. Hi there Johan.

    I really feel the same when using ESRI's rest api. It's so simple comparing to everything else that it's a joy. Other than just plain WMS there really is something to be gained from standardizing this api. I also agree with some of the criticism but overall I feel the community would gain on the long run. Your proposal of breaking the proposal into several could also allow for progressive standardization that would give time to all the players for adoption. I.e. start with Core and MapService. Later go on with Feature and Geometry...

    ReplyDelete
    Replies
    1. Thanks for your comments. In a way, I think the way that ESRI (and others eg georest) is definitely the way forward, and that it will happen independent of whether this proposal is honoured by the OGC or not. Compare it to Microsoft XMLHTTP. It was never a standard, but it happened to become the start of AJAX which we all use now.
      What I dislike about the proposed API is that it leaves no room for improvement. Perhaps with minor changes we can have a standard with a broader support which is also more future proof.
      And if we start out, I would not start with mapservice. I don't see a future for mapservices other than basemaps for which we have a good simple standard(TMS, not an OGC standard btw or WMTS), and otherwise we can fall back on WMS which works good enough. What we really need is a good "feature" service. HTML 5 can handle 2 million features (see eg http://www.giscloud.com/blog/gis-cloud-starts-html5-mapping-revolution ). Why should we render images on the server if we can have interactive maps on the users pc?

      Delete