Tag Archives: ArcDeveloper

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.

 


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.


2010 ESRI Developers Summit

So, I’m off to the ESRI Dev Summit next week to meet and learn from a legend (the official unit of measure of geonerds) of geonerds.  I will be giving a user presentation on using Cairngorm 3 to create testable applications with ArcGIS Server.  The presentation is all but done, and I’ll have links to the slides as well as the source I use for the demo app once the conference is over.  I am very interested in some of the other user presentations, which span the gamut of what can be done with ArcGIS and a bit of nerd elbow grease.  I’ll definitely be attending the Ruby/Rails based user presentations, as well as some of the other Flex and javascript-based presos.  Just like last year, I’ll not likely go to any Silverlight presentations, simply because we are not currently using Silverlight.

If you’re going to be in Palm Springs this year and want to have a pint or ten, hit me on twitter (@ruprictGeek).  For what I do, the ESRI Developers Summit is far-and-away the most relevant and important conference, so the more geonerds I can meet, the better.

Hope to see you there!


ArcDeveloper REST: Windsor Brings the Party That Rocks the Body

NOTE: Dave has blogged about the REST API, including a demo of it in action! Check it out!

In part III of my series on the ArcDeveloper REST API, I want to focus on how we use Windsor to configure the service. The best way to to that is to take a step back and look at why Windsor exists. Windsor is an Inversion of Control (IoC) container that provides a robust Dependency Injection (DI) framework. Both of those phrases have been blogged about by just about every human in existence, so if the Fowler link doesn’t help, then hit Google.

Background

In a nutshell, when you have classes that depend on other classes (and, really, what project doesn’t have that? Answer: Maintenance nightmare projects) a good pattern to follow is to supply the dependencies as opposed to instantiating them from within the class. The consummate example is:

public class ClassA{

  private ClassB _classB;

  public ClassA()

  {

    _classB=new ClassB();  //This is pure evil

  }

}

The above code violates so many design patterns and principles that I had to have my 7-year old actually type it (he is a TOTAL hacker) b/c I couldn’t bring myself to do it. A better way to do it is:

public class ClassA{

  private ClassB _classB;

  public ClassA(ClassB injectedClassB)

  {

    _classB=injectedClassB;  //This is sunshine and puppy dogs

  }

}

That code is an example of constructor injection, b/c the dependency must be provided to the constructor or the class cannot be instantiated. There is also setter injection, where public properties are exposed and the dependencies are suppled there. Both approaches have their pros and cons, and I am of the opinion that, if you are simply using DI in either form, you are WAY ahead of the game.

Before I leave the background, I would be remiss if I didn’t point you to the Bitter Coder’s Wiki, where the best tutorials on Windsor live and party.

Great, So How’d Does the ArcDeveloper Rest Stuff Use Windsor?

Well, the Windsor container can use an external configuration section, say, you the web.config file.

<configSections>

<section name=castle type=Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor/>

</configSections>

Once that is defined, you have three major configuration areas that you can play with: facilities, properties, and components (NOTE: You’ll find a separate .config file for each of these sections in the web project of our REST stuff.) Facilities are, basically, an extension to the Windsor container. There are many existing facilities, but the easiest to grok is probably the LoggingFacility. You register facilities on the container like so (from our facilities.config file):

<facilities>

<facility

id=logging

type=Castle.Facilities.Logging.LoggingFacility, Castle.Facilities.Logging

loggingApi=log4net

customLoggerFactory=Castle.Services.Logging.Log4netIntegration.Log4netLogger

/>

</facilities>

Here I have registered the Log4Net implemenation of the logging facility, which I could change to a different logging implementation by merely changing the “loggingApi” value (NOTE: I omit the logging.config that is required to configure Log4Net as it’s an, erm, implementation detail.) Once defined, any components registered on the container that have an ILogger public property will automagically get an instance of my Log4Net logger. That is just cool, man.
The rest of our time together will be spent working with components (we aren’t currently using properties right now, but they rock and the tutorials cover them well.) The ArcDeveloper REST API has services that provide the query functionality (like an ArcGIS Server provider) and formatters that take the results from the providers and transform them into the requested format. So, this means that we can register any provider and any formatter we might want to use with Windsor, and then all we have to do is tell the RESTServiceManager (our web service implementation class) about them. Here’s a picture (not quite 1000 words worth, but maybe a quick fin’s worth)

High Level Architecture of ArcDeveloper REST API

So, let’s quickly register the ArcGIS Service provider, which is implemented in the AGSMapService class.

<component id=ags.service lifestyle=pooled initialPoolSize=2 maxPoolSize=2

