[Andy Castle]

Thanks for the comprehensive response Steve.

With UK addresses, there can be inconsistencies in format: some eforms will ask specifically for House Name/Number before the Street Name, others will ask for address line 1 and expect the user to include House Name/Number and Street Name (this latter option is the standard option for our public mail). I fully understand the difficulties of dealing with international address formats on websites.

In the example we’ve discussed, Trinity Centre is the house name (there is no house number), and for correct postal addressing this must be the first entry in the address. So with Connections I have to ensure the display of the address is correct on the tile, but also works with Geocode.

I’ve tried alternatives with the way Connections/Google now works, and it’s clear that putting a House Name in line 1 now screws things up for Geocode: I promise you it didn’t when I loaded most of my directory. The way it now works most accurately is with a House Number and Street in Line 1. I can’t get accurate locations for addresses with House Names. This causes me most problems for buildings which house a number of organisations and have a name and no number, quite a common occurrence in our rural location.

Connections is the backbone of my site and as you’ll know from previous issues, I’ve been extremely impressed with the way you support the plugin.

I see you’ve marked this topic as resolved, but I would appreciate it if you could give it some further thought.

Andy.

[Steven Zahm]

@ Andy

Yes, I marked as resolved, but I did say I would look into it, which I did.

It seems Google did make a change. That posted this announcement on their dev blog.

Reading over it, as far as I can tell, I am indeed following their outlined best practices. I should be using the Google Maps API for unambiguous queries, which I am. I would qualify this address as unambiguous, per Google’s definition.

Trinity Centre
Thakeham Road
Storrington, West Sussex RH20 3NG

Trinity Centre, Thakeham Road, Storrington, West Sussex RH20 3NG

However, even on their own test/demo site for developers, no Geocode results are found (the Places API autocomplete works fine) when using the new forward geocoder. Unchecking that option, so the old geocoder is used, and it does return a match.

I guessing this match under the old geocoder is what you would have seen. It appears, according to their FAQs regarding the new geocoder that I can “force” use old geocoder until March 2017. I made the tweak to my code to use the old. This change will be rolled into the next update.

Planning for the future…

Playing with the options, if I set the Component Filtering to the Postal code I was able to get a similar result to the old geocoder.

Why Google doesn’t simply parse this from the supplied address like the old geocoder, I have no clue.

I hardcoded the Postal code into my scripts and now it works, of course only for the Trinity Centre address.

So, what I should be able to do is check if the zipcode field is set then set the Postal code component filter as part of the query. This is not a quick easy fix. I use a third party library to interact with the Google Maps API to simplify using it. This library unfortunately does not support adding Component Filtering options. So, I have to come up with a different solution. I’ll come up with one before March 2017, so expect your results you see to change again Sorry about this, not much I can do about this since this is a change by Google.

[Andy Castle]

Hi Steve,
I really appreciate that you go the extra mile for your customers.

Such a nuisance that Google should mess things around like this when so many are relying on their features. I’m sorry it means so much effort for you.

I’ll keep an eye out as you release the new versions.

I hope this hasn’t too irritating in the run up to the Holidays.

Seasons Greetings,
Andy.

[Steven Zahm]

@ Andy

No problem! Thanks for alerting me to the issue. If you wish, I can apply a “hot patch” to your site so you do not have to wait. I do not expect to release another update until the new year. I would have been a great service to developers everywhere if Google could have waited one more month before rolling this out, or, even put a notice in the browser console like they have for other changes.

fyi, I did notice you have not yet setup Google Maps API keys. You should do this sooner rather than later because Google is now requiring the keys. If you do not create them, the maps features will stop working eventually. All new site require one right away, “old” sites are grandfathered but will at some point require a key too.

[Andy Castle]

Hi Steve,
I don’t think you need to apply a hot patch: thanks to your guidance I can work around it until your next release (not too many many new organisations springing up here at this time of the year). It was kind of you to suggest it.

Thanks for the heads-up on the need to set up Google Maps API keys. I had no idea I needed to do this. I’m trying to find out what’s involved. I have other sites which display Google maps and I suppose they will all need attention.

Andy.

[Steven Zahm]

@ Andy

I do have a tutorial on how to get a Google Maps API keys.

Google has changed the steps slightly since the tutorial was written.

Instead of choosing API key types, create two keys. Add a referer restriction to one key following the example referer in the tutorial. This one will be the Browser key. The key without a restriction is the Server key.

Make sure you set a referer restriction on the Browser key or anyone will be able to use your key and then you’ll be charged for any overage use.

Hope that helps!

ps. You should set up different keys for different sites. Connections and All-in-One Calendar can share the same key on the same site, just use the Browser key in the All-in-One Calendar settings.

[Author]

Posts