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.'"
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.
THL phish sticks
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.