Re: Geocoding Service with street number ranges (or lack thereof)

469 views
Skip to first unread message

Hayds

unread,
Sep 26, 2014, 2:34:20 AM9/26/14
to google-map...@googlegroups.com
I have the same problem.

https://maps.google.com/maps/api/geocode/json?language=&region=&components=&address=10+Gladstone+Ave+Wollongong+NSW+2500&sensor=false
gives me "location_type" : "RANGE_INTERPOLATED"

where specifying a subpremise on the same address gives me the correct result
https://maps.google.com/maps/api/geocode/json?language=&region=&components=&address=1-10+Gladstone+Ave+Wollongong+NSW+2500&sensor=false
"location_type" : "ROOFTOP",

But this does not always work because:

https://maps.google.com/maps/api/geocode/json?language=&region=&components=&address=16+corrimal+st+NSW+2500&sensor=false
gives me
"location_type" : "RANGE_INTERPOLATED",

and specifying a subpremise
https://maps.google.com/maps/api/geocode/json?language=&region=&components=&address=1%2f16+corrimal+st+NSW+2500&sensor=false
give me "location_type" : "ROOFTOP", but the building doesnt exist and is not on the map. This looks like a bug.

 
On Friday, 15 March 2013 16:48:21 UTC+11, Tim Vernum wrote:
Sorry if this has been asked before but I couldn't find a useful search string that would find me any meaningful results

I'm geocoding via the service at http://maps.googleapis.com/maps/api/geocode/json

My issue is when I enter an address that should use an street number range, but doesn't (e.g. 10 Main St vs 10-12 Main St) I (usually) get range-interpolated results, and sometimes they're not very good.

Often result is not interpolated at all, and the service works out that the provided address is actually part of a ranged address, and returns the correct (ranged) address, and the rooftop location. That makes me happy.
The majority of the time the interpolated result is pretty good, and our users are happy, and no one really cares too much. 
Sometimes it's interpolated and way off the mark, and sometime the service decides its ambiguous and returns multiple partial matches. Both of those make me unhappy.

An example of a badly interpolated result

gives a RANGE_INTERPOLATED result, because 518 is not a standalone address (it's actually 518-522)

But the interpolated result is a long way off from where 518-522 actually is.

Of course,
gives an accurate ROOFTOP result

but interestingly:

As it happens, using the same addresses at maps.google.com gives much more reliable results - i.e. Searching for 518 gives a Lat/Long that is very close to the result for 522
This of course makes our users think that our app is doing something wrong (and maybe we are...)

Note: We are using a Maps for Business license, and within our app those JSON requests would be signed, but I've left it out for simplicity's sake.

And an example of a partial result:


But changing "217-223" into just "217" gives us a number of partial matches, none of which are the 'real' one

(In fairness, getting locations right on a street that decides to renumber itself every couple of kms, has got to be a hard problem, but in this case I think the 217-223 address should at least be one of the matches returned)

And for good measure some well interpolated results
So....

Is there anything I can do to get reliably better interpolation (or even a rooftop) for a street number that should be part of a range, but isn't?
I can easily change our code if there's a work around, but I can't really get our users to provide more accurate address information (it's usually passed through 3 or 4 sets of hands before it gets to us, so there's no real way for us to go back and say "Google doesn't think that's a really address, can you check it?")
The only thing I can think of is to run it through a fuzzy match on Australia Post's DPID list, but I was really hoping that the geocode service would have enough smarts to make that unnecessary.

It's pretty common for people who live at an address with a street number range to simply provide the lower bound as their street number (even if it's not strictly correct), and unfortunately it's hit or miss for us when we then try to geocode them, and that's causing us some problems.

Thanks.

Note: I didn't post this to StackOverflow, because I didn't think it was really the type of question that belonged there (and I was worried it would get closed if I tried).

Reply all
Reply to author
Forward
0 new messages