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.

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.

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.

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.

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.

Tags: imity, geolocation, proximity, opensource, clausdahl, mobile,

He mentions the “Here be Dragons” experience of people really wanting to go out there and find the unmapped places. This is how OSM really got off the ground in the first place, as most of the world was “Dragon-land” and everyone’s individual contribution made a huge difference, at least in the UK/Europe.

Data as good and bad

The US still doesn’t have great OSM representation. One response I’ve heard from the OSM crowd is, “the US already has TIGER/Line data, so there’s less impetus for people to go out and contribute new data”. There were very few “unknown areas”, so people found less benefit to put effort into adding those few places. Now, with Yahoo’s imagery & an applet to automatically generate roads, will there be the same effect in the UK/Europe? Nearly overnight the amount of mapped areas with dramatically increase with little to no effort by the actual mappers. While their efforts made OSM what it is, and therefore made it possible and useful for Yahoo to give the imagery, I wonder if they’ll now feel they’ve partly “lost their voice”?

Will looking at the next generation OSM map and seeing 90% coverage make the developers/gatherers more apathetic about setting up mapping parties? What happens when you go from the underdog to the superdog? Google is dealing fairly well with it – they spend a lot of effort to seem like a “small company” – but when you have an open call to hire more than 150 engineers, you’re not small.

Bring out your users… <dong>

What this data definitely will do is bring more users to the project, whereas before there were mostly devs/contributors, and very few users. We’ve already seen some of the first commercial uses of OSM data, albeit for very specific locations. With more data, better coverage more developers can use OSM data for their projects. And perhaps we’ll even see people able to load the data into their GPS receivers or nav systems and use them as their primary mapping source.

Having users is a whole different set of issues than what OSM has dealt with in the past. Part of the growing pains is dealing with a quick increase in the community size which can affect the quality of data, reduction in a feeling of ‘community’, and also just dealing with common issues, support, and questions from new people as they start flooding in.

Simple Inspirational

The primary contributors to OSM have been in Europe, and they’ll probably have the largest change from development to users. European contributors will have to deal with the possibility loss of identity that they had with OSM as a grass-roots organization and helping shape it as a larger, more stable entity.

But another benefit of this huge surge in usefulness and visibility of OSM is that it should inspire contribution and development around the world. It can spur users in Asia, New Zealand, Africa, and South America what the power and purpose can be in contributing new data. They’ll now see OSM not just as a bunch of geeks “over in Europe” running around with GPS units, but a solid, useful, system where they can contribute to and really use this new data and services.

Of course, all this will still take some time. OSM just got the imagery, and they’re still working out the bugs and features of the applet to convert the images to real street data. But it’s definitely a turning point in the open-geodata front, one that will cause quite a bit of excitement.

And good luck conquering the last of the dragon-lands.

Tags: openstreetmap, stevecoast, geobloggers, osm, yahoo, mapping, maps, geo, neogeography, gps,

Setup took a whopping 10 minutes (including waiting for the DNS of the MySQL database to propagate, and adding some accounts). You can setup projects, add users, limit users to specific projects, and add clients. It even looks really great, which is entirely not-normal for an Open-Source project, which is usually very innovative/solid, but looks like old white toast.

I don’t think it supports the nice API’s and such that BaseCamp does, but it’s an actively developed project, so hopefully it shows up soon.

However, there is another drool-worthy phone coming out in January. On the same vein as the Nokia N770 tablet, which is very hackable, the OpenMoko phone is a fully hackable mobile phone. GPS, quad-band GSM/GPRS, SyncML, microSD cards, apt-get install, Linux, GTK goodness. Future versions are expected with WiFi and Bluetooth. via Koen’s Blog

Also check out the LinuxDevices article which sports images including mapping applications.

Tags: mobile, openmoko, linux, phone,

It’s Open-Source project hosting, with what seems like very advanced issue tracking. Fast, easy to understand, simple.

There are already some projects up, like Rails App Installer and Biometric API for Linux.

I assume all/many of the Google Summer of Code projects will end up hosted here. Also, I could see Google providing something like a Krugle source-code search for finding specific files and code snippets. Then why not go ahead and toss in a Code Snippets where anyone could highlight/mark source code as useful, and pulled out for others to then see these snippets easily.

