Geocoder returns OK instead of ZERO_RESULTS for non-existent addresses

[waldo22]

Sometime in the last 6-8 weeks, the Geocoder started returning a status code of "OK" instead of "ZERO_RESULTS" for non-existent addresses.

ZERO_RESULTS is the expected response for non-existent addresses as documented here:
http://code.google.com/apis/maps/documentation/javascript/services.html#GeocodingStatusCodes

My site uses the geocoder to determine if a person is inside of my service area or not.

The API works just fine for addresses that are found; it either tells the user that they are not in our delivery area or it allows them to proceed.

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.

Is anyone else experiencing this?

Here is a link to the page showing this behavior:
https://www.scratchtakeout.com/cgi-bin/geocodeTest.pl
(I am using alert(status + ' ' + google.maps.GeocoderStatus.OK) for debugging, but both say "OK")

Here is our code from that page:

var geocoder;  //this is a global variable 

function initialize() {
        geocoder = new google.maps.Geocoder();
    }

    function loadScript() {
      var mapScript = document.createElement('script');
      mapScript.type = 'text/javascript';
      mapScript.src = 'http://maps.googleapis.com/maps/api/js?sensor=false&callback=initialize';
      document.body.appendChild(mapScript);
    }

    function codeAddress() {
        var address = document.getElementById('streetAddress').value;
        var city = document.getElementById('city').value;
        var state = document.getElementById('state').value;

        if (address === '') {
            alert('You must enter a street address!');
            return false;
        }

        address = address + ' ' + city + ' ' + state;

        geocoder.geocode( { 'address': address}, function(results, status) {
          if (status == google.maps.GeocoderStatus.OK) {
            alert(status + ' ' + google.maps.GeocoderStatus.OK);
            //whichZone(results[0].geometry.location);
            return true;
          } else {
            showLightbox(320,130,'10px','notFoundChoice');
            document.getElementById('tryAgain').focus();
            return false;
          }
        });
   

Since all fake addresses return a real LatLng object (the city center), along with a status of OK, there is no way to determine if a geocode was really successful or not.

Any help is appreciated!

-Wes

[Andrew Leach]

On 6 December 2011 22:53, waldo22 <w...@tarheeltakeout.com> wrote:
> Sometime in the last 6-8 weeks, the Geocoder started returning a status code
> of "OK" instead of "ZERO_RESULTS" for non-existent addresses.
>
> ZERO_RESULTS is the expected response for non-existent addresses as
> documented here:
> http://code.google.com/apis/maps/documentation/javascript/services.html#GeocodingStatusCodes

I haven't done much with this, but there are other results fields returned:
http://code.google.com/apis/maps/documentation/javascript/services.html#GeocodingResults

Do types and location_type help to determine what the geocoder is
telling you? I guess for a real address you would get either ROOFTOP
or RANGE_INTERPOLATED, and if it was limited to a city centre you
wouldn't get those.

I think ZERO_RESULTS will be the response where the geocoder gives up
completely.

[Rossko]

> *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 geocoder is working as it should; it's doing the best it can to
provide some kind of location from mangled input. It's not an address
validation service.
But, as Andrew says, you can examine just what kind of guess it has
made.

[waldo22]

@Andrew,

Thanks so much for your helpful reply.

I changed our "check" code to:

if (status === google.maps.GeocoderStatus.OK && (results[0].geometry.location_type === 'ROOFTOP' || results[0].geometry.location_type === 'RANGE_INTERPOLATED'))

This seems to be a good workaround.

If an address isn't found at all on a real street, location_type is "GEOMETRIC_CENTER" (of the street) and the type is "route", but the street center isn't useful information for us anyway, so it's no big deal to exclude the location_type "GEOMETRIC_CENTER".

Also, if a neighborhood name is entered, the location_type is "APPROXIMATE", but people don't generally type in neighborhood names, so it also isn't a problem to exclude this location_type.

Thanks again,

-Wes

[waldo22]

@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 it as an address verification service;  range_interpolated results are perfectly fine, and "APPROXIMATE" results with a type of "neighborhood" or "premise" would also be fine.  (our code wouldn't have handled it, but it does now thanks to Andrew's suggestion)

It seems perfectly reasonable for a non-existent address on a real street to return "APPROXIMATE" results with a type of "route".

It does not make sense to return a type of "locality" when the data entered does not match anything in the specified locality.

The expected behavior (indeed, the previous behavior) for this scenario was to return ZERO_RESULTS.

I wish they hadn't changed this, but it seems that examining the type of results is more reliable solution anyway.

Thanks for the help.

-Wes

[Rossko]

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"

[waldo22]

@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 return results of location_type 'locality', type[0] 'approximate' for the city of London if you misspell Downing St.?

In other words, you misspell the street name, so rather than return results for that street with a type of 'approximate' or 'best_guess' the API returns the LatLng of the city center?

I guess that depends on your use case (which I guess is your point, right?)

Honestly, now that we are checking the other results, it's not really a problem.

My frustration was that it changed.  It used to return ZERO_RESULTS, but sometime in the last 8 weeks it started returning 'OK' with the location_type of 'locality' instead.

If you go to maps.google.co.uk and type in '10 donwing st. London' it puts a marker on 10 Downing St. and says "did you mean..."  So I think Google is smart enough to detect typos, at least.

If you type in "10 bullshit st. london" it says "we could not locate this address" and doesn't put a marker there.

( I know that "maps" and the API are two different things, but I though it helped make my point).

Anyway, I see where you're coming from.

Thanks for the lively discussion.

-Wes

[MymsMan]

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 marker or to re enter the address.

[Rossko]

> 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 partial validation you require)

> Honestly, now that we are checking the other results, it's not really a
> problem.

Understood

> My frustration was that it *changed.

Yep, they do that. For most use-cases it would be an enhancement.
One of the real maps gurus often said "never trust a geocoder",
they're never more than a best-guesser.
Only the end user knows what they really mean, hence maps.google.com
"Did you mean?" feature. API developers can produce their own
tailored version (e.g. in your case it might be geographically
limited)