Lessons from Maps and Old Code

Taking over someone else’s code is hard. There is probably no better look at how a person thinks than looking at their code. It can be tempting to trash their code and start from scratch. This temptation often runs into conflict with a sunk-cost fallacy that says “The previous person spent so much time on this that they had to understand the problem far better than me and maybe my time would be best spent learning from their code.” The really tough part about this is that it’s not always a fallacy.

My own encounter with this dilemma came early in my career – early enough that the code in question was written in AML. The company I worked for at the time had just transferred me to the offices of a large water utility to take over the development of their cartographic production system from a developer who had recently moved on. I had never met this developer and he was already gone, so I only had his code to work from.

Read more

Working with the GeoIQ Features API

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.

Read more