OGC Abandons the Web

geospatial 2 Minutes

Those are my words, not theirs.

It came to light today that OGC has decided to withdraw the GeoServices REST Specification, also known as the “ESRI REST API,” as a proposed standard. I will not take up the relative merits of the specification or the implications of OGC potentially adopting an industry-developed specification that has so much implied workflow embedded in it. With this decision, three facts remain unaltered:

  1. The ESRI REST API will continue forward as a widely-used de facto standard in the form of ArcGIS Server installs and other emulations, such as that in Arc2Earth.
  2. GeoJSON will continue forward as a widely-used de facto standard in the form of numerous open-source implementations.
  3. OGC still has no JSON syntax.

Yes, twelve years after the birth of JSON, five years after the release of the ESRI REST API and its embedded JSON syntax, and five years after the release of GeoJSON 1.0, OGC is still has no entry in the JSON space. Between Esri and GeoJSON, the utility of JSON in web mapping applications has been roundly proven. In the ESRI arena, find me anyone who willingly uses the SOAP API these days while the adoption of support for GeoJSON across the open-source GIS world speaks volumes. The industry has voted with its feet and its code as to what it prefers.

There’s probably a lively discussion to be had about where JSON should fit into OGC’s priorities. What is clear, however, is that Javascript and JSON are driving the web at large and the web-mapping space in the geospatial market. With no official stance of any kind in this area, it becomes increasingly difficult to take OGC seriously in matters of the modern web.

Howard Butler had a great point a while back when discussing the potential adoption of the GeoServices REST Specification:

The irony here is that the withdrawal of the specification accomplishes the same thing. I won’t go so far as to say OGC has no clue or doesn’t care but, in the perception-is-reality department, they look pretty out-of-touch these days. Is this a problem with process? Maybe. Is it a problem with message? Definitely. The message I’ve gotten from this whole episode is that we can keep doing what we’ve been doing with our web mapping applications because OGC has nothing for us.

Published by Bill Dollins

Published

12 thoughts on “OGC Abandons the Web”

  1. Your post elicits a couple of immediate reactions in me. The first is that there is no reason a WFS server could not return GeoJSON now as a supported format. In fact, I believe MapServer can do that now with the right configuration. The second point is that the withdrawal of the geoservices spec is in theory to allow further work and incorporation of the various community input.

    I’m very supportive of REST bindings of the existing suite of server types and broader support for GeoJSON as pragmatic steps. But then I’m a dinosaur and don’t really think we need to throw out everything every five years in favor of the new hotness.

    1. Thanks, Frank. I don’t disagree with any of that. Part of the reason avoided any specific discussion of GeoServices is because I don’t mind its withdrawal. I actually prefer working with GeoJSON. We all know the JSON syntax of GeoServices goes well beyond representation of features and geometries because it needs to support to workflow implicit in the spec. I think acceptance of the spec would have created a hurdle for GeoJSON until such time as harmonization could occur.

      You and I are probably very close in our views on this. I think I am also a dinosaur and would prefer to see such pragmatic steps as well. I’m not sure the GeoServices episode did much other than cost time.

      1. “I’m not sure the GeoServices episode did much other than cost time.”
        ^ This is also my distinct impression, but I can’t help but think the fallout of adopting the ESRI way would have it’s own possibly greater cost in the long run. There’s no doubt the entire affair highlighted OGC shortcomings in adopting timely standards. Hopefully all of this will put the spurs in and make up for the time spent on this boondoggle. Good post on the matter.

    2. Yes, there are a number of WFS instances that return GeoJSON encoded payloads. exactAIS is the latest product to do so. There is nothing in the OGC WFS standard that precludes using other response encodings. You could return CSV if you wanted to.

  2. oh man, now the REST buzzword is going to be replaced by JSON? We might look deper and find out that (i) OGC is about open standards, and the so-called ESRI GeoServices REST API is all but open, by construction of the process. Good that OGC and the ocmmunity recognized this and acted.

    And (ii) closer investigation shows that this spec, while combining all buzzwords that high-level decision makers like to hear, is technically lagging behind 10 years and is ill-specified. It’s not even RESTful, but that’s the least problem in fact.

    OGC’s W*S suite has proven its openness, and discussions about how to advance it actually is documenting this. Who ever discussed about changing anything in the so-called GeoServices REST API? It was the open community, OSGeo and OGC.

    I’m glad we have them. My personal opinion.

    1. No, I’m not linking JSON to REST. JSON, XML and many other formats are perfectly valid representations of resource states. I intentionally did not discuss the merits of the specification because, over time, I have come to believe that it would not make an appropriate standard.

      Unlike KML, the GeoServices specification has a lot of implied workflow that is closely bound to its current ArcGIS implementation. Adopting that implied workflow would probably have big ramifications for existing products that feel the need to maintain OGC compliance. It would also give a leg up to a specific member of industry, which is clearly something an organization like OGC, which strives for neutrality, should not do.

      No, I was simply discussing a fundamental piece of the modern web, which has yet to be meaningfully addressed by OGC.

    1. I haven’t looked at it in a while but probably need to circle back to it. Simple features is one of OGC’s quieter success stories and I’m usually comfortable seeing it in the mix.

  5. Can’t we just use WMS and pay OpenGeo and the OSGeo gang to make it work for us? Sadly it was an example of squeaky old cogs getting the oil.

Comments are closed.