So I’ve been playing with Leaflet a lot lately. It’s become my lightweight mapping library of choice. There’s a lot it doesn’t do so I keep OpenLayers and others in the rotation as well but Leaflet is direct and to the point so I use it when I can.
A while back, I stumbled onto the Leaflet.markercluster project on GitHub, which adds a clustering layer type. I wanted to try it so I revisited my old GISP heat map demo (Silverlight) and decided to rework it. I was happy to finally get a chance to strip out the plug-in, anyway.
A few weeks ago, I posted about some .Net wrappers I created for the GeoIQ API. Due to ongoing project work, I have continued to extend them by adding methods to wrap GeoIQ analytical capabilities. Despite the recent acquistion of GeoIQ by Esri, it’s my understanding that GeoCommons and existing GeoIQ installations will continue for some time. That’s good, because analytics on the GeoIQ platform are powerful and fairly easy to use. This post will demonstrate how to use analytics in a .Net application.
As previously posted, the .Net wrappers can be found on github here.
The GeoIQ platform offers several functions to analyze data sets hosted on a GeoIQ instance or GeoCommons. I have not yet wrapped all of the functions but am working my way through them as I can.
The original intent was to wrap the entire API but it turns out that we were undertaking this in the middle of GeoIQ’s upgrade to version 2.0. In the intervening time, we got some projects implementing the GeoIQ platform for end users (such as the Climascope portal that Andrew Turner recently blogged about).
In my previous post, I described how I used a Python script to scrape power outage information from a local web site and convert it into an RSS feed. In this post, I’ll show how I used GeoCommons to visualize the changing information over time.
The process starts by creating a data set in GeoCommmons based on a URL link to the feed created in the previous post. The general process for doing that can be found here in the GeoCommons documentation.
In the aftermath of Hurricane Irene, I was trying to get information from my local electric cooperative about outages. There were many (including my neighborhood) and I wanted to see the scale of the problem. It turns out, they have a page with a map that shows current outages by zip code.
It’s pretty old-school as far as web maps go but it gets the job done. Their day job is making electricity, not web maps, so I won’t critique it too much. One thing I did notice is that the map seems to be dynamically generated (as do the tables on the page) from some inaccessible data source. I search and tried to find some kind of feed, to no avail.
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.
I read Learon Dalby’s latest GISuser.com expert column (disclosure: I am a contributor there also) with great interest since it addresses an issue with which I have worked closely over the years: availability of GIS data in a time of crisis. Over the years, the proliferation of “operating pictures” (you’re not in style unless you have your own UDOP) and other systems has obscured the fact that the data is really what matters. Certain segments of the community, especially those more focused on man-made disasters rather than the natural variety, have gotten very good at putting multiple layers of technology, services, security, policy, etc. between GIS data and the people who need it.
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: