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.'"

Comments

Lesson learned

[Anonymous Coward]

You have to be bigger and have more money to buy standards outright.

Roughly Microsoft sized to be exact.

Re:Lesson learned

[gandhi_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.

Re: Lesson learned

[Anonymous Coward]

There is no need for esri anymore, but they are busy marketing the hell out of keeping the myth alive. we have the database engines now for 90 percent of what they offer, only we don't call it guis we call it data and analysis. only the Esrilites stay commit red to the idea that the gis is special somehow (for most use cases).
  As for the rest the open source stack blows esri away on performance, cost (even with paid foss support), and tool sets. Esri is just a leach of the govrrnmeny, and a bully of spatial data types.

Re:Lesson learned

[mjwx]

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:Lesson learned

[Jaysyn]

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: Lesson learned

[plopez]

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:Lesson learned

[gandhi_2]

I really WANTED to like GRASS.

Re:Lesson learned

[TeXMaster]

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: Lesson learned

[westyvw]

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.

Re:Lesson learned

[westyvw]

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:Lesson learned

[Jaysyn]

Me too man, me too. Actually I plan on giving it another shake when I get some downtime.

Re:Lesson learned

[Shinobi]

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:Lesson learned

[smooth wombat]

Their products are complete shite but they hold a monopoly over the market.

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.

Re:Lesson learned

[NJRoadfan]

Microstation does GIS? Yikes. Based on what I have read, ERSI has a monopoly position in the US and many agencies outside of the US seem to use MapInfo. I don't know if they ever fixed it, but the web interface for ArcGIS used to be the worst web "application" ever written. It was slow, and never quite worked properly in anything but IE6... well when it actually worked. No wonder so many people rely on Google Maps API.

Re:Lesson learned

[Jaysyn]

Microstation does GIS? Yikes.

Bentley does industry specialized GIS over Microstation. Every one I've ever used has been a crap-fest..

Re:Lesson learned

[chuckinator]

Your list omits Quantum GIS (qgis). I've used it, and while it's not very enterprise-y, it seems to be better than the other FOSS offerings. Also appears to support connecting to a PostGIS system for layer info, but I haven't gone down that rabbit hole yet.

Re:Lesson learned

[Jaysyn]

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:Lesson learned

[chuckinator]

Didn't intend to come off with an accusatory tone in my earlier post, but there it is when I read it a second time. I like qgis, and it's much easier to fire it up to load some GeoTIFFs and DTED files for quick perusal. My primary complaint about GRASS is the obtuse process you have to go through simply to get a project started before you can actually, ya' know, view some geospatial data. There's some definite improvements that could be made (controlling layer rendering based on zoom level, OpenGL rendering, etc.), but it's pretty solid without having to dip my toes into the proprietary s/w markets for this use case.

Re:Lesson learned

[gandhi_2]

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 wife, a wildlife biologist with Arcview skills and a littel experience in R programming, trying to make heads or tails out of it. Each "feature" that someone might want in a GIS software suite, I ended up spending time trying to find it, download it, read the even worse documentation spread across unmaintained websites and dead links, then to find out many of them didn't work. I got the feeling that most modules were for some niche edge case that someone needed for a grad school project. At least I didn't have anyone telling to me to "roll my own then, noob"... so that was a plus.

Maybe it's gotten better since I tried it out? I really hope so.

Re:The problem with open source

[Anonymous Coward]

Even the trolls on slashdot suck nowadays. Come on man apply yourself!

If you're going to make a crude OSS troll you refer to it as "open sores". You could even parlay that in to your homophic slur by implying your play on words is an STD that homosexuals get, which would be brilliant because it draws further parallels with the "OSS software is viral" troll.

So much wasted potential. Sigh.

Here is Open Letter from the open source community

[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 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.

Re:Here is Open Letter from the open source commun

[Anonymous Coward]

Correction the letter is from the Open Source Geospatial Foundation (sigh).

is it even RESTful?

[UnanimousCoward]

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:is it even RESTful?

[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.

Re:is it even RESTful?

[Anonymous Coward]

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.

Feature services are not the same as map service layers. They are vector data layer child services of a map services consisting of multiple layers. Anyways you can return information about just one layer in the format you suggested see the example here-
http://server.arcgisonline.com/ArcGIS/rest/services/Demographics/USA_1990-2000_Population_Change/MapServer/1
Returns info about just that layer.

Re:is it even RESTful?

[WaffleMonster]

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.

Re:is it even RESTful?

[teebo]

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

Re:is it even RESTful?

[dkf]

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:is it even RESTful?

[Anonymous Coward]

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

No, it isn't remotely RESTful; then again, 99% of other self-proclaimed "RESTful" web services (and web developers) wouldn't know REST if it kicked them in the sack.

HTTP (the communication protocol) and REST (how that protocol is designed to be used) are appallingly misunderstood and misinterpreted, in large part because most developers today are only trained in object-oriented programming, which uses a fine-grained, low-latency, inherently reliable message passing interaction model. Whereas HTTP is a data-centric model specifically designed for coarse-grained interaction over an unreliable, high-latency network, where behaviors are triggered not by specific messages but by general state changes.

Needless to say, when OO programmers - a narrowly knowledgeable but broadly ignorant lot who hate stepping outside their personal comfort zone - encounter something as alien as HTTP's interaction model, their first reaction is not to understand it on its own terms but to bend and twist it until they can hammer it into their own OO-fixated mindset. Inevitably, the result is some sort of ad-hoc RPC-over-HTML with XML/JSON-serialized arguments/results, which they call 'REST' but isn't. And when all this fine-grained, low-latency, reliability-assuming message passing ends up sucking because it's being used over a massively distributed system for which such it is fundamentally unsuited, they blame 'REST' rather than themselves. Honestly, such developers should stick to SOAP; yes, it's crap, but at least it's vaguely consistent crap.

A basic rule-of-thumb test is to look at the user documentation: the public documentation for a RESTful app should only describe the data, not where that data is located or how to directly get to it. The only things it should describe is the root URL, all of the resource types found in the application, the various representations (content types) available for each type of resource and which of the standard HTTP verbs may be applied to each resource. OTOH, if it tells you how to munge your own URL strings, or has verbs or version numbers in the URLs, or uses the same content type for different types of resource representations, or any of the other REST anti-patterns, then it's almost certainly designed by someone who honestly thinks they grok REST but really groks donkey poop. If you want to see good REST documentation, go look at the Atom standard.

The whole /object and /object/{id} paradigm is missing.

That's one of the most common misconceptions amongst developers who've managed to make it past the http://domain/verb stage only to bog down immediately thereafter. A RESTful app could have all URLs of form http://example.org/UUID, and that would still be valid. The '/object/id' form is just something that usually shakes out on the design side as a convenient way for developers to map their resources, but clients must not form any assumptions from that - in REST, URLs should always be treated as atomic and opaque.

If you want to find a particular sub-resource, you start by GETting the root resource, then extracting a URL from the returned representation and GETting that URL, and so on until you arrive at the resource you want [1]. That way, if the application is updated later on, client code does not break simply because some resources have moved. The whole point of REST is to minimize coupling between server apps and client apps so that the former can safely grow and change without disrupting the latter. If the only client coupling is to the server's resources then the server is much more free to evolve than if the client is coupled to both the resources and their URLs. Especially since it is trivial to support interface versioning for resources (by offering multiple representations of the same resource), whereas there is no practical way to versio

Re:is it even RESTful?

[Anonymous Coward]

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

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, where behaviors are automatically triggered upon particular state changes instead of in response to explicit custom messages. That's the whole point of HTTP/REST: it's a state-centric, not message-centric, interaction model. The problem is that most OO-trained developers today can't think outside the message-passing box, so instead of using HTTP how it's meant to be used (i.e. RESTfully) they constantly fight against it, then blame it for 'sucking' when it's not the one at fault.

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.

This is extremely bad advice; as in Tower of Babel scale disaster, and anybody who invents their own 'HTTP' verbs deserves to have their fingers slammed in the nearest firewall. The whole point of having fully standard HTTP verbs is so that their behaviors can be fully standardized as well. This isn't just to limit the number of verbs that a user must learn but also to ensure that the same verbs act the same way across all web systems - not just individual client and server applications, but also everything inbetween: firewalls, caching servers, and other middleware.

This doesn't mean that other RESTful protocols can't define a different set of standard verbs to fit their specific requirements, but when it comes to HTTP you use GET, POST, PUT, and DELETE, and you use them the way HTTP/REST standards say they should be used. And assuming you're actually capable of thinking in terms of state machines and state transitions rather than local-message-bloody-passing all the time, it largely works very well. The explicit transfer of a state representation from client to server performs a state change on the server, which in turn can implicitly trigger whatever server-side behavior(s) you like. The basic principles are actually rather simple and easy to grok when you approach them on their own terms; it's the vast mouth-breathing ranks of OOPers that are pathologically incapable of adjusting to the different mindset who are making everything so hideously painful.

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

a.k.a. Ad-hoc RPC over HTTP with an XML/JSON-encoded payload. And y'know, if you just want something quick and dirty, and consistency, efficiency, fault-tolerance and long-term futureproofing aren't required, then this is probably what you should do. It's certainly infinitely better than inventing your own 'HTTP' verbs, as while it may suck in itself and fail to take advantage of the various benefits and protections that HTTP mechanisms provide, it doesn't go way out of its way to actively break them either.

Re:is it even RESTful?

[UnanimousCoward]

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 that there's another level that can be achieved.

Re:is it even RESTful?

[UnanimousCoward]

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:is it even RESTful?

[UnanimousCoward]

Yes, agreed. As per my other comments on comments, how about "best practices" instead of "standard?"

Re:is it even RESTful?

[WaffleMonster]

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 resource?

If I want to tell the server to perform a domain specific verb I should be able to do so. Telling me to shoehorn a custom transform into a bunch of CRUD operations for purely semantical reasons is what is nonsense.

where behaviors are automatically triggered upon particular state changes instead of in response to explicit custom messages. That's the whole point of HTTP/REST: it's a state-centric, not message-centric, interaction model.

Again this only works in the real world for trivial cases and turns to shit otherwise. HTTP is a simple as shit protocol for serving up web content. There are no usable concurrency, transaction semantics, no usable bulk operations or established contexts. It is way too simple for effective machine to machine communications. In otherwords it lacks the necessary infustructure to be used for anything but "message passing".

This is essentially the same SOA shit all over again. All great obvious ideas but using HTTP to implement them turns them to shit.

The problem is that most OO-trained developers today can't think outside the message-passing box, so instead of using HTTP how it's meant to
be used (i.e. RESTfully) they constantly fight against it, then blame it for 'sucking' when it's not the one at fault.

What does one win when they implement REST "properly" using HTTP? A clusterfuck of state machines? I'm tired of people playing semantical games or saying you should do this or do that without explaining why. The only justification for REST I have ever seen is horiztonal integration which sure as heck aint happening anywhere in any meaningful way.

MSOOXML

[Citizen of Earth]

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.

Re:MSOOXML

[Aighearach]

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:MSOOXML

[plopez]

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

[ModernGeek]

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.

Re:Their API's are exactly what you would expect

[Darktan]

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 Google always takes me to the version from three releases back.

Rather than standardization, I just want a way to take a map document and turn out cartocss, or mapnik styles.

Re:Their API's are exactly what you would expect

[kwbauer]

7000 what? days, nano-seconds, times?

Re:Their API's are exactly what you would expect

[phasmal]

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).

Re:Their API's are exactly what you would expect

[plopez]

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:Their API's are exactly what you would expect

[Anonymous Coward]

Radians, obviously.

Re:Their API's are exactly what you would expect

[smellotron]

7000 parsecs

Re:Their API's are exactly what you would expect

[westyvw]

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:Their API's are exactly what you would expect

[dkf]

Steradians. We're mapping in 3D, bitches!

Re:Their API's are exactly what you would expect

[NothingMore]

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).

Re:Their API's are exactly what you would expect

[hackula]

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!

Re:The problem with open source

[Anonymous Coward]

I know you are, but what am I?

Yet

[Anonymous Coward]

when said vendors happen to be Microsoft or Google the whole standards process goes out the window and they just buy their 'advantage'..

WFS/WMS

[Stevecrox]

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.