Category Archives: ArcDeveloper

Using RobotLegs to Create a Widget for the ArcGIS Viewer for Flex

I submitted two talks to last week’s ESRI Developers Summit, one of which was not selected.  This made me indignant enough to write a blog post explaining the shunned presentation, in the hopes that all the people that did not vote for it will slap their foreheads and pray for the invention of time travel.  Or, maybe I just want to dialog on using Robotlegs with the Flex Viewer.

In the Advanced Flex presentation that Bjorn and Mansour gave at DevSummit, he extolled the use of frameworks.  Paraphrasing, he said “Find a framework and stick with it”  By “framework”, he meant something like PureMVC, Cairngorm (3, mind you, not 2), or Robotlegs.  I agree with the sentiment, wholly, although I am also a bit baffled at why the Flex Viewer didn’t use one.  My guess is that they will claim they have their own framework, which is certainly true, but it flies in the face of what Mansour spoke of in his presentation.  I raised my hand to ask this question, but (thankfully) time ran out on the questions and I was not selected.  It is probably just as well, as I don’t want to get on Mansour’s or Bjorn’s bad side.  They’ve both been very helpful to me in the past and I doubt I am even close to beyond needing more of their knowledge.

So, in this blog post, I am going to create a Flex Viewer Widget with Robotlegs.  First, though, I’ll explain a couple of things.  The reason I like using Robotlegs (or any well-supported framework) is myriad. It makes my widget much more testable, meaning, I can more easily write unit tests to exercise the widget.  This allows me to design the widget in a test-driven fashion, which is a good thing.  I wonder why the Flex Viewer source doesn’t include any unit tests.  Again, it’s not like ESRI is promoting bad habits, but they aren’t promoting good ones either.  Also, Robotlegs is known outside the ArcGIS world, so future Flex developers on my project that know Robotlegs will be able to get productive more quickly.  Granted, they’ll still have to learn about the ArcGIS API for Flex as well as the widget-based approach taken by the Flex Viewer, but the patterns Robotlegs uses brings context to this learning.  That’s my story, and I am sticking to it.

So, why Robotlegs?  Because I like it.  It’s got a great community and it makes a ton of sense.  Read on to see what I mean.

OK, let’s get to the code.

The Scenario

The widget we are building today is a Geolocation Widget.  (final product here) It’s function is to figure out where the user is and store that location in application, allowing the user to zoom to their location.  It will rely on javascript to do the IP Location search (which we won’t get into too much.  Suffice it to say that we’re using the HTML 5 Geolocation API for this with a fallback)

Now, I don’t really want this post to be an intro to Robotlegs.  There are plenty of those, including a very recent one by Joel Hooks (an RL founding member and crazy-smart guy) Read through those posts (as of this post, there are 3, with more on the way)  It should get you enough background to understand what is going on here.  Go ahead, I’ll wait.