service=ArcDeveloper.REST.Core.Interfaces.IRESTService, ArcDeveloper.REST.Core

type=ArcDeveloper.REST.ArcGIS.AGSMapService, ArcDeveloper.REST.ArcGIS>

<parameters>

<name>TestService</name>

<description>Base map</description>

<connectionString>http://65.101.234.201/arcgis/services/gains/gains/MapServer</connectionString>

</parameters>

</component>

There you go. The AGSMapService class implements the IRESTService interface, and we provide the pertinent parameters. The “name” parameter (value=”TestService”) will be what is provided in the URI in order to specify that we want to use this service. The “connectionString” parameter is the URL of our ArcGIS Server Map Server object. Look closely at the attributes of the component, and you will see that we are pooling 2 instances of the service, which allows us to connect on first request and keep the object around for other requests. Since connecting to the server is a very expensive operation, we only have to live with it once. Windsor does this all for you! What do YOU do for Windsor? HMMM? That’s what I thought.

Anyway, lets show the formatter:

<component id=geojson.formatter lifestyle=transient

service=ArcDeveloper.REST.Core.Interfaces.IFormatter, ArcDeveloper.REST.Core

type=ArcDeveloper.REST.Core.Services.GeoJSONFormatter, ArcDeveloper.REST.Core>

<parameters>

<name>geoJSON</name>

</parameters>

</component>

So, our GeoJSONFormatter implements the IFormatter interface. We name this one “geoJSON” which, whenever we write a second formatter, will be how the URI will refer to it when requesting the GeoJSON format. Oh, and the lifestyle of this bad boy is “transient”, meaning it’s created on request and disposed after request. This is not an expensive item, so that’s how we roll.

Finally, let’s take a look at the RESTServiceManager:

<component id=rest.service lifestyle=singleton

service=ArcDeveloper.REST.Core.Interfaces.IRESTServiceManager, ArcDeveloper.REST.Core

type=ArcDeveloper.REST.Core.RESTServiceManager, ArcDeveloper.REST.Core>

<parameters>

<services>

<list>

<item>${ags.service}</item>

<!– <item>${other.service}</item>–>

</list>

</services>

<formatters>

<list>

<item>

${geojson.formatter}

</item>

</list>

</formatters>

</parameters>

</component>

You can see that our RESTServiceManager implements our IRESTServiceManager interface and we register our AGSMapService and GeoJSONFormatter with the service manager. The “services” and “formatters” properties of the service manager are lists, so we can add more services and more formatters simply by registering them on the container and adding them as an <item> to the list. Let me say it another way, just to drive the point home: If you wanted to register another ArcGIS Service map service with the RESTServiceManager, you would register with Windsor (so, copy the “ags.service”, give it a new id and change the <connectionString>) and then add an <item> to the <services> parameter with the component id (oh, you may have to restart your web app, as changes to the external config files do not kick off an app unload. If you don’t like it, pull all the config sections into web.config). After that, you can issue REST queries against the map service. It’s just that easy.

One final caveat. The IRESTServiceManager is not only our service manager, but it is also our WCF service contract. When you host a WCF service in IIS, it is created by the WCF Service Host factory, which means there is no way to register it with the Windsor container. That is bad, because if we can’t register the service manager, then we can register the services, and pretty much we have a web service that does bugger all. In order to get around this, the (man and legend) Ayende wrote a component that will allow you to register your WCF services with Windsor. The documentation for it is here, and is so eloquently written that I am stunned that I, er, I mean, the author didn’t get at least a Pulitzer nomination. The long and short of it is;

– Change the .svc file to use a custom ServiceFactory (from our rest.svc file)

