Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by Anonymous Coward

    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 te

  • is it even RESTful? (Score:4, Informative)

    by UnanimousCoward (9841) on Monday June 03, 2013 @08:31PM (#43901119) Homepage Journal

    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.

    • by Anonymous Coward

      I don't think (not an expert, however, it is my day job) but a collection can be returned with deeply nested resources as well according to REST. Sometimes it will even be the best option rather than making hundreds|thousands of individual requests. Other times it will not be the best choice, but REST doesn't actually say one way or the other about it.

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

      http:/// [http]/layers

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

      http:/// [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 bu

      • by dkf (304284)

        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.

        Just define your own HTTP verbs and use those as well. As long as you support the standard OPTIONS request, it should all be "REST" enough.

        Or just pack everything over POST and party like it's SOAP once again!

      • So I agree with just about everything you are saying here. I shouldn't have used the term "standard"--how about "best practices?" If ESRI or some other organization wants to put out a "RESTful API," then I think that it should adhere to some "best practices" which, IMHO includes the paradigm that I put forth (and is well-implemented in various web platforms).

        Again, I agree with your stipulation that it is an IDEA or a CONCEPT (I've read the seminal thesis). But with respect to implementation, I think tha

    • by teebo (43281)

      It's even worse than that.

      http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

      http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

  • MSOOXML (Score:4, Insightful)

    by Citizen of Earth (569446) on Monday June 03, 2013 @08:59PM (#43901227)
    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.
    • by Aighearach (97333)

      MS was a special danger because they had so much money and were slinging FUD before people were broadly educated on the power, and possibility, of standards and interoperability. ESRI is just a niche player with good market share, (30%) and the community backlash happened because people know to value open standards, and they know they are possible. The horse is out of the barn on that one.

      Maybe they're the 800 ounce gorilla in their small niche, but 30% is no monopoly; even without anybody else close.

    • by plopez (54068)

      They would have gotten away with it if it hadn't been for those meddling kids.

  • 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.
    • by Darktan (817653)

      I find the truth is almost the opposite. The REST API is pretty good, at least compared to anything the OGC has put out. While ESRI's tools are okay for authoring maps, their server software is some of the worst crap I've ever had to work with. It's slow, and buggy. And slow. Map tile generation takes 7000 longer than on open source software, on the same hardware.

      While technically all their stuff is documented, they have a nasty habit of creating a new documentation portal for every major release. And Googl

      • by kwbauer (1677400)

        7000 what? days, nano-seconds, times?

      • by westyvw (653833)

        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.

    • by phasmal (783681)
      Couldn't you write something in Javascript to bridge it to OpenLayers? (OK given the caveat that I failed to do this in under a few hours recently because I couldn't work out what projection the geometry was in).
    • by plopez (54068)

      True, it is a nightmare. But so is GIS, map projections, coordinate systems, and they fact they are lugging around legacy concepts from the '80s, by which I mean the 1780s, which must be accommodated. State plane? Township-Range anyone[1]? The unsymmetrical nature of planet Earth? Decimal degrees vs DMS? All have to be accommodated. The real world is much messier than can be mapped to a happy little app.

      [1] Invented by Thomas Jefferson.

    • No kidding. They have the absolute WORST API documentation of any product i have ever used. Its slightly better now (in Arc 9 good luck finding documentation to do anything non-standard). However this problem does extend beyond ESRI since it seems like documentation in this entire software sector is pretty shitty (OGC is better but not great).
      • by hackula (2596247)
        Of course, due to the fact that they leave all of their 9.x docs in place, they come up at the top of a web search, so you might be on 9.x docs anyway!
  • by Stevecrox (962208) on Tuesday June 04, 2013 @07:56AM (#43903317) Journal
    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.

Put no trust in cryptic comments.

Working...