Toot toot – beep beep

I am going to write a little post to toot my own horn and discuss some of the REST ideas people, especially Sean , have brought up. About 2 years ago I started experimenting with REST shortly after starting at ESRI. It was prompted mostly by blog posts by John Udell and the advent of GreaseMonkey. You can see my original post here (we gotta use the Wayback Machine because I no longer host my own blog). Some of the links still work but the A9 OpenSeach no longer works because I don’t have a Tomcat instance running outside a firewall. If you go to the full Wayback archive for my blog that includes that date, please scan down to “feeling a bit slow on the uptake” and the post right on top. I think the whole Google removing their SOAP api is an example of providers seeing the problem of people seeing your data without getting their eyeballs to your property. And that whole recombination thing is the point of Yahoo! pipes, which is why I thought it was so great when it came out.

What I had done internally at the time was write a greasemonkey script that scraped an Amazon book page for an ISBN number. The script then did a REST request to a controlling servelet on my server, which then made a REST request to an Amazon Web service for a list of resellers, then from that list requested addresses for each reseller, then took the cities and states for each reseller. Now I wrote a servelet in front of an ArcGIS Server geocoding service and another in front of a mapping service. The geocoding servelet would take a comma seperated url of cities and states and return a XML document with X and Y locations. The mapping servelet would take a comma seperated list of X and Ys in the URL and return an URL of a map of the U.S. with the dots for each reseller’s location. For the last stage this URL would be returned to the greasemonkey script that would then insert that url into an IMG tag and render the map on the page.

I can not tell you how much fun it was working on that project. The hardest part was getting the Greasemonkey script to reliably scrape the ISBN number from the page and then insert the image in the right location. I showed this around a bit, but it only worked inside the ESRI firewall (oh to have an external facing server like they do now). Working on that got me thinking about loosely coupling with HTTP requests and XML (JSON was still in it’s infancy then and I felt very comfortable tooling around with XML). Of course the code was erased when I did one of my many clean sweeps to reinstall development builds – so you will just have to take my word for it (or not).

So the ideas have been there, I just think like with most technology, GIS people are usually not on the leading edge. They need the idea to bake into other services with other examples and then build on top of that. Which I think supports the idea that GIS and mapping are usually part of a larger question, and it is only once you can get the other data in the larger question, can you then bring GIS to bear.

I am glad ESRI is thinking about putting a REST API in front of server but it is also not that hard to build one yourself. I mean we already have the SOAP API so why not wrap that in some XML parsing, web programming goodness and make your own API. One of the the beauties of REST is that it is all urls and xml (or json) and there are so many fewer interop problems than you can get with web services. But a drawback is how to establish a contract as to what the URL should look like and what I am going to send back in response. A SOAP web services gives up flexibility and ease of use for more certainty in the contract of send and receive. Both SOAP and REST have their place, it just depends on what you want to do.

It should be interesting to see if ESRI groks what REST is about or if we end up with an all roads leads to ArcObjects api.

Quick rant on joins in ArcMap

Working with some tabular data and some point feature classes in ArcMap. I want to do a one point feature to many row join but I could also settle for a definition query where I would end up with 1 feature to 1 row

Step 1 – export the Query to a table in my personal geodb and then try to join on the appropriate fields – join works (after I follow all the rules) but it doesn’t respect the Definition query I put on the table…grrrr

Step 2 – go to the support find and that this is a known issue

Step 3 – go talk to some of the GIS analysts and they reccomend a relate rather than a join. Trouble is you can’t symbolize by a relate, it just looks like it is intended for editing.

Right now I am looking at generating 1 DBF or table per definition query I would have used above and then joining. This stinks… Does anyone have better suggestions to this issue.