Add accuracy in Google Geocoding (patch included)

[Pierre]

Hi

I'm needing the google geocoding accuracy in my application, but since it is
not available in Geopy, I patched geopy to implement it.

Thanks
Pierre

[Pierre]

Hi

This patch breaks the API, I'm gonna look at the Location/Point
classes to fix that.

Thanks
Pierre

Patch :
Index: google.py
===================================================================
--- google.py (revision 109)
+++ google.py (working copy)
@@ -97,6 +97,15 @@
def parse_place(place):
location = util.get_first_text(place, ['address',
'name']) or None
points = place.getElementsByTagName('Point')
+ details = place.getElementsByTagName('AddressDetails')
+ detail = details and details[0] or None
+
+ accuracy = None
+ try:
+ accuracy = int(detail.attributes["Accuracy"].value)
+ except:
+ pass
+
point = points and points[0] or None
coords = util.get_first_text(point, 'coordinates') or
None
if coords:
@@ -104,7 +113,7 @@
else:
latitude = longitude = None
_, (latitude, longitude) = self.geocode(location)
- return (location, (latitude, longitude))
+ return Location(location, Point(latitude, longitude),
{"accuracy":accuracy})

if exactly_one:
return parse_place(places[0])
@@ -136,7 +145,11 @@
def parse_place(place):
location = place.get('address')
longitude, latitude = place['Point']['coordinates'][:2]
- return (location, (latitude, longitude))
+ try:
+ accuracy =
place.get('AddressDetails').get('Accuracy')
+ except:
+ accuracy = None
+ return Location(location, Point(latitude, longitude),
{"accuracy":accuracy})

if exactly_one:
return parse_place(places[0])
@@ -163,7 +176,7 @@
latitude, longitude, location = marker
location = re.match(ADDRESS, location).group('address')
latitude, longitude = float(latitude), float(longitude)
- return (location, (latitude, longitude))
+ return Location(location, Point(latitude, longitude))

match = re.search(MARKERS, page)
markers = match and match.group('markers') or ''

[Mike Tigas]

I propose locking the API for now (say, until 1.0). I do agree that
the current (static) way of returning results is extremely limiting,
especially when considering that other backends (such as geonames)
attempt to include data like elevation. (Issue 6 and issue 13 both
stem from this limitation.)

In a future, backwards-incompatible (2.0-ish) release, geocoder
results should definitely be object-based, where possible. I would
recommend against backward compatibility by “faking” list behavior
within the object.

I’ll add this to the roadmap.

I’ve opened Issue 33 <http://code.google.com/p/geopy/issues/detail?
id=33> as a tracking bug to develop this a bit further. If we *are* to
break API compatibility, then we should ensure that we make the new
API fairly flexible and clean.

[Pierre]

But it looks like only the Google "backend" uses this static way of returning
results.
What would it cost to provide in the 1.0 release a google.py containing two
backends ? One returning the "good old" static data, the other one using the
extensible Location and Point classes ?