Extending API to return the Accuracy / Precision ...
James Robinson
We had written up our own API layer which talked to either
geocoder.us or yahoo -- did the development about a year ago when
yahoo's TOS wasn't nearly so restrictive. Anyway, our app logic
branched according to the accuracy of the geocoding response. Looking
at geopy's return results, looks like the accuracy is not available
to the caller, even when using a service which returns it.
Would there be an interest in:
1) Changing the return type of the geocode() methods to an object,
possibly implementing __getitem__ so that the old syntax of
place, (lat, long) = y.geocode("Thames Street, Newport, RI")
could still be supported. See code at bottom.
2) Adding a data member of said object to hold the precision, or
None if underlying service does not support it.
3) Also trying to normalize the various underlying service's
precision or accuracy codes to a common api standard codes meaning
street address level, street level, zipcode, etc. Asusming there's a
possible uniform mapping. This normalized result would be a separate
data member / property from the bare exposed accuracy result from the
network service.
I could offer a patch which does #1 and #2, and a mapping for yahoo's
codes to 'street', 'zipcode', etc. I've not investigated what
google's accuracy values mean.
Proof-of-concept code where a returned object could still support the
preexisting place, (lat, long) = fxn() idiom used by geopy already so
such a change ought not hurt any existing users [ but they'd not be
able to get at any of the other data members of the returned object,
such as the precision.
class Test(object):
def __init__(self, a, b, c):
self.a = a
self.b = b
self.c = c
def __getitem__(self, idx):
if idx == 0:
return self.a
if idx == 1:
return (self.b, self.c)
else:
raise IndexError()
def __len__(self):
return 2
place, (lat, long) = Test('the place', 12, 34)
----
James Robinson
Socialserve.com
Brian Beck
> Would there be an interest in:
>
> 1) Changing the return type of the geocode() methods to an object,
> possibly implementing __getitem__ so that the old syntax of
>
> place, (lat, long) = y.geocode("Thames Street, Newport, RI")
>
> could still be supported. See code at bottom.
>
> 2) Adding a data member of said object to hold the precision, or
> None if underlying service does not support it.
>
> 3) Also trying to normalize the various underlying service's
> precision or accuracy codes to a common api standard codes meaning
> street address level, street level, zipcode, etc. Asusming there's a
> possible uniform mapping. This normalized result would be a separate
> data member / property from the bare exposed accuracy result from the
> network service.
Sounds good, especially because I want to make a compound geocoder that
will just try all the services and returns the most accurate result.
> I could offer a patch which does #1 and #2, and a mapping for yahoo's
> codes to 'street', 'zipcode', etc. I've not investigated what
> google's accuracy values mean.
Sounds great, post it and I'll look into adding it to the next version.
> Proof-of-concept code where a returned object could still support the
> preexisting place, (lat, long) = fxn() idiom used by geopy already so
> such a change ought not hurt any existing users [ but they'd not be
> able to get at any of the other data members of the returned object,
> such as the precision.
Good idea (I'm fond of that idiom). It also might be reasonable for the
first item to return self (a GeocodedPlace object or something) and the
str() of it be the place name, although it would be a bigger semantic
change. Then people could still use the idiom while saving the full
GeocodedPlace object.