At State of the Map today in Amsterdam I announced that we were open-sourcing our geocoder. You can get the LGPL-licensed code on GitHub and also check out my lightning talk presentation announcement on Slideshare.

The geocoder was built as part of our FGDC CAP Grant to help GeoEnable Government Tabular Data and utilizes the free and open TIGER/Line street data as well as various address parsing and metaphone components for US level address parsing. Also, not everyone can call to a web-service, abide by the terms of service, or be limited by the speed and amount of geocoding queries.

The reason we’re open-sourcing it because primarily an open-source geocoder has been a sorely missing piece of the open-source geospatial stack. You have storage, analysis, rendering, geolocation, and even routing – but not geocoding, at least not in an active project way. GeoCoder::US has been around for a long-time and well built, in Perl, and despite it’s long-standing solid service at geocoder.us, it didn’t fit our needs.

So instead we worked closely with Schuyler Erle, one of the original developers of GeoCoder::US, to rebuild it in a modular way (in fact he finished it once and promptly rebuilt it again), and also in a popular, modern language, Ruby(that we happen to use as well).

We’re also hoping to engage the community in building out the Geocoder. Right now it has components for the United States – but we hope that others will add components for their countries. OpenStreetMap is coming along very well with adding both ranged, and even parcel level, address data. So a good first task would be to build out an OpenStreetMap data importer.

Feel free to check out the code on GitHub – fork it, let us know what you’re working on, any issues you run into, and how we can make the best, and open-source, geocoder out there. Look forward to more detailed posts on how we built it and how we’re using it in GeoCommons and GeoIQ.

This weekend, Tim Waters (chippy) noticed that the WhiteHouse is using OpenLayers mapping library and OpenStreetMap basemap tiles in their new Delivering on Change page.

Whether you were already serving your country, or are responding to the President’s call, share how you are delivering on change in your community.Whether it is an hour per month helping those struggling in the current economy, tutoring kids in your neighborhood every day, or anything else, we want to highlight what Americans are doing to strengthen our country.

This is very interesting on several levels. Foremost is the use of government provided (TIGER/Line) and crowd-sourced data (OpenStreetMap) in an official US Government Site. This is definitely an indicator that what were cutting edge tools have reached a critical mass to provide broad usability and appeal. Open Source? check

Looking underneath the hood, the data is provided via a KML feed (), so you can pull the data out and upload or map it however you want. Open Data? check

The site itself, Delivering on Change, is asking citizens to contribute stories and media about their personal engagement with change. This is an incredibly exciting step to ask for people to contribute to national storytelling and character. Citizen-sourced data? check

The new US administration is continually doing amazing, and open, initiatives. There is incredible excitement around Recovery.gov as a testbed for the next generation of transparency and embrace of technology and open data feeds.

Small next steps

My thoughts on interesting applications wouldn’t be complete without pointing out a couple of suggestions. While many defend the default OpenLayers controls – I personally think that implementors should take that next step and apply minor customization to better integrate the look and feel of the map controls into their site. I’ve talked before about how easy it is to change some CSS to replace the controls. Perhaps even just a darker blue background to match the White House blue in the logo. Customized?

Another, less highlighted but very important for Government sites is the integration of accessibility controls. OpenLayers supports map navigation using keyboard inputs – which provides for alternative interfaces to navigate the map. It’s not clear if this is official “508 compliant”, but at least demonstrates the potential. Accessible?

How you can help

So do you want to help make Change, especially with mapping data and technology? Come join us at the Washington, DC mapping party – currently planned for June 20 + 21, 2009 somewhere in DC (details coming soon). Or join a mapping party near you.

Through my help with VoteReport.in I have been diving much more into supporting and deploying the Ushahidi platform as part the front-end for user contributed reports. Ushahidi itself started out as a quick mashup a year ago and since then has blossomed into a much fuller platform that is being utilized in dozens of initiatives and projects.

Each of these projects evolves the platform, adding new customization capabilities, more input types, browser support, and more. These modifications may be happening in rapid succession without the main Ushahidi development team even being aware of these changes. And the system may even be running in a remote area with little connectivity.

Traditionally, this has meant that a deployment would download a copy of the current release version, or maybe a development snapshot if there was some emminent new feature that was very useful, and then go off, make modifications – probably on a live server, and maybe email these changes back way after the event in hopes that some of the changes are accepted back into the platform. Updates to the main code base wouldn’t be easily applied to these heavily modified derivatives – so essentially every deploy is a fork of the code.

How Git can save the day

