I don’t usually cross-pollinate between this, my personal blog, and the company blog over at Zekiah. One of the great things about working at a place like Zekiah, however, is the opportunity to work with smart people and see what they are doing. At times, my colleagues will share components of their work on the company blog. We encourage this, and the experimentation that leads to the posts, as a way to keep our technical capabilities fresh and to also showcase what we do in a way that goes beyond the typical capabilities statements that exist on every site. My colleagues have been pretty busy but have managed to take some time to write a few posts about their work:
When it’s really a desktop application.
Over the past few weeks, I have been reading with conflicted agreement the posts of Brian Timoney and Bill Morris about the nature of geo-portals and what they should or should not be and do. I say that I am in conflicted agreement not because I take any issue with anything they have said. Their posts represent what should be considered best practices in terms of building web mapping applications. In Brian’s posts, the counter-examples he highlights represent some of the worst practices to be avoided.
I find myself pointing people to GeoCommons for data more often these days. With over 50,000 data sets, there’s a lot there. The people I work with seem to usually be able to find data of value there so I’ve been putting a little time into making it easier to get data from GeoCommons. As I’ve mentioned before, many of them are long-standing ESRI users. While they are becoming more aware of alternate tools and data sources, it is still important for them to be able to get data into the ESRI environment where their custom tools reside.
Given the content of my recent posts, it’s no secret that my recent project work has involved the ESRI Silverlight API so I decided extend it to more easily access data from GeoCommons.
Recently, GeoIQ pubished an update to their RESTful API that includes a “Features API,” which gives you a little more direct access to the features in a GeoIQ data set (GeoIQ is the platform upon which GeoCommons is built). Previously, if I needed to access data from GeoCommons in the ESRI Silverlight API, I would just access it as KML using the native KmlLayer class. The GeoIQ Features API, however, offers more fine-grained control over how much data we return in the form of various query parameters. Currently, the API only returns JSON (GeoIQ’s own syntax or GeoJSON) so it was time to do something different.
Note: The application described in this post is running here. It requires Silverlight 4.
I was perusing my LinkedIn connections and noticed that quite a few had PMP certifications. I also noticed that most of those who did seemed to be in the Washington, DC area. Of course, given that I live in that region, my sample could be a bit skewed but then I started thinking out loud (via Twitter):
I would love to see a heat map showing concentrations of PMPs. I bet the DC area would be white-hot. I suspect others not so much.
Naturally, I could not let this sit. How hard could it be? It turns out it wasn’t that hard so I decided to throw a small app together to look at the data. In the process of working out an approach, I decided to also look at GISP certifications because the data set is smaller and is available as one download from the GISCI. Here’s a blow-by-blow:
In a previous post, I mentioned that I developed a MeasureString function for use in developing an annotation tool. In this post, I’ll go into a little bit more detail about that tool. For purposes of discussion, I extended the interactive graphics sample from the Esri Silverlight API interactive SDK.
For starters, I added another tool to the sample’s tool bar (circled in red below) to provide access to the annotation capability.
Things have been a bit hectic the last few weeks and that’s left little time for blogging. Quite a bit has happened so I thought I’d do a little round-up (if for no other reason than to clear my own head).
In no particular order:
Steve Coast to Microsoft (I told you it had been a while) – Firstly, congratulations to Steve (#sincerity). Secondly, this clearly is the final proof that crowd-sourced data in general, and OpenStreetMaps (sic) in particular, has no real value when compared to “authoritative” data sources (#sarcasm).
Google Fusion Tables – The only real problem at this point is the size limitation but, otherwise, this will be a game-changer for storing and sharing data. In its current form, it’s already fairly easy to push your data up and expose it through Google’s APIs. It’ll be interesting to see if it gets easier. Support for spatial queries hints at some analytical capability, too. Speaking of which…
Analytics in GeoCommons – This is one to watch. They are debuting a new function each day on their blog. FortiusOne builds their platform API-first, UI-second so everything they are showing should be exposed through their APIs. This will be a huge step in moving cloud-based geospatial technology from the “bit-bucket” stage to having a more complete workflow on the cloud infrastructure.
Despite recent news regarding Silverlight, I expect some of my projects to continue using it for the near term. Others may be taking the same tack, so I thought I’d go ahead and offer this up.
Several of the projects I support have the requirement to periodically refresh specific layers in order to track change or movement. These layers can range from weather to vehicle locations and such. I have typically accomplished this with a timer that refreshes the layer(s) on a specified interval. This can get rather cumbersome if you have different layers that require different refresh intervals.
Working within Silverlight, I have the option of using an existing layer class as a base class and extending it to include an automatic refresh capability. However, some classes, such as the ArcGISDynamicMapServiceLayer, are sealed and cannot be extended. Luckily, the Expression Blend SDK enables me to get around this by attaching a custom behavior.
I was working on an annotation tool for an application I am developing using the Esri Silverlight API. The TextSymbol class has properties to specify the X and Y offsets in order to position the text relative to the symbol’s base point. I needed to calculate the size of the string in order to determine the offset I wanted to use. Silverlight seems to have no intrinsic equivalent to the MeasureString function so I hacked this up.
Updated: This demo application now running here. I will update this demo periodically, as time permits, so keep checking back.
At the 2010 ESRI Federal User Conference, WeoGeo announced the availability of a toolbar for interacting with WeoGeo Market and private libraries from within ArcMap. This, combined with Dan Dye’s series of posts showing how to use the WeoGeo REST API with Python got me thinking about how easy it would be to integrate with ESRI’s clients for the ArcGIS Server REST API. All of my clients (it seems) are using the Silverlight API these days so I am spending a lot of time with it and decided to use it as my testbed.
My goal was simple, I wanted to browse the WeoGeo Market for any data sets in the current map extent, be able to select one from a list, and have its preview image display in the proper location on my Silverlight map.