Google Hosting FAQ

Tags: google, googlehosting, sourceforge, opensource, open-source, programming, codesnippets, oscon, oscon2006

This is a great idea, and also an example of how a company can build a business around open-source technology. Nomad Labs has done all the work of installing, configuring, and maintaining the large, and often cryptic, set of services for a developer to just begin working on their specific application, rather than having to spend half of their time just being a system administrator.

The GeoHosting is limited to Australia only currently, but I could see this being expanded to other worldwide locations (especially since the premise of Nomad Labs is that they are spread all over the world).

The feature list looks like:

• lighttpd + fastcgi
• lighttpd + mapserver
• mapscript
• gdal/ogr
• gdal bindings+
• sftp data upload
• postgis (requires higher-level hosting
• 5GB, 10GB, or 15GB data storage

In the meantime, I settled myself to using the adequate Cartographer Plugin to easily create Google Maps. I even went so far as to extend Cartographer to switch to Yahoo! maps and MapQuest Maps.

I just came across another mapping gem, YM4R (yellow maps for Ruby) which handles GoogleMaps v2 (there is a patch for Cartographer to do the same), and Yahoo! maps, local, and traffic. Wow!

Not only that, it’s by the same developer of GeoRuby, The Pochi Superstar Mega Show!.

Check out the very good, and complete Ym4r + GeoRuby + Spatial Adapter tutorial

“Today in Royal Oak a new business…”

where Metacarta can then pull out Royal Oak and try and continue searching the documentation for more location pertinent information that Royal Oak may be in Michigan, or Florida, or Australia, or wherever.

The examples use the OpenLayers, mapping agnostic, webmap tool.

For a great example of all these technologies, check out Gutenkarte, which maps the locations for any book found in the Project Gutenberg library. I wonder how it deals with imaginary places, and mixtures of real and imaginary places (like Nowhereville, NY)

Technorati Tags: where2.0, where2con

I agree with Matt Croydon’s take on the 5/15-minute presentation schedule. It seems very “lightning round”, but also a really good way to get lots of ideas out and then move the interesting discussion to the sideline and various nightly gatherings.

In particular, the Birds of a Feather (BoF) meetings should be great. There is a Microformats meeting to discuss the possible directions microformat. also hope to meet with some of the GeoRSS developers and bloggers.

I’ve even secured a place at the Google Geo Developers day on June 12 – so I should get a chance to show off my cool mashup projects. Not to mention discussing other possibilities of visualizing geo-specific driving simulations in GoogleEarth.

I think my biggest concern about attending is wanting to meet everyone and discuss all the current ideas and possibilities in location information & mapping.

Of course, to get to California, I’m heading out of Vienna early, by way of Detroit, then on to San Francisco. Yay lots of time on a plane. Here’s to hoping for flying on something nice like an Airbus 330.

Mesh networks are simple: everything is a sensor and can connect to other sensors. She referred to it as “Ad Hoc Wireless networking”, but I think that confuses the issue, because then people start thinking it just means WiFi everywhere.

What it really means is that all of these sensors and network devices can talk to one another, gather, share, and use information. For example, if every car was a member of the mesh network, they would all share traffic information, road conditions, and driver destination, perhaps. Then your in-dash display would update real-time traffic ahead of you as each of these cars shared their data. Also, you may be able to get internet down the line as you all shared a common network system.

Other examples that have popped up in the past include finding potential mates/friends around you by a profile you broadcast, or tracking birds with RFID.

Of course, now that you have all this data, how do you share it? Robin says she envisions all of this being built on open-source technologies, to allow for “innovation” (aka ‘good hacking’). Open standards like GeoRSS could also be used to begin disseminating all of this data as it streams in and share it between devices. See the notes on Mikel’s XTech talk for more inspiration along those lines.

If the devices are cheap (< $100), open-design, and run on open-software, this is a great future. If, however, it is run by proprietary, expensive technology, and closed standards, then you’ll have a future where you get fast connections in your Ford car from other Ford cars, but no connection to all those BMW’s or Toyotas on the road.

What happens when users have the ability to hijack sites and how they expect to be used? For example, there are scripts to provide mapping functionality within Flickr!, or to compare book prices on Amazon.com with other vendors.

MapThis! overrides the “Map This!” link that shows up in GMail when an address is detected. Instead of linking to just a plain-ol’ googlemap, the link is “hijacked” to provide routing directions from the user’s geolocated position (using HostIP) to the address in the email.

This is useful, for example, if a friend sends you the address of their house, or that cool roller-rink with disco ball that you’re meeting up at and you want to quickly get directions.

It also demonstrates how a user isn’t limited by the interface a site-designer supplied, allowing them to customize and use the site as they wan.

Mashable states:

Does anyone really think that micropayments are a good idea? Paying one cent for every site I visit feels like a reading tax

I think micropayments are actually a great idea. Except for the web, we already pay a “reading tax” on everything: newspapers, magazines, books. We also pay a watching tax (except for network tv), a listening tax (either via ads, or buy your cd) and so on.

And micropayments shouldn’t apply to just websites. Open-source software is used by individuals and companies who find value in the tool and in some cases make money. Yet in most cases the original developer(s) never see a single $0.01. I can speak for this myself. There have been over 7000 downloads (that I know of via the tracking stats I have) of one of my programs DashSaver. This includes being included in MacWorld UK, and a Japanese Mac magazine, and being very favorably reviewed several times on sites and podcasts. Guess how much money it’s made me? (if you guessed anything other than $0.00, you were wrong – though if you guessed that it did win me a broken Newton Message Pad you’d be correct).

This doesn’t really bother me. I like making software and tools that people find useful. However, I’m a little less inclined, and able, to make great tools/sites/stuff when it comes out of my free-time and I don’t even have the option of making it my ‘day job’.

The only ways someone can monetize, and therefore begin to properly support themselves and produce great content and software is via advertising. Advertising drives up the cost of goods, makes a site fugly, and also can have a driving impact on the content itself (see also Lobbying of governments by corporations).

Anyways, Micropayments seem like a pretty decent idea – just have yet to be implemented well. The only current means of doing payments easily and universally is via PayPal, which takes a good chunk of the change for itself. And indieKarma requires 1 hour of viewing for 1 cent? Personally, I rarely spend more than 10 minutes on a site, and that’s for a good site.

So do what I do, if you like a site/resource, then make sure and give their advertisements a couple of clicks. Leave the windows open for awhile, and even click around and see what the advertiser has to offer. It’s no money out of your pocket, takes a short amount of time, and you’ll pay the site more than programs like indieKarma are offering.

Combine a local mobile webserver with the Opera Mini or Full Opera web browser makes for rapid development of nice phone applications.

They even offer some nice suggestions:

Interactive, Context and Location Dependent Content

These demonstrate that a website on a mobile phone is not just like any other website that simply happens to be on a mobile phone, but that it enables functionality that in the context of regular stationary websites is largely meaningless.

* Remote interactive picture taking.
* Use the phone as a webcam.
* Find other mobile web sites in the proximity.
* Find out the location of a mobile website (cellid).

This article will give a short overview of how to use the BlueLogger for a variety of applications. I use it primarily for geolocating photographs, but it’s also nice for any location-based activity.

The Bluelogger comes with the following:

• Bluelogger device
• Carrying case (with belt loop)
• Car charger
• Wall charger
• Charging stand (can work with either car or wall charger)
• Bluelogger Windows software

Connecting to GPS

To connect to the Bluelogger, you will need a bluetooth adapter. Many computers now come with bluetooth built-in or as an add-on option. If this isn’t the case, I would recommend the D-Link DBT-120. It’s probably the only D-Link product I can recommend, but I’ve had great luck with them, and never run into any device that it hasn’t worked with (and I have had problems with other BT adapters, especially on my Mac).

Once you have a bluetooth adapter, you will need to setup a connection to the device by pairing them. See your devices’/operating systems’ manuals on how to do this.

A very slick option is to run gpsd, which is a service-daemon running in the background that allows multiple connections to the single GPS device. Normally, only 1 software instance can connect at a time. With GPSd, you can “serve” your location. What would be really cool is to have GPSd be able to connect in with Geolocation by IP or Wifi as well as an actual GPS device to seamlessly switch between location technique.

GPSUtility is a nice, compact, graphical GPS application for Mac OS X. It can connect either directly to the GPS bluetooth port, or via gpsd. You can view location, satellite strengths, verbose NMEA output, and speed.

KisMac, while not a GPS-specific applicaiton, has excellent GPS support. KisMac is actually a wireless stumbler, which can also mark the latitude, longitude, and strength of detected networks and plot these on a map.

Storing & Viewing tracks

The Bluelogger software (currently Windows only) can export the tracks as GPL files. GPSBabel can convert these to a more useful format, such as GPX, which an XML format for GPS data.

Since using the bluelogger usually entails turning it on and off often, the entire track log will contain many separate trips. GPSBabel supports splitting up tracks based on a time separation. Each segment will be a self-contained track.

The following example will convert a GPL file to a GPX file, and make a individual track for any separation of 4 hours between points.

$ gpsbabel
  -i gpl -f Track_2005_11_23.gpl
  -x track,pack,split=4h,title="LOG # %c"
  -o gpx -F Track_2005_11_23.gpx

Displaying tracks

There are several options for displaying your tracks:

GPX Tracks

GPXLoader

• GPX Tracks HTML file

GPS and Nokia 770

ThoughtFix has a fairly comprehensive tutorial on setting up GPSDrive with a Bluetooth GPS receiver. They went with the i-Blue High Sensitivity Bluetooth GPS, which looks like a nice unit, but lacks logging.

Resources

• NMEA Protocol fields
• GPS Running Log -> GoogleMap on website
• Geocode Photos
• RoboGeo Windows photo-geocoding
• OziPhotoTool

One of my entries, which may or may not actually be considered a “mashup”, is a Firefox GreaseMonkey script called GreaseRoute that creates map and route icons for an Microformat formatted adr or geo locations. These are often used in an hcard.

One of the cooler parts is that the extension automatically determines the location of the person viewing the page. Using the HostIP IP-to-Location database, the user’s location is automatically entered as the starting location. So when a user is viewing the webpage of, for example, a store or business, they can click the “route” link and get turn-by-turn directions to that location. No more copy & pasting street/city/state to a form or asking the person next to you “where are we?”

Microformats are a stepping stone on the way to the semantic web. They are a simple way to encode useful information for viewing and mining by users and other applications (ala mashups).

Example adr

The proper format of the adr is as follows:

<div class="adr">
 <div class="street-address">1517 N. Main St.</div>
 <div class="extended-address">Box 203</div>
 <span class="locality">Royal Oak</span>,
 <span class="region">MI</span>
 <span class="postal-code">48067</span>
 <div class="country-name">US</div>
</div>

which will then be displayed as:

Example geo

Instead of an address, one can instead just encode the latitude and longitude:

The Result

GreaseRoute has 2 version, the lite version and the embed version. The lite version displays a map and route icon next to the addresses found on the webpage:

The embed version displays a “route” link. When clicked, a pop-up map is displayed between the users location and the encoded address.

Give GreaseRoute a try and let me know what you think.

You can also go over to Userscripts.org, the GreaseMonkey script repository, and rate them and leave comments.

• UserScripts.org: GreaseRoute
• UserScripts.org: GreaseRouteEmbed
• UserScripts.org: MapThis!

If you’re configuring ActionMailer and you try to run the console and get the following messages:

[host]$ script/console
Loading development environment.
./script/../config/../config/environment.rb:41:NameError:
  uninitialized constant ActionMailer
/home/highearth/.gems/gems/actionpack-1.12.1/lib/action_controller/integration.rb:15:
  NameError: uninitialized constant ActionController::Integration::Session::Test
./script/../config/../config/../app/controllers/application.rb:3:
  NameError: uninitialized constant ActionController::Base

Make sure your ActionMailer configuration in your config/environment.rb file is after your Rails::Initializer.run do |config| block.