Fortunately, Ushahidi chose Git as the code repository server, although the installation instructions still suggest that you download the code. Git is meant to support just this kind of distributed workflow and collaboration.

If you’re not familiar with Git, I highly recommend checking out Git Internals. But to summarize, it is a versioning control system that is fast, efficient, has local indexes (stored in a local .git directory) and can reference any number of remote indexes to share commits, branches, and files. Where in traditional systems there is an ‘official’ host repository – in Git all repositories are equal and can quickly connect and syncronize.

What this means in a system like Usahidi is that any deployment would first just get a local clone of the official Ushahidi repository to their local system and setup and get running. If they make changes to this code they can just do a commit into their local index. In order to share this code with other developers on this same deployment they could just provide them with the Git link to this repository, or make a branch and add a deployment specific “remote” index that multiple developers could all push into.

Along the way as new code is released in the Ushahidi repository, these deployments could merge in these changes to their local branches without losing their local modifications. And conversely, local modifications could be merged and pushed back into the Ushahidi master index very easily.

Moving sideways

Now lets think about some really powerful uses of the Git architecture. Since the entire index is stored locally in a .git folder – it is easy to put an Ushahidi deploy on a USB stick or archived folder, send it around, make modifications in the field and continue to commit these changes to a local repository even while offline. Then when connectivity is restored, or the USB stick can be brought back to a networked computer, the modifications that had been made, and tracked, could be pushed back to a deployment or Ushahidi instance.

And with arbitrary remote indexes – individual deployments could share code and modifications between themselves without having to go through an Ushahidi instance. Local networks around an incident, culture, language, or feature set could easily collaborate and iterate the code. Imagine if in Gaza, the Al Jazeera instance could have shared code to other local organizations running similar systems.

I think there are even more potential applications of Git to distributed architectures that would be useful for document and database sharing that occur in fast paced situations. However, Git itself will have to work on some of the usability and interface design issues that make it a difficult tool for novice users.

One of the more interesting presentations and discussions at BarCamp.mil was the Department of Defense CIO thoughts on a future publicized guidance on the use and promotion of open-source software for defense contracts.

Open-source in the DoD isn’t new. In fact, there have been government reports that call for the DoD to issue an official strategy for utilizing open-source. The issue is particularly unclear in recent light of the US Government being declared a sovereign entity outside of copyright law.

The objective of the prospective official guidance would be to outline both the benefits of using open-source in defense as well as provide understanding on the effects to contractors and bids. It is vital that contracts are clear on the legal implications and responsibilities of providers.

So far, this has meant that solution providers are not necessarily willing to wade through the uncharted waters and instead deliver proprietary software. In addition, there was no impetus to use open-source, since by shipping proprietary software the effect is to lock-in the provider for decades.

In addition, there needs to be a defined mechanism for how accepted open-source software that comes inside various government offices, especially defense and intelligence organizations, be re-released to the community. Currently I’ve seen a number of open-source projects taken into agencies and essentially forked since the code will never be able to be released due to concerns of potential security leaks in the code itself.

In the open-source world, a government supported promotion of its use would have dramatic effects. Looking at the current state of commercial company support for projects such as Apache, Linux, Gnome, OSGeo and more demonstrate that there is clear benefit to be gained. If the government then pushes open-source there would a huge upsurge in the support of projects and communities.

Here’s to hoping the lobbyist groups don’t head this off before it makes it to the light of day.

Imity – the bluetooth proximity location service that showed up at Where2.0 last year and has been teasing me with their cool software has just open-sourced their code! (via O’Reilly Radar)

As of today, our phone client is open source. New features, bug corrections, builds for new phones, it’s all open for your mad Java skills (or whatever you feel like porting to).

So yes, it’s in Java. Last time I tried to get a J2ME toolchain built on Mac or Windows it was 3 days of frustration before I gave up. Perhaps their service API is simple and could be done in Py60 or Mobile Processing.

If you haven’t heard of Imity before, the concept is that while geolocating you in the world is neat and all, what really matters is who is near you. It doesn’t matter so much that you’re at a conference center, what matters is that there are dozen people around you, some of you whom have met already, or will meet again. Imity tracks these proximity locations of other users, connects you when certain ones are nearby.

Really, geolocation is a good mix of the two. Sometimes it is just about me, where I am, and what there is to do there. And other times it’s about connecting me with people – and perhaps we go off to do some of the fun things in the area.

Imity also did some very cool stuff by prototyping their concept and code in Second Life, the virtual reality world. It was a great demonstration of using Second Life as a rapid prototyping environment (no need to build into real handsets and find other users in the world), and also did a good job at marketing.

Check out the Google code page for the software.