> I guess that depends on your use case (which I guess is your point, right?)
I think that's the size of it; so far as I can see the geocoder is
provided by Google to extract some/any kind of location from user's
mangled input, which makes it inherently unsuitable for address
validation (or the pa
Since the terms of service require you to use the geocoding result in
conjunction with a google map you could ask your users to confirm that the
marker you have placed is in the correct place when the you get an
approximate result returned from the geocoder and either allow them to drag
the mar
@Rossko,
I understand your point; if the Geocoder were smart enough to know that
Donwing st. means Downing St, or that Londno means London, and return
something like 'street_address' for the location_type and 'best_guess' for
type[0] it would certainly be helpful.
...but is it helpful to retur
I maintain that the geocoder is fully intended to give results for
mispelt "10 Donwing Street, London" - you would rather it didn't.
While you do want results for non-existant "1234 Downing Street,
London"; I can't guess what you'd expect for non-existant "10 Downing
Street, Londno"
--
You receiv
@Rossko,
No, I don't think this is the desired behavior for a street that doesn't
even *exist*. There is no street, neighborhood, or premise with the name
"bullshit st" in most areas (of the United States, anyway).
This certainly was not the behavior 2 months ago.
I am not trying to use this i
> *However, *entering a non-existent address such as "1234 nowhere Ln.,
> Durham, NC" or "532 Fake St. Durham NC" or "235 Gobbledygook Rd. Durham NC"
> causes the API to return a status of "OK" and results[0] holds the same
> LatLng object as if you type simply "Durham, NC" in maps.google.com.
The
