@ 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.