<%@ ServiceHost Service="rest.service"
 Factory="Castle.Facilities.WcfIntegration.WindsorServiceHostFactory, Castle.Facilities.WcfIntegration" %> (GRRR....CopyAsHTML doesn't help me in .svc files)

– Instantiate the container at application start up, using the Global.Application_Start method (from our Global.asax.cs file)

protected void Application_Start(object sender, EventArgs e)

{

container = new WindsorContainer(new XmlInterpreter());

WindsorServiceHostFactory.RegisterContainer(container.Kernel);

_log = container[typeof(ILogger)] as ILogger;

_log.Info(“Services app started successfully.”);

}

That’s it. Now the WCF service will use the “rest.service” component we registered in the config file above.

So, this post got a bit wordy on me. I am young in my blogging ways, so I have trouble focusing. Also, I am easily distracted by shiny objects. In future posts, I plan to show how we leverage the Json.NET stuff for the GeoJSON formatter and maybe write a blog about something besides REST.


ArcDeveloper ArcGIS Server REST API is Breathing!

So, the angst around the ArcGIS Server Web ADF is well known and I shan’t rehash it here (OK, just a little rehashing: the ADF is a bloated sack of vomit) but, rather, I’ll point you to the beginnings of an open source ArcGIS Server REST API (svn) at ArcDeveloper.NET. The project is very young (and always looking for contributors) and, in it’s current state, has the following capabilities:

  • You can query single features by id (must be OBJECTID, ugh)
  • You can query features with a where clause
  • You can query features with a bbox (AND a where clause, if you want)

In this post, I will walk through what it takes to set it up and point it at one of your ArcGIS Server services.

What You’ll Need

Visual Studio 2008, implying .NET 3.5. You will have to build the solution, as we haven’t made an official release yet.

Optionally, I would have Fiddler, Firebug, and JSONViewer.

Step 1: Get the source

Using TortoiseSVN (or the svn client of your choosing), perform a checkout of the trunk (http://svn2.assembla.com/svn/arcdeveloper/ArcDeveloper.REST/trunk/)

Step 2: Open the solution

In the “Product” directory, you’ll find the VS2008 solution file. Like, open it or something. It consists of 5 projects, 2 of which are test projects. The other projects are the core interfaces and services, with the last one being a web project to show how to publish the REST service with WCF and a demo web page.

Step 3: Build the solution

Uh, in VS2008, select “Build Solution…”

Step 4: Use Dave’s Stuff

So Dave Bouwman, who I think is just the cat’s pajamas, has the demo site using an ArcGIS Server map service that he has been generous enough to provide. If you look in the ArcDeveloper.REST.Web project, you’ll find a config directory. Opening up the components.config file will show where the endpoint of the map services is specified. Looks alot like:

<component id=ags.service lifestyle=pooled initialPoolSize=2 maxPoolSize=2

service=ArcDeveloper.REST.Core.Interfaces.IRESTService, ArcDeveloper.REST.Core

type=ArcDeveloper.REST.ArcGIS.AGSMapService, ArcDeveloper.REST.ArcGIS>

<parameters>

<name>TestService</name>

<description>Base map</description>

<connectionString>http://65.101.234.201/arcgis/services/gains/gains/MapServer</connectionString>

</parameters>

</component>

Do you see the cool <connectionString> parameter? That’s Daves AGS service (I told you he was cool.) Run the site (it uses the VS Dev server now) and click “Load Polygon”. You’ll see a small polygon drawn over Yemen (erm, at least I think that is Yemen). Change the ID and draw some more.

ArcDeveloper REST API Demo Page

Here’s what is happening:

A HTTP GET is issued to the local web service with a URI that looks alot like:

 http://localhost:xxxx/rest.svc/TestService/Flyways/10?g=true

Let’s break down the URI, shall we? Starting with rest.svc, that is the WCF endpoint for the REST service. “TestService” points to our configuration (from above) file and tells the service which map we want to use. “Flyways” is the name of a layer in Dave’s service. “10” is the id of the feature we want, and “g=true” tells the service to return the geometry (there are cases where you don’t want that, b/c it can make the size of the response baloon pretty quickly.) So, that is pretty RESTy, yes?

The response from that HTTP GET looks like:

{  "type": "Feature","geometry": {"type": "Polygon",

"coordinates": [

[

[ 44.3231, 14.2555], [43.2827,13.6294],[ 43.285, 13.6503],        (...lots more coords...)     ]

},

"properties": {

"Ssp": "maculosus",

"Species": "Burhinus capensis",

"Shape_Length": "4.59630121045653",

"TSN": "0",

"extent": "42.9447173339071,13.6294196034485,44.3230947030963,15.0950604545328",

"SpeciesCod": "BURCA",

"WISDOM_SpeciesID": "557",

"OBJECTID": "10",

"Code": " ",

"Shape.area": "1.28930099595786"

}

}

Which is valid GeoJson. Neat, eh?

I know what you are saying. “Glenn, why would I use this when ArcGIS Server 9.3 will have a REST API?? HMMM?” Well, that is a great question. The only answer I have is that you can use this now, contribute to it, and make the world a better place. Also, you can learn about a lot of stuff, like REST, WCF, GeoJSON, AJAX, the Castle Project stuff, and much, much more. Plus, there are some real brains on this project (I am not one of them) so you can sop up their wisdom as well. Also, I heard a nasty rumor that the AGS REST API wasn’t using GeoJSON, but a proprietary spatial JSON format, which is a bit disconcerting, if not totally expected.

In future posts I’ll break down the ArcDeveloper REST API architecture, showing how you can write your own providers and formatters. We still have a TON of work to do on it, but we’re on our way.