Limits of the Android Geocoder

blueBill Mobile, for which a brand new site has just been created, provides some important location-oriented feaures, as it records the coordinates of bird observations. While, after all, the coordinates are the single important location datum, as they can be resolved later with some postprocessing, blueBill Mobile makes it possible to share your observations in real time: in this case, making available the name of the place where you saw the bird might be valuable, because not everybody in your recipient list has got a GPS-capable phone (... yet?).

Android provides a Geocoder in the standard APIs which is pretty simple to use, as this code excerpt demonstrates:

import android.content.Context;
import android.location.Address;
import android.location.Geocoder;
import it.tidalwave.geo.Coordinate;

Context context = ... ;
Coordinate coordinate = ... ;
Geocoder geocoder = new Geocoder(context);
List<Address> addresses = geocoder.getFromLocation(coordinate.getLatitude(), coordinate.getLongitude(), 100);

Unfortunately, tests on the field proved it to be almost useless, at least in my typical scenarios. The problem is that it seems that a single geocoder service is available (and of course it is the one provided by Google by means of its web services) and the following problems arise:

1. I've repeated this a number of times in the past years: the "always connected" thing is a myth. Italy's mobile network coverage is excellent and just an epsilon below the 100%. Still, in the countryside, or in a dense wood, it's easy to find places where the radio signal is so weak that the connection doesn't work or takes a very long time to transfer data. Usually it's a matter of moving around to pick a better signal, but this is not the thing you want to do while observing birds. Thus, I need to have a geocoder capable to resolve at least a subset of common locations without requiring a network connection.
2. 
   
3. The quality of data provided by the Google geocoder in my country is very variable. Sometimes it's able to pick even the name of the nearest, small fraction of houses around; other times it just resorts to returning "Province of XYZ", which is too vague. Being able to aggregate multiple results from different geocoders (e.g. GeoNames, or Yahoo!) might resolve the issue or at least improve things here.
4. 
   
5. I've realized that for my purposes I also need to rely on user-provided location names. For a birder, the indication "Observatory #5 in the FooBar Wildlife Sanctuary" might be extremely useful, but I don't think it's even possible to have the Google geocoder capable to resolve it (while it would be possible, for instance, with GeoNames that accepts user-contributed data). Another case for multiple geocoding services, one of which should be local. Indeed, I'm a bit surprised that Android doesn't provide a service to register custom locations in the preferences, as it is possible e.g. to have a database of contacts.

In other words, the Location APIs in Android are too closed and Google-centric. I'll have to import the code used in forceTen, which implements pluggabe GeoCoders and already has got a GeoNames provider. Fortunately, the fact I'm able to run at least a subset of the NetBeans Lookup API on Android should make the task not too hard to achieve.

First Screencast of blueBill Mobile

I'm able to provide a first decent screencast of blueBill Mobile, even though I've still to learn and improve the way screencasts of Android applications can be made: