Address Field: Name Field For Geocoding Missing

[jakobhaerter]

The Google Maps Plugin has a dedicated name field where you can input location names, city names without providing a street name etc.

We would like to switch from Google Maps to Mapbox because the API key handling is much more straightforward, especially when working with clients. However, the geocoding autocomplete feature currently only works with street names, not with full addresses and location names – this option is very important for us.

Is there a reason why the Mapbox Plugin comes without the name field or are we missing something?

Thank you!

[MoritzLost]

@lindseydiloreto Any word on this? We're really hoping to be able to switch from the Google Maps plugin to this Mapbox plugin – we mostly use Mapbox in the frontend anyway, so having a Mapbox-powered address field as well would be great. However, lack of support for location names and autocomplete using place names is a real stopper for us.

[lindseydiloreto]

Hey, sorry for the late response! The answer is complicated and I'm currently traveling.

The short answer is this... When you select an address from the results, and all other subfields get automatically populated, Google Maps and Mapbox handle this extremely differently.

With Google Maps, the API is returning a complex array of data. Then the Craft plugin takes this data and "manually" populate each related subfield.

With Mapbox, the API relies heavily on the browser-native autocomplete attributes. Mapbox wants to "automatically" populate the other subfields, according to standard browser specs. We are only "manually" populating the longitude & latitude subfields based on the response data.

There is no autocomplete value which maps to a place name.

I have mixed feelings about this... Using a browser-native solution is obviously preferred, but it's leading to some notable limitations. We may end up ditching the autocomplete attributes, and "manually" populate each subfield (like we're doing with the Google Maps plugin).

And relatedly, there seem to be multiple overlapping Mapbox APIs for looking up an address. It's possible that we need to adjust which API we are using, and/or how we are using it.

I'm certainly open to suggestions on the best path forward! Feel free to hit me up on Discord if you want to get into the weeds about it.

[MoritzLost]

@lindseydiloreto Thanks for the explanation!

As a first step, having a name subfield, even if it can't be autofilled, would be an improvement. This would allow editors to manually enter a name as part of the address, since a lot of use-cases require this – and having a separate field for the name is really inconvenient and not great UX.

I could be wrong since I haven't used the Autofill API before, but looks like it does include place / feature names: https://docs.mapbox.com/mapbox-search-js/api/core/autofill/#addressautofillsuggestion

The JS component that does the autofilling probably provides access to the underlying API result. So I think it should be possible to access that data in a hook and write it to the subfield, the same way you're writing the coordinates? If that is not possible, maybe use the underlying core component so you have full access over the API result?

As an alternative, have you considered the Search Box API? Looks like it has similar features, except the automatic autofill based on the autofill parameter, and it does provide access to the full search result. The API response definitely includes the place/feature names: https://docs.mapbox.com/api/search/search-box/#response-get-suggested-results

[lindseydiloreto]

I agree that, at the very least, the Mapbox plugin should have subfield parity with the Google Maps plugin. We can start by adding all remaining subfields in a neutral, non-automated state.

This has the added benefit of making the data more portable between the two plugins.

Once Mapbox has all remaining subfields, we can circle back on the API decisions. Switching to the Search Box API may be the correct answer.

[MoritzLost]

@lindseydiloreto Sounds good, thanks!
Yes, I think switching to the other API might be the best solution. It's a bit more versatile as far as I remember, and will probably be required for some of the other issues (proximity search & geocoding) anyway.

[lindseydiloreto]

This is done. It took a bit of work, but I've swapped out the Autofill API for the much more flexible Search Box API.

Once that was done, it was straightforward to add all remaining subfields for parity with the Google Maps plugin. It also clears a path to more easily handle #7.

It may be a few more weeks before these changes are pushed live, but you can grab it now from the v1-dev branch...

"doublesecretagency/craft-mapbox": "dev-v1-dev"

Important Note:

In order to add the "Name" subfield, you will need to resave each of your existing Address fields. By default, the new subfields will not appear until you add them to the Address configuration.

This also gives you the opportunity to select which subfield(s) will trigger the autocomplete results.

[MoritzLost]

@lindseydiloreto Awesome, thank you 🚀
Just gave it a try, works great. That's an immense improvement, feels much closer to Google Maps now in terms of feature-parity. Being able to use autocomplete on every field is very nice, as now the editors can enter either a place name or street address in either name or street1, and the results will populate the correct fields regardless of where it was entered. Switching to the more powerful API was definitely the right move. Looking forward to this release, thanks!

[lindseydiloreto]

@MoritzLost Ok fantastic, thanks for reporting back!

Glad to hear it feels like a huge improvement (I totally agree)! 👏

[lindseydiloreto]

Great news, v1.1 has been officially released with these changes. Thanks for the feature request! 🎉

Address fields now includes the following new subfields...

• name
• neighborhood
• county
• mapboxId

Fun side note... we also added a mechanism to transfer your Address data from the Google Maps plugin. 😉

[jakobhaerter]

Great news indeed, thank you @lindseydiloreto! 🙏