Incorrect order of fields for geocoding

Changing status.

Would it be necessary if #1967520: Use Google geocoding components filter for better results with addressfield gets in?

Patch from OP works in my case (NL -addresses and other European countries)

@Simon Georges #3 This patch is probably no longer relevant if components are implemented for google geocoding.

The problem with this patch is that it fixes the issue for the Netherlands, but messes it up for countries with the original address order. Ergo, this needs to follow the addressfield localisation.

On hold in favor of #1967520: Use Google geocoding components filter for better results with addressfield

Ok, let's focus on the other, but let's not forget it's only targeting Google.

This was postponed but since #1967520: Use Google geocoding components filter for better results with addressfield isn't being current anymore I proposed fixing this patch instead.
Using addressfield_get_address_format($field_item['country']) to establish the correct address format will be a nice solution for most use cases.

@basvredeling, so your response is to come on this issue and say that #1967250 "isn't being current anymore" and to fix this patch instead?

How about some people actually review #1967250, provide feedback, and suggest to others that it needs to be committed?

@ron_s sorry if I was a bit quick in formulating these posts mate. No harm intended. To clarify:

I responded to both #8:

Ok, let's focus on the other, but let's not forget it's only targeting Google.

and #1967520: Use Google geocoding components filter for better results with addressfield:

Given the recent release of 7.x-1.3 and focus on the 2.x branch, I'm not certain if anyone still wants this patch?

So my conclusion was: a) I tested your patch in 1967520, and didn't find it working currently, and b) we might as well fix this issue so long as 1967520 needs work.

@basvredeling, my concern is spending more time working on a patch where the module maintainers have provided no feedback.

I have experienced too many situations where maintainers offer no comments on patches for months, and then introduce a new version (such as we are discussing for 7.x-2.x-dev), that requires an entire re-write of what was previously done.

I need to hear from someone in charge of Geocoder that #1967520 still has value, and I'll gladly re-roll a new version.

Hi there,

Sorry for the lack of update in this issue, I must have skipped it.
Indeed, I'm the maintainer, but as explained in many other posts, I have personnal concerns right now and they require a lot of attention.
It requires so much attention that I'm unable to think about coding and diving into code.

I'm absolutely available for committing patches of course.

@ron_s, your patch can still be committed to 7.x-1.x and 8.x-2.x ?

Thanks for your understanding.

@Pol, I wasn't aware of the personal matters you are currently handling, sorry to hear. I assumed there was more than one maintainer working on the module.

The patch was originally created over a year ago, and 8.x-2.x did not exist at that time. Per the comment from @basvredeling, the 7.x-1.x version needs to be re-rolled based on recent commits. I can post a new version, but someone else will need to create a 8.x-2.x version.

Thanks.

@Pol, best of luck with your personal issues.

I've added a concept solution to reliably add the country specific order to the addressfield elements. This is not the most elegant solution because addressfield module only collects the proper address format during form rendering or output rendering. So I've tried hacking into this ordering without having to duplicate any sorting work done by addressfield plugins already.

In issue #2859851 the OP proposes a similar patch but relies entirely on address field to provide a formatted address. Would it still need a reorder of the fields as suggested here or does the address field already takes care of this? Wouldn't it be better to address this in the addressfield module? I like the simplicity of the approach and separation of concerns of #2859851

Can't we do some simple incremental changes to geocoder_widget_parse_addressfield() instead of using a completely different approach? Maybe it won't be perfect, but I think we can make it work better than it currently does.

The attached patch puts the premise after the thoroughfare, and the postal code before the locality, and then my results are all fine.

Putting the postal code before the locality (which usually is the city name) seems more reasonable than putting it before the country. So this seems like a good step.

In issue #2859851 the OP proposes a similar patch but relies entirely on address field to provide a formatted address.

I already commented over there. I am very skeptical about the approach, which uses the theme layer and produces a html address, and then applies strip_tags(). In the end we get an address string without commas or sometimes without spaces between components, which could be different per theme, and which might or might not be the format that Google or some other service needs.

The formatting functionality in addressfield is designed to look nice on the screen but not for sending it to Google Maps Geocoding API.
If it works for that it is pure coincidence.

Also it creates a dependency on addressfield (which is kinda ok because where else would those field items come from?)

#1967520: Use Google geocoding components filter for better results with addressfield:

This should be more reliable for sure. But it only works for Google, and only for the geocoding API.
Other modules that use e.g. the directions API still need the address as as string, because Directions API does not accept components (afaik). So I would like to see an address-to-string function that actually works, even if later on we switch to an approach with components.

Here are the improvements I would suggest:
- Put postal code before locality (city name).
- Use country code instead of country name.
- Use administrative_area name instead of code/abbreviation. With the abbreviations, geocoder completely fails for a number of countries including Spain.

Possibly controversial:
- premise after the thoroughfare? I think thoroughfare would be street name, and premise would be house number? This will be different per country.
- omit comma between street name (thoroughfare) and house number (premise), use space instead? not sure.
- omit comma between postal code and city name, use space instead? not sure.
- Use "+" (plus) instead of " " (space) for Google. This could be done in the Google callback itself, so it won't apply to other services.

Maybe we need different versions of geocoder_widget_parse_addressfield() for different services. But the above improvements do seem reasonable and universal enough that we could assume them to work for different services. Of course some testing would be good.

Using addressfield_get_address_format($field_item['country']) to establish the correct address format will be a nice solution for most use cases.

I looked at the result of this function. It does not tell us much about the order of fields.

Country: United Kingdom
Address 1: Newport Memorial Hall
Address 2: West Street
Town/City: Fishguard
County: Pembrokeshire
Postcode: SA42 OTF

How do we get from "Address 1" and "Address 2" to "thoroughfare" and "premise" as used in geocoder_widget_parse_addressfield()?

As pointed out by Rick J in #2859851-8: Geocoding from address field fails under some circumstances, my concern about the added dependency is invalid.
In this function we already assume that addressfield exists.

Hi all,

What's the status of this ?

Thanks!

Hi, Yes would love to know the status.
I have problem using this in relation to a view. With all sorts of geocoding I got;
Geocoder cannot find this location. Check your connection or add a findable location.

Thanks for the update and greetings, Martijn