GIS Community Blocks Esri's Geospatial 'Open Standard' REST API 53
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.'"
Re: (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.
Re: (Score:2)
Mapping and GIS much much more than GUIs and simple databases. There are a huge number of coordinate systems, projection types, mapping analysis functions, etc. out there. ESRI is a pain, I hate it at times, and suffers from too little real competition, but it also a huge suite of data visualization, manipulation, and analysis tools that will be with us for a long period of time. Replacing SQL Server and Oracle with Postgres is just one small step.
Re: (Score:3)
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
Re: (Score:2)
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.
ESRI is the Microsoft of the GIS world. Their products are complete shite but they hold a monopoly over the market.
The way ESRI controls the GIS world would be how Microsoft would control the desktop and server OS world if it weren't for the anti-trust actions taken against them by the US DOJ and EU.
Re: (Score:3)
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.
Re: (Score:1)
I really WANTED to like GRASS.
Re:Lesson learned (Score:4, 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.
Re: (Score:3)
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.
Re: (Score:1)
That is a VERY fair question.
I'm accustomed to clunky GUIs in FOSS. I like the "each tool does one thing well" unix philosophy.
But walking into GRASS thinking you will be getting some GIS work done.... will be a mistake. I mean, a Photoshop power-ish user can pick up Gimp and usually get the job done after the figure out none of the tools, windows, hotkeys, or features work the same or as well. But you can figure it out.
I found the documentation to be less helpful that I'd have hoped. I tried to picture my
Re: (Score:2)
Me too man, me too. Actually I plan on giving it another shake when I get some downtime.
Re:Lesson learned (Score:4, 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.
Re: (Score:2)
Re: (Score:2)
Microstation does GIS? Yikes.
Bentley does industry specialized GIS over Microstation. Every one I've ever used has been a crap-fest..
Re: (Score:1)
Re: (Score:2)
Your list omits Quantum GIS (qgis).
That would be because it's a list of GIS software I've actually heard of & used before. That being said, I just got it installed because a previous post mentioned it as well.
Re: (Score:1)
Re: (Score:2)
I'm glad you said that because having had the misfortune to deal with their software, it must only be because they're the big guy that they survive.
Their install procedures have essentially no documentation, their install process may or may not work and, as per usual shitty programming, most of their software requires users to be admins on their machines to work correctly.
Shit and monopoly seem to go hand in hand.
Here is Open Letter from the open source community (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 te
is it even RESTful? (Score:4, 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.
Re: (Score:1)
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.
Re: (Score:2)
Yes, agreed. As per my other comments on comments, how about "best practices" instead of "standard?"
Re: (Score:2)
Yes, I realized the difference after taking a longer-than-quick look :-)
However, I still think there should be some notion of /object/{id} for GET. As per some of the other comments, I agree that what I'm talking about isn't a standard. I think it's more of a best practices implementation thing.
Re: (Score:3)
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
Re: (Score:2)
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!
Re: (Score:2)
This is nonsense. It's true that HTTP 1.1 is a bit resource starved (PATCH, and arguably MOVE and COPY, should be included as well), but you can express a huge range of behaviors using just the standard GET/POST/PUT/DELETE verbs as long as you design your application as a state machine,
This is where academia and reality depart. Design your own state machine? Seriously? No thanks I'll pass. This is a great way to unecessarily increase implementation complexity and maximize round trip delay.
If I want to project a layer of dataset in a different datum what do you suggest I do? GET it, project it myself and PUT the result into a new resource on the server? Or better still COPY and then "PATCH" it? Not going to happen. What if I want my transform to be a view and not a separate resourc
Re: (Score:2)
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
Re: (Score:1)
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)
Re: (Score:2)
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.
Re: (Score:2)
They would have gotten away with it if it hadn't been for those meddling kids.
Their API's are exactly what you would expect (Score:3)
Re: (Score:1)
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
Re: (Score:1)
7000 what? days, nano-seconds, times?
Re: (Score:2)
Steradians [wikipedia.org]. We're mapping in 3D, bitches!
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:1)
Re: (Score:2)
WFS/WMS (Score:3)
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.