Slashdot Mirror


GIS Community Blocks Esri's Geospatial 'Open Standard' REST API

Bismillah writes "The developer of ArcGIS, Esri, has dropped its bid to have the GeoServices REST API recognized as an open standard by the Open Geospatial Consortium, after a community backlash against 'providing a vendor with significant market advantage, erring on the creation of a state-sanctioned monopoly.'"

13 of 53 comments (clear)

  1. Re:Lesson learned by gandhi_2 · · Score: 3, Interesting

    ESRI is THE 800 pound gorilla in GIS.

    The FOSS offerings are pretty cool, but I see no "black swan" like MySQL was to Oracle DB coming along in that space any time soon.

  2. Here is Open Letter from the open source community by Anonymous Coward · · Score: 2, Informative

    I have been following this one on the sidelines, while I was initially annoyed with a version 1 standard not accepting change requests due to reasons of backwards compatibility (a very poor attitude). The real annoyance was ignoring/subsuming the GeoJSON work that has been really earning its keep for web mapping.

    In anycase the Open Geospatial Consortium put together a letter here (http://www.lisasoft.com/blog/open-letter-ogc-re-geoservices-rest-api) which may of had some influence. A nice write up of the technical problems is here (http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html) thanks to Adrian Custer.

    Personally I want to ensure the first extensive REST API to come out of the OGC is actually a REST API (as it needs to serve as an example for later standards). I trust the voting OGC members (including ESRI) can do better on their next time at bat.

  3. is it even RESTful? by UnanimousCoward · · Score: 3, Informative

    In taking a quick look a the standard, it doesn't even look RESTful. For example:

    http://<mapservice-url>/layers

    Returns deep copies of all layers and tables as opposed to a list of IDs. Then:

    http://<featureservice-url>/<layerId>

    Returns a deep copy of a particular layer/table.

    How about http://<something>/layers returning a list of layers/tables and http://<something>/layers/{id} returning the particular table/layer? The whole /object and /object/{id} paradigm is missing. And that's just about GET. Regardless 800-lbs gorilla arguments against this "standard," I'd be more inclined to reject it due to its lack of adherence to standards.

    --
    Twelve-and-three-quarter inches. Unyielding. This wand belonged to Bellatrix Lestrange.
    1. Re:is it even RESTful? by WaffleMonster · · Score: 2

      In taking a quick look a the standard, it doesn't even look RESTful. For example:

      http:////layers

      Returns deep copies of all layers and tables as opposed to a list of IDs. Then:

      http:////

      Returns a deep copy of a particular layer/table.

      This encapsulates my hatred for "RESTful" APIs. In the real world the "everything is an object" hierarchy breaks down you often find yourself wanting to address shit that does not fall into a simple hierarchical scheme. This leads to ridiculous API specifications with no possibility of pratical horizontal reuse...which is the whole point of REST.

      The whole /object and /object/{id} paradigm is missing. And that's just about GET.

      The other classic reason REST fails is constraining verbs to the use of available HTTP verbs... No really WTF? This is wholly insufficient to address anything but non trivial 'CRUD' use and does not lend itself to any meaningful level of reuse as definitions are streched to encapsulate a handful of static verbs...so normally someone will just add a modifier to a URL to bypass the whole issue.

      And that's just about GET. Regardless 800-lbs gorilla arguments against this "standard," I'd be more inclined to

      Another problem with RESTful APIs is the reuse of HTTP status codes to convey operational status is misguided and dangerous. There are any number of middleboxes and even unrelated layers in the HTTP stack that can generate overlapping responses. Hey I got an XXX error from this web service so I will do y... but really that error was caused by something totally unrelated in the server stack while it was initializing.

      reject it due to its lack of adherence to standards.

      REST is an *IDEA* it is **NOT** a standard. When implemented using HTTP it ususally amounts to a shitty implementation of an otherwise reasonable idea.

  4. MSOOXML by Citizen+of+Earth · · Score: 3, Insightful

    ESRI would have gotten away with it if they had just taken the Microsoft path of stuffing the committees with Yes-men. I'm sure the OGC procedures would have been completely defenseless against this and the OGC management would have been overjoyed to collect $10k per temporary yes-man.

  5. Their API's are exactly what you would expect by ModernGeek · · Score: 2

    Trying to work with their API's is like trying to write something that has no documentation as all of their documentation reads like an MSDN tutorial. Most information has to be hunted down and tracked as if you're the first person ever working with their tools. They need standardization. Coming from someone that comes from Open Source and is working in their little walled garden, it says a lot when a large company like ESRI puts out junk compared to F/OSS. The only problem is that there are no F/OSS front-ends that allow for the creation of the maps themselves. Their mediocre tools for map creation are better than anything else out there, and that's what keeps them ahead.

    --
    Sig: I stole this sig.
    1. Re:Their API's are exactly what you would expect by westyvw · · Score: 2

      Yes, buggy. Slow, and often WRONG. Analysis using their product is sketchy at best. Better watch your data types, they play fast and loose with conversions in the internal code (INT to FLOAT for example).
      Worst part is that they sell you a viewer, then charge to edit, then charge more to analyze. Please, between PostGIS, Sextante, R, Geoserver, and QGIS I really cant see the point of using ESRI at all.

  6. Re:Lesson learned by Jaysyn · · Score: 2

    That may well be, but I much prefer using ESRI products over *any* of the following:

    MapInfo
    GRASS
    GE Smallworld
    Spatial.NET
    OptiLite / OptiNT
    Anything at all based on Microstation / Bentley.

    But what do I know, I've only had to use this crap in production environments since 1998. As for a monopoly, far, far more of my customers use MapInfo than ESRI or anything else on that list.

    --
    There is a war going on for your mind.
  7. Re:Lesson learned by TeXMaster · · Score: 3, Interesting

    Ok, serious questions here. Are there _technical_ reasons for hating GRASS? It does have a butt-ugly UI, but it's extremely flexible, extensible and it's designed with a Unix-like philosophy in mind, with a collection of tools that do individual things but are well integrated with each other. I'm not saying it's perfect, but then again neither is ArcGIS.

    --
    "I'm never quite so stupid as when I'm being smart" (Linus van Pelt)
  8. Re: Lesson learned by westyvw · · Score: 2

    Yes, but being a GIS expert means you can use projects, datums, etc. PostGIS has over 700 functions, and the database is more than simple features. Planer systems are not that complicated, you can do it without ESRI. ESRI uses GDAL and PROJ4 in their own systems, yet this is open to you.
    The difference is that most GIS folks dont understand that a update to a record is nothing more than just that. The spatial column isnt special, analysis is available through functions, and the output is available via a GUI (Qgis) or a Web presentation (geoserver).
    Its a situation where any data person can deal with this information, its not as specialized as ESRI wants you to believe.

  9. Re:Lesson learned by westyvw · · Score: 3, Insightful

    Thats because you don't need all of that. PostGIS --> Geoserver --> Web page. Need a GUI? Qgis. Analysis happens at the database level, just like any other query.

  10. Re:Lesson learned by Shinobi · · Score: 2

    From what I hear from some friends, the UI is not just ugly, but very clumsy to work with as well. In addition, just as with so many other FOSS tools for more specialized domains, with so much focus on "flexibility and extensibility", it pretty much means you have to spend significant amounts of time just to get the stuff you need to do work, and many firms doing GIS can't afford to hire some full-time programmers either.

  11. WFS/WMS by Stevecrox · · Score: 2

    Why are they developing their own REST service? Several years ago I was messing around with the GML* specified Web Mapping Service/Web Feature Service's and they worked brilliantly. Our demonstration setup had NASA's World Wind Java querying the server directly and a wrapper's were written for TENET** and ESRI. The WMS & WFS server was an open source GEOServer***.

    What does this give us that is new? WMS is great for tile retrieval and we were using WFS to supply all sorts of random mapping data. I would have thought those technologies would have matured quite nicely by now. I'm all for REST services but I can't really see the point.

    *I'm away XML handling is slow, but converting the format into JSON wouldn't be hard work.
    **Getting the WMS tiles to load quickly into TENET without locking the map UI was the hardest problem. ***May have gotten this name wrong.