Fabrizio Giudici is a Senior Java Architect with a long Java experience in the industrial field. He runs Tidalwave, his own consultancy company, and has contributed to Java success stories in a number of fields, including Formula One. Fabrizio often appears as a speaker at international Java conferences such as JavaOne and Devoxx and is member of JUG Milano and the NetBeans Dream Team. Fabrizio is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. You can read more from them at their website. View Full User Profile

Limits of the Android Geocoder

05.03.2010
| 11856 views |
  • submit to reddit
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. 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.

  3. 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:

Published at DZone with permission of Fabrizio Giudici, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Alex(JAlexoid) ... replied on Mon, 2010/05/03 - 7:44pm

Unfortunately Geocoder is still very limited. That is why I reverted to just creating a database of named locations where I need them (And that adds a positive point of having your home called 'Home' instead of just a vague address).

And I can't still find out how to install a custom LocationProvider.

But then again, Google are the leading ones in providing this kind of global service. And there are a lot of issues with android.location, unfortunately. Thankfully those issues are not crippling errors.

Fabrizio Giudici replied on Tue, 2010/05/04 - 3:26am

Good point, the need for personalized names of places is another reason for having one's own location manager. Yes, these are not errors, but missing features, and the fact that we're having Java 5 makes it easier to use existing stuff, even though I think that for the custom location database using sqlite is really needed.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.