Back? Confused? Robotlegs takes a bit to comprehend (not even sure if I totally get it, ahem) So, here are the things you’ll need to go through this in your own Flex development environment:

  • The ArcGIS API for Flex (I am using 2.2)
  • Robotlegs (using 1.4 here)
  • FlexUnit ( and related swcs
  • AsMock (1.0) with the FlexUnit integration swc
  • Robotlegs Modular Utilities (github) Stray  (who is brilliant) and Mr. Hooks have written a modular utility for RL, and since our Flex Viewer is modular, we are using it.

For simplicity, just grab the git repository here, which has all this stuff set up for you.  Don’t get too hung up on the number of libraries and third party code.  This is how separation of concerns looks, leveraging the best library for a specific function.

The ‘Main’ Context

For those of you that did go read the Robotlegs introductory articles, you know that we have Contexts, Views, Mediators, Commands, and Services.  The context is the first thing we need to sort out, and there is a couple of caveats to our particular situation.  First, the Flex Viewer is not a RL application and, therefore, it does not have a context.  However, we need one, even using the Modular Utility.  In a nutshell, the Application Context is there as a parent context, and will supply the injector to the module contexts (unless you create one explicitly).  So, first thing to do is create the main context:

import com.esri.viewer.BaseWidget;
import flash.display.DisplayObjectContainer;
import flash.system.ApplicationDomain;
import org.robotlegs.core.IInjector;
import org.robotlegs.utilities.modular.mvcs.ModuleContext;
public class ApplicationContext extends ModuleContext {
	public override function startup():void {

In the main application context, we register the BaseWidget class, which will allow Robotlegs to inject any widget going forward.  This makes using Robotlegs a bit more involved than just sticking with the “core” Flex Viewer widget approach, but it’s a small price to pay, in my opinion.

The View

Since functionality drives the widget, next is the view.  In this scenario. we want the geolocation to be loaded when the widget is first opened.  Once it is found, the location should be displayed and the user can pan to that location as desired.  In my mind’s eye, I see a couple of labels and a button.  Also, we have 3 states: Searching for location, location found, and location not found.  I see this:

We have a feedback area, the location is displayed, and the user can pan whenever they like with the “Go there!” button. Not gonna win any awards, but it gets the job done. From looking at our UI, there are a couple of takeaways: First, the location is loaded automatically, which means it happens when the user opens the widget. Second, we can start to think about our states and what is visible for each state. Finally, something has to handle user pressing that button. In RL, it’s the job of the Mediator to handle view events, so this is what ours looks like:

public class GeolocationWidgetMediator extends ModuleMediator
  public var location:IGeolocation;
  public var widget:GeolocationWidget;
  override public function onRegister():void{
    eventMap.mapListener(widget.btnGoThere, MouseEvent.CLICK, handleGoThere);
    //Could also use this, but then you have to figure out the target.
    //this.addViewListener(MouseEvent.CLICK, handleGoThere);
    this.addContextListener(GeolocationEvent.LOCATION_FOUND, handleLocationFound);
    widget.currentState = GeolocationWidget.STATE_SEARCHING_FOR_LOCATION;
  private function handleGoThere(event:MouseEvent):void{ 
    var point:MapPoint = com.esri.ags.utils.WebMercatorUtil.geographicToWebMercator(new MapPoint(location.x,location.y)) as MapPoint;;
  private function getLocation():void{
    //Find yourself
    dispatch(new GeolocationEvent(GeolocationEvent.GET_LOCATION));

When the Mediator is registered, we map the button click event to handleGoThere(), which simply zooms to our location. But wait, where did that location come from?

The Model

The location object is our Model and is of type IGeolocation (I used an interface for the model here, and now I kinda wish I hadn’t…oh well) We know it needs x/y coordinates, so we’ll make a model object that fulfills our requirement:

public class Geolocation implements IGeolocation
  private var _x:Number;
  private var _y:Number;
  public function get x():Number{
    return _x;
  public function get y():Number{
    return _y;
  public function Geolocation(x:Number=0.00,y:Number=0.00)
    _x = x;
    _y = y;

There, now we have a model that is injected into our mediator. The model is a singleton (not a Singleton, it’s managed by RL) so that anything that cares about changes to the model can just have it injected and they’re always up to date. MMMM….that feels good. When we look at our module context, you’ll see how to make the model a singleton (we do it with services too!) For now, we’re still talking about the mediator. The getLocation() method fires off a GeolocationEvent, which we need to ‘splain.


The Mediator takes view/framework events and translates them into Business Events. In this case, the loading of the widget is translated into a go-get-our-geolocation event, which we call GeolocationEvent.GET_LOCATION.

public class GeolocationEvent extends Event
  public static const LOCATION_FOUND:String = "locationFound";
  public static const LOCATION_NOT_FOUND:String = "locationNotFound";
  public static const GET_LOCATION:String = "getGeolocation";
  public var location:IGeolocation;
  public function GeolocationEvent(type:String)
  override public function clone():Event{
    return new GeolocationEvent(type);

Nothing special about events in RL, which is GOOD. Our GeolocationEvent has a payload of our location model, and it handles a few event types. We know when getGeolocation happens, the other two events are in response to finding out geolocation. We’ll talk a bit about those when we get to the service. For now, something has to respond to our GeolocationEvent.GET_LOCATION


In RL, you handle business events with Commands. Commands are responsible for answering the question raised by the event, either by going outside the application (when they talk to services) or by some other means. In our case, we’ll make a GeolocationCommand that calls some service to get our geolocation.

public class GetGeolocationCommand extends Command
  public var service:IGeolocationService;

  public var event:GeolocationEvent;
  override public function execute():void{

About the simplest command you can possibly have. Also, note how RL is helping us flush out our needs while guiding us in using best practices. What have you done for RL lately? Yet it still guides you on the path of rightgeousness. Let’s discuss that IGeolocationService.


The ‘S’ in MVCS. Services are our gateway to what lies beyond. When we need to go outside the app for data, we ask a service to do that. In this case, our service is going to ask the HTML5 Geolocation API for our current location. This means, basically, that we call out using ExternalInterface and define a couple of callbacks so we can handle whatever the service returns.

public class GeolocationService extends Actor implements IGeolocationService
  public function GeolocationService()
  public function getGeolocation():void
  public function handleLocationFound(x:Number, y:Number):void{
    var location:Geolocation = new Geolocation(x,y);
    var event:GeolocationEvent = new GeolocationEvent(GeolocationEvent.LOCATION_FOUND);
    event.location = location;
  public function handleLocationNotFound():void{
    var event:GeolocationEvent = new GeolocationEvent(GeolocationEvent.LOCATION_NOT_FOUND);

Notice that our service extends the Actor class, which is an RL class that (basically) gives us access to EventDispatcher. The service will fire events (as you see above) when it gets back results from the beyond.

Something has to handle the events thrown by the service. We want these results to show up in our view, which means, we want these results to change our model. Back to the Mediator.

The Circle of RL

Back in the GelocationWidgetMediator, we can subscribe to the events raised by the service. As a side note, you really have a couple of options here. If your data is more complex than an x/y pair, you’ll likely want to parse it before it gets to the mediator. At this point, I would recommend you look at Joel’s posts and, for something super cool and useful, the Robotlegs Oil extensions. I will likely blog about Oil in the future. You could also create a presentaion model, inject it into the view and data bind to the model objects on the PM. I am doing it the simplest way because my scenario is simple. Anyway, back to the mediator and handling the events raised by the service. You subscribe to context events in the same onRegister() function that you subscribe to view events.

override public function onRegister():void{
  eventMap.mapListener(widget.btnGoThere, MouseEvent.CLICK, handleGoThere);
  //Could also use this, but then you have to figure out the target.
  //this.addViewListener(MouseEvent.CLICK, handleGoThere);
  this.addContextListener(GeolocationEvent.LOCATION_FOUND, handleLocationFound);
  this.addContextListener(GeolocationEvent.LOCATION_NOT_FOUND, handleLocationNotFound);

  widget.currentState = GeolocationWidget.STATE_SEARCHING_FOR_LOCATION;

public function handleLocationNotFound(event:GeolocationEvent):void{
  widget.currentState = GeolocationWidget.STATE_LOCATION_NOT_FOUND;

We saw handleLocationFound() above, here I added the handling of the not found scenario. All it does is set the state to the “not found” state, which hides buttons/labels/whatever.

The Context

As I mentioned earlier, the module needs its own module context. The context’s job is to wire everyting up. Our mediator is mapped to its view, events to commands, and the services our registered. Also, the items that will be injected to the various players (like the model and the service) are specified.

public class GeolocationWidgetContext extends ModuleContext
  public function GeolocationWidgetContext(contextView:DisplayObjectContainer, injector:IInjector){
    super(contextView, true, injector, ApplicationDomain.currentDomain);

  override public function startup():void{
    injector.mapSingletonOf(IGeolocationService, GeolocationService);
    mediatorMap.mapView(GeolocationWidget, GeolocationWidgetMediator);

    commandMap.mapEvent(GeolocationEvent.GET_LOCATION, GetGeolocationCommand,GeolocationEvent);
    commandMap.mapEvent(GeolocationEvent.LOCATION_FOUND, FindPolygonCommand, GeolocationEvent);

Our context extends ModuleContext, which is supplied by the Robotlegs Modular Utilities. The ModuleContext creates a ModuleEventDispathcher and ModuleCommandMap, and is basically (as Joel states here) just a convenience mechanism. Since we are in a module, there is one last little item we have to do to make this all come together. Our module should (read: needs to) implement the org.robotlegs.utilities.modular.core.IModule interface. This defines two functions (a setter for parentInjector and a dispose() method) that ensures the API to initialize the module and RL is in place. So, in the script of the MXML, you have:

public function set parentInjector(value:IInjector):void{
  context = new GeolocationWidgetContext(this,value);
//Cleanup the context
public function	dispose():void{

The set parentInjector allows us to create a child injector as well as use mappings from the main context. Read Joel’s post on Modular stuff for more detail. The dispose() function is just good practice, allowing you to free up anything you need to free up. The mapSingletonOf calls are how you tell RL to just make one of these things. Above the Geolocation model object is made a singleton, so the mediator and the command get the same copy. In a more complex widget, you could data bind to that bad boy and anything that changes it shows up in the view without any code. That…howyousay?…rocks!

That really covers the meat of creating a Flex Widget for the ArcGIS Viewer for Flex using Robotlegs. As I mentioned, this was submitted to the Flex-a-Widget challenge at the Developers Summit and did not place. The winners (which, to be honest, I voted for) did things display Street View and Bing 3D and windows into your friggin’ soul in the Flex Viewer, so you can see why this simple-to-the-point-of-being-useless widget did not place. Still the guts of this widget are pretty sexy, and now hopefully you can build your own soul-displaying widgets using Robotlegs.

The code on github has a few items that I didn’t think pertinent to this blog, like unit tests (which are VERY important and a BIG reason why using something like RL is crucial) Also, the source has another sequence of taking the point and finding the county where the user is currently, just for fun. I hope you found this useful. If I messed anything up or got something wrong, please let me know in the comments. Much of the reason I do blog posts like this one is to confirm that things are what I think the are. I have (frequently) been wrong before, so correct me if you see an error.


ESRI DevSummit 2011: Daz(zl)ed and Confused

As I am flying back to Charlotte from another ESRI DevSummit, my head is awash in a storm of possibility, hope, and worry.  This conference is head-and-shoulders above any other conference on my radar in relevance and utility to my career.  Every year I leave amazed at how far ESRI has come with it’s product suite, particularly on the server-side, and every year I feel overwhelmed at what I don’t know and what I am not doing.  The ESRI developer community has exploded from a collection of people that couldn’t install Tomcat to a sophisticated, intelligent set of technical ninjas.  Watching this change from my perspective has been interesting and extremely humbling, as sometimes I feel like I am a part of something great, and sometimes I feel like I am falling behind.  All things considered, though, it is a great time to be a GIS and ESRI developer.

Reviewing the content of the conference, as i am prone to do each year, I would have to say the overarching theme was mobile, mobile, and more mobile.  Of course, I live on the server, so I didn’t give and desktop sessions a second glance.  I focused mostly on the Flex and Javascript APIs, as I simply don’t have room in my arsenal for another web API (sorry Silverlight.  I will say that the demo of the week was probably the Kinect map demo given by @SharpGIS.)  The Flex sessions are always great, especially if Mansour Raad is presenting.  His energy and knowledge truly make him unique among presenters.  He showed off Flex “Burrito”, which is the code name for the preview release of the next Flex IDE.  Burrito allows a developer to target Blackberry, Android, and (wait for it…) iPhone devices with Flex.  Mansour showed off a few apps running on Android and iOS, which is crazy if you think where Flash on the iPhone was only a year ago.  The maturation of the REST API lead to demonstrations of more sophisticated editing scenarios on the web, making me wonder if the future of ArcMap isn’t the Flex Viewer (or other API “viewers”)  The javascript team showed similar demos, focusing on iOS (both iPad and iPhone) with HTML 5 goodness.  I really though the drag-and-drop demonstration, which showed a CSV of points being dropped on a web page and added to the map, as well as dropping a map service URL onto the map to add it to the map content, was particularly impressive.  There is a part of me that really thinks HTML 5 is the end game for the web, even if Flex can still do some things that HTML cannot.

One of the items that Mansour and the Flex team showed was a pre-release version of the Flex Viewer Application Builder.  The Builder allows a user to, basically, point and click their way to a Flex Viewer, choosing basemaps, operational layers, and tools/widgets.  The goal is to allow them to avoid having to edit XML and all the pain that comes with doing that.  Being honest, I am not all that excited about such a tool.  Also, I am not sure that showing a “no-need-for-a-developer” tool at a developers summit is really playing well to the demographic.  My guess is that Silverlight and javascript will follow suit, and we’ll have many clients feeling they can cut out development shops and live with what ESRI has created.  Expanding on this theme a bit, the very existence of a *supported* viewer from the vendor could be problematic as well.  In my opinion, this can potentially kill innovation around the web APIs.  Why, as a client trying to save money, would I choose to create  a custom web mapping application, when the vendor has a viewer that is supported?  The answer is, in most cases, I wouldn’t.  So, as ESRI developers, we will be mostly relegated to viewer configuration or, if we are lucky, custom widget creation.  Plus, the client base of the APIs becomes 99% ESRI supported viewer and 1% demos that no one would really use.  I talked to a few developers about this and opinions varied from what I expressed above to “nah, it’ll be OK, there will always be enough GIS development work”  I am not sure what the answer is, as I understand why ESRI created the viewers.  They are doing what they feel is best for their clients.  I can’t really fault them for that.  However, I think every year ESRI eats a little bit more into the realm of their business partners, and the effect of that will be seen with ESRI partners having to move to other business or failing outright.

There, enough with the gloom-and-doom.  The mood around the conference was overwhelmingly positive, if not sycophantic.  Coming back, my fellow devs and I are discussing how we are going to get more mobile, more cloudy, and more better.  Despite my aforementioned worries, I am recharged as in previous years.  If you didn’t attend the conference, you should watch some of the sessions.  Almost all the ones I attended were excellent.  This includes the user presentations, which I’ll review now.

Starting at the bottom of the user presentation barrel, my talk on using jQuery to create a legend for the ArcGIS Server javascript API was OK.  I made some pretty bad slide choices (code on a black background is not the way to go) and I had a couple of clumsy holy-crap-he-just-hit-the-microphone-and-blew-out-my-eardrums moments.  On the positive side, a couple of folks came up afterwards and talked to me about using what I’d done, which is always reassuring.  On the super-fantastic-presentation end of the users, you had the usual suspects for the most part.  The DTS Agile crew (@dbouwman and @bnoyle) gave near perfect presentations on HTML 5, the cloud, and Flex pixel bending.  Kirk van Gork (@kvangork) may have stole the show with his presentation on making apps that “Don’t Suck”, which I did not attend but will be watching this week, for sure.  Another really great presentation was on using MongoDB to create a Feature Cache.  This presentation was done by a (for gawd’s sake) 21-yr old Brazilian developer who informed us he had never presented before.  I was thoroughly impressed with this poised and intelligent young man, and you should definitely give that presentation a look.

Well, the plane has started the initial descent into Charlotte.  I am ready to be home and thankful for another wonderful DevSummit.  If you have any questions about sessions or the like, feel free to hit me on Twitter or comment on this post.  Go forth and spread the Word of the GeoNerd.

2011 ESRI Dev Summit: Prologue

Yay!  One of my presentations was selected for the User Presentation track at ESRI Developers Summit.  It is called “You are Legend” and it shows how I created a jQuery plugin that creates an interactive TOC/Legend combination for your jsapi map.  I am kind of surprised it was chosen, since it didn’t seem like I was getting many votes and the whole TOC/Legend concept is, in many people’s mind, a big usability no-no.  I really did it because most of my clients want one and I like jQuery and I like javscript and I had to do something for the ESRI Charlotte Developers Meetup.  The DevSummit version of the presentation will be, I am hoping, much enhanced and a bit more polished, if for no other reason than I won’t likely be 3 beers into the night before the talk (the Charlotte meetup was in a pub).

Last year I thought the user presentations were really, really good.  If you want to network with other developers, attend as many of these as you can and then ask questions after the talk.  I know that I appreciated the questions after my talk last year and, as a result, have added Twitter contacts with which I can now discuss ongoing development issues.  Also, if you’re headed to DevSummit, let me know (comment here or @ruprictGeek on the twittersphere) and maybe we can plan a couple of pub-based nerd sessions.  Here are some of (what I consider) other interesting sessions:

I am not sure if all of these made the cut, but they do look interesting.  I didn’t put any Python or Silverlight presos on my list, simply because I don’t use that stuff much, but if that is your cup-o-tea there are a lot of offerings.  Another thing that surprised me was that my Robotlegs presentation did not get selected.  Out of the two I entered, I thought that one would get the votes.  Basically, I was going to walk through using Robotlegs to create a Flex Viewer widget.  The ArcGIS Flex Viewer is nice, but I don’t like that they rolled their own framework.  There are so many well-supported and, frankly, superior frameworks out there (Robotlegs, Swiz, PureMVC, Cairngorm3) that would have allowed ArcGIS Flex devs to leverage those communities.  I am trying to enter a widget in the Flex-a-widget challenge that uses Robotlegs, so we’ll see if I can get that done.

Try to get to DevSummit if you are able.  If you are a ArcGIS Developer, this is by far the best conference of the year.


ArcGIS Server Legend Resource Application

Building on my last post, I wanted to create a RESTful app that serves up legends from ArcGIS Server.  Ideally, this app would not need any configuration.  I thought this was very doable, since I could just put the URL information for the map service into the URL for the legend resource service by my new RESTful app.  All in all, this was much easier than even I predicted.  Oh, and I have to thank Colin Casey (again) for refactoring my code to look more Ruby-way like.

At first, I thought of using a Rails app for this, which I did stand up and get running.  However, it seemed like way too much for just a simple app.  There is no database, no real views, and not much that required all the conventions that Rails uses.  I have been hearing tons about Sinatra (including a running joke that it’s where experienced Rails developers eventually land) and how lightweight it is.  And, it is VERY lightweight.  I am not going to post any examples of Sinatra here, but a rudimentary scan of the Sinatra home page is enough to show that it’s not a lot of weight.  So, I selected Sinatra and had the app working in a  few hours (most of which were me struggling with my RubyNoob issues)  The result is legend_resource and is posted on github for your criticism and mockery.

Using LegendResource

It’s very easy to get legend_resource up and running.

  1. Pull down the code (git clone
  2. Install Bundler, if it isn’t already (gem install bundler –pre)
  3. You might have to install RMagick, if you have not already.  As I alluded to in my last post, you should go the the RMagick site and figure out the best way to install it for your operating system.  (#copout)
  4. type ‘bundle install’ from the git repo root.   This should install all the necessary gems.
  5. type ‘rackup’. This should fire up the application on port 9292.

Now that the app is up and running, you can generate a legend for any map service.  For example, if you want a legend for the USA_Percent_Male map service in the Demographics folder on, click on this link:


Or create an HTML page with an img tag and set that link to the src.  Like this,

Neat, eh?

That’s it.  Neat, huh?

The URL scheme is pretty simple:  http://<webserver>/legend/<mapserver>/<mapservicepath>, where

  • webserver is whereever the legend_resource app is currently hosted.
  • mapserver is your ArcGIS server
  • mapservicepath is the path to the service on mapserver.  This works for services in the root or in a folder.  The link above was in a folder, for example.

Config Options

The configuration options for legend_resource are few right now.  Out-of-the-github, I want it to just work, and it does.   It writes the files to the local file system if you don’t tell it otherwise.  Right now, the only other option is a Google Storage for Developers backend that exists because I received my invite to it this morning.  If you want to use that, you have to:

1) Change the gstore.yaml file to add your access_key and secret.

2) Comment out the line in that sets up the GStoreLegend as the file handler.

run LegendResource
# Uncomment this line to use Google Storage (don't forget to change the gstore.yml file)')
#LegendResource.set :filehandler, GStoreLegend

I did that for a Heroku app that I am hosting at (the image above is from said Heroku app) that you are free to use to crank out a few legends.  Just bear in mind that the map service will have to be exposed to the web for my Heroku app to see it.

I hope someone else finds this useful.  It was a ton of fun to make and I learned a lot about ruby in the process.  I realize that my code is pretty noobish from the Ruby standpoint, so feel free to fork the repo, refactor, and issue pull requests.  That’s how I learn.  Also, if you’d like to see other options for the legends, hit me on github or leave a comment.

Happy Legending!

UPDATE:  One thing I don’t think I made clear is that the REST interface for this service only handles GET and DELETE.  If you HTTP GET to the url, it will either create or return the legend.  If you HTTP DELETE to it, it deletes the legend, so, the next GET will create it anew.

Create Legend Images from ArcGIS Server with Ruby

Recently, I needed to create a legend for an ArcGIS Server map service, and was amazed that it was still a non-trivial activity. Googling it, I saw a few posts with (what I considered to be) WAY too complicated C# code for such a simple task. Also, there is no great way to get a legend out of ArcMap (for gawd’s sake) which left me thinking “Surely, there is an easy way to do this.” (expletives removed)

I have been mucking about (again) with ruby and Rails, which is great and depressing all at the same time. I don’t use much ruby in my 9-to-5, as it’s neck-deep in Microsoft, so I try to shoehorn ruby into my work however I can. In this case, I remembered the venerable Dave Bouwman’s Ruby-Fu presentation at DevSummit (That guy is always doing the stuff I want to be doing. I don’t like him.) and that he had found a ruby library that spoke both REST and SOAP to ArcGIS Server. Being an experienced AGS dev-monkey, I also know that you can get legend and symbology information from the SOAP API. Thusly, a not-terribly-original-or-visionary idea was born: Use ruby to create a legend.

My main requirement is that it easy, something on the order of:

  1. Tell the thing the URL of my map service.
  2. Tell the thing I want a legend for the map service.
  3. Save the legend given to me by the thing to a file.

So, I got my shoehorn out and when in search of ArcGIS-flavored ruby bits.


I hunted down the slides for Dave’s preso to find the name of the ruby library he mentioned. It is arcserver.rb (github) written by Colin Casey, an extremely patient and approachable developer. I sent him a message with my Grand Legend Plan, and he say “Do it, man.” arcserver.rb already did #1 and #2 from my list above. All I had to do was #3.  Once you’ve installed the arcserver.rb gem (so, type ‘gem install arcserver.rb’ at your command prompt and watch it install all kinds of stuff….WEEE!)  (run this in irb):

require 'rubygems'
require 'arcserver'
server ="")

That gives you a text representation of all the legend information for the service. So, all I had to do was loop through all the symbology and write out the symbols. Easy, right? Well, in ruby evertyhing is easy (no fanboy bias there at all). I needed an image processor, and the Old Man of Ruby Image Processors is RMagick. Now, bear in mind that I did all of this on a Windows box, but I used Cygwin. You can install RMagick 2 on Windows natively, so I hear/read, but I didn’t do it that way. However you do it, you’re gonna need RMagick, and therefore, ImageMagick. (um, everything in ruby is easy *cough*)

Got RMagick installed?? Awesome! Wasn’t that easy? Are you giving me the finger? Let’s continue. One of my goals in contributing to Colin’s project was to not pollute it too much. Being pretty much a ruby novice, I figured the best thing to do was to keep as much of my code in its own class/file, so Colin could easily remove/rewrite/laugh-and-point-at it how he saw fit. The final (cleaned and reorganized by Colin) version consists of a LegendImage class that you can see here on Github (I don’t want to post a ton of code here, it’s just unwieldy) I am not going to walk through the code, but I’d like to point out that it’s <70 lines and very readable. For a first run, I was very happy. If people use it or I find the need, the next step would be to handle options (dpi, width, height, layers to exclude, etc.) but, for now, this works. Also, I’ve heard that 10.1 is going to fix this legend issue and make it easy to create them, so putting a ton of work into this prove to be fruitless.

Now, to create a legend image, do the same thing we did above, but add (if you’ve installed RMagick since you started irb, you need to restart it):

require 'RMagick'

which will write a PNG file called “legend.png” in the from which directory you fired up ‘irb’. Kick ass. Three lines of code (less if you chain) to get a (very basic, but usable) legend from ArcGIS Server. Here is the legend it creates using the Diversity service from ArcGISOnline.

Legend for Diversity Map Service

I thought that was pretty cool and useful. There may be other, more elegant ways out there to get a legend from an ArcGIS Server map service, and I am sure someone will mention them in the comments. Even so, I enjoyed doing this little exercise and I appreciate Colin letting me contribute to his project. Here are all the irb commands needed once you have the prerequisites and the gem installed:

require 'rubygems'
require 'RMagick'
require 'arcserver'
server ="")

My next task is to use this library in a Rails-based web mapping application. Hopefully, I’ll get to that in the next week or so.

Enhanced by Zemanta

Unit Testing Objects Dependent on ArcGIS Server Javascript API

Recently, I’ve created a custom Dojo dijit that contains a esri.Map from the ArcGIS Server Javascript API.  The dijit, right now, creates the map on the fly, so it calls new esri.Map(…) and map.addLayer(new esri.layers.ArcGISTiledMapServiceLayer(url)), for example.  This can cause heartburn when trying to unit test the operations that my custom dijit is performing.  I am going to run through the current (somewhat hackish) way I am performing unit tests without having to create a full blown HTML representation of the dijit.

I’ll be using JSpec for this example, so you may want to swing over to that site and brush up on the syntax, which is pretty easy to grok, especially if you’ve done any BDD/spec type unit testing before.

The contrived, but relatively common, scenario for this post is:

  1. My custom dijit makes a call to the server to get information about some feature.
  2. The service returns JSON with the extent of the object in question.
  3. I want my map control to go to that extent.

Following the Arrange-Act-Assert pattern for our unit tests, the vast majority of the work here will be in the Arrange part.  I don’t want to pull in the entire AGS Javascript API for my unit tests.  It’s big and heavy and I am not testing it so I don’t want it.    Also, I don’t want to invoke the call to the server in this test.  Again, it’s not really what I am testing, and it slows the tests down.  I want to test that, if my operation gets the right JSON, it sets the extent on the map properly.

The Whole Test

Here is the whole JSpec file:

describe 'VersionDiff'

   vd = new esi.dijits.VersionDiff();
 describe 'updateImages()'
   it 'should change the extent of the child map'
           var obj={};
           return obj;
     vd.childMap = new esri.Map();
     var text = fixture("getFeatureVersionGraphics.txt")
     text = dojo.fromJson(text)
     //Assert 7660976.8567093275 7661002.6869258471 704520.0600393787 704553.8080708608


The Arrange portion of the test stubs out the methods that will be called in the esri namespace.  Since the goal of the test is to make sure my djiit changes the extent of the map, all I need to do is stub out the setExtent method on the Map.  setExtent takes an Extent object as an argument, so I create that in my local, tiny esri namespace.  Now I can set the property on my dijit  using my stubbed out map.  Thanks to closures global variables (ahem), the esri namespace I just created will be available inside my function under test.  Closures are sexy, and I only know enough about them to be dangerous.  Yay!  I don’t have to suck in all the API code for this little test.  That fixture function is provided by JSpec, and basically pulls in a text file that has the JSON I want to use for my test.  I created the fixture my saving the output of a call to my service, so now I don’t have to invoke the service inside the unit test.


This is the easy part.   Call the function under test, passing in our fixture.


How do I know the extent was changed?  When I created my tiny esri namespace, my esri.geometry.Extent() function returns an object that has the same xmin/ymin/xmax/ymax properties of an esri.geometry.Extent object.  The setExtent() function on the map stores this object in an extent property.  All I have to do is make sure the extent values match what was in my fixture.

I didn’t include the source to the operation being tested, because I don’t think it adds much to the point.  Suffice it to say that it calls setExtent() on the childMap property.

So What?

I realize this may not be the greatest or cleanest approach, but it is serving my needs nicely.  I am sure in my next refactor of the unit tests that I’ll find a new approach that makes me hate myself for this blog post.  As always, leave a comment if you have any insight or opinion.  Oh, and regardless of this test, you should really look into JSpec for javascript unit testing.  What I show here is barely the tip of what it offers.

Reblog this post [with Zemanta]

2010 ESRI Dev Summit Wrap Up

Back in Charlotte after another lively ESRI Developers Summit.  I went back and read my impressions from last year, and have to say that they were hit and miss.  You could replace last year’s impressions mentioning 9.4, with some mentioning 10 (the new and improved 9.4) and it would at least partially apply.  New stuff this year to get your inner (and outer) GIS nerd in a frenzy are:

  • Editing from the web.  The new FeatureLayer in the REST (and, thus, the various web) API is the big deal.  Simple editing of GIS data from the web.  In my oft-hyperbolic opinion, this is a game changer.
  • Attachements support in the REST API.  I have mixed feelings about this, as it seems that ESRI might be trying to make the geodatabase the everything-base, but I guess attachments are just another kind of data.  I can see cases where we’d use this, but I plan to be very careful…
  • Scriptable REST admin (my sessions were almost all either REST or Flex or both), which could be very useful.
  • REST-enabled Server Object Extensions (SOE) look very promising as well.
  • The Flex API has AMF support at 10.  Truthfully, I’ve not done much with AMF in Flex, but I understand it’s superdy-duperdy fast.  That’s on the immediate todo list.
  • Also on the Flex side, although not ESRI specific, is the release of Flex 4.  I went to a couple of sessions where they demoed Flash Catalyst, Flash Builder, and the new workflow.  I finally understand what Catalyst is, which is a good thing.  Depending on it’s cost, we may or may not use it.
  • Various small bits, like point clustering being supported by the GraphicsLayer, complete with a cool “flare-out” symbol.

This year was the second where users were allowed to present.  I presented on Cairngorm 3 and best practices in Flex.  I thought the presentation when as well as I could have hoped.  The slidedeck and code are available, and you can find all that information here.  The app I used basically allows the user to draw a polygon around NFL stadiums in the US and then click on the selected stadiums to see a pop-up with an aerial view of that stadium.  Cairngorm 3 and Parsley made it very easy to create the app, and the amount of code I had to write is shockingly little.

I will say I was surprised at the number of Flex vs Silverlight developers this year.  Last year, I wrote about Silverlight being the Queen of the Ball, with most developers I knew going to all SL sessions.  The buzz was much bigger about SL then, which was a 180 turn-around this year.  All of the Flex sessions seemed to be packed, and the buzz was Flex-heavy.  I didn’t actually go to any SL sessions, but I heard more than one developer say that the sessions seemed less full than last year.  Maybe it’s an alternating year thing or something.  Or maybe the release of Flex 4 on the Monday of the summit had something to do with it.  If you are a Sliverlight developer, please bear in mind that I don’t really care if Flex or SL has more “buzz” or attendees, but I just find the dynamic between the two camps and their respective APIs mildly interesting.

For more info, you can go to ESRI’s Dev Summit site and watch plenary videos as well as all tech sessions.    The user sessions aren’t posted yet, but they’re coming.  If I think about it, I’ll post a link to mine when it comes online.  Oh, and if you checkout the Twitter #devsummit tag, you’ll see a mountain of info and links for your perusing pleasure.

It was a great conference, as always.  Already looking forward to next year.