location field type: return more mapbox metadata

[pjmuller]

Feature

The location field type it returns the latitude and longitude as a string (e.g. 44.427946,26.102451).

However as it connects to mapbox API there are a lot more relevant data attributes at our disposal. For us it would be interesting to receive a hash with things like

• address
• postal_code
• city
• country

Current workarounds

Not aware of any hacks to get this data

[adrianthedev]

That would be a good enhancement, yes.

[TobiasKampAdmin]

Hi @adrianthedev , Is there any update on this?

It would be great to have a field-type where:

• users can enter a humanized version of an address (ex. 'Baker street 1 London')
• with Mapbox this being processed to coordinates
• but also add a hash (or dedicated columns) with the address, postal_code, city, province and country

A bit like this in Monday.com: https://support.monday.com/hc/en-us/articles/360001144325-The-Location-Column Or this in Asana: https://asana.com/nl/apps/taskmap

[adrianthedev]

I see two things here with this enrichment.

1. get the coordinates to be stored on the record
2. get more information from the API (postal code, city, etc.)

The first one could be a field, yes. Possibly a custom field that's shown only on forms

For the second item, where would you see this information beings stored? on the record for each individual property, or fetch it from the API everytime to do what?

[pjmuller]

Hi @adrianthedev ,

1. you got me confused, the current behavior of the location field is already storing the coordinates as "#{lat},#{long}", what's different?
2. for us it's cleanest to store each part in a separate table column (e.g. imagine the field is called :shipping, we store shipping_latitude, shipping_longitude, shipping_address, shipping_postal_code, shipping_city, shipping_province, shipping_country. Though if we receive everything in an object we can denormalize it via a before_save hook for example

[adrianthedev]

For 1. I meant get the coordinates from the API after the user inputs a human-readable address.

But we could simplify it by getting the human -readable address from the user, fetching the data from the API and then just passing that to the record. You could pick it up using a setter on the model or how you proposed using a before_save hook.

[pjmuller]

@adrianthedev is all then clear regarding the feature request? What I did not see you mentioning is the autocomplete part which is definitely a big plus (e.g. https://www.mapbox.com/address-autofill#:~:text=Try%20out%20the%20Address%20Autofill%20Demo )

[adrianthedev]

I don't know if we have everything we need about this request. I'm re-reading the original post and can't visualise a flow.

• the user sees the text input
• they fill in an address
• they get some suggestions
• they select a suggestion and then what happens?
• if they selected a suggestion, what happens when they click submit?
• if they don't select a suggestion and just leave a semi-complete (or a complete) address in the field; what happens when they submit?

[pjmuller]

@adrianthedev , apologies for the late reply I'm "holiday" with my 3 kids at home, exhaustion is around the corner ;p.

here's my answer: https://www.loom.com/share/7ee368e1d6e34dad8eab0143dfbab6cd (demo = https://www.mapbox.com/address-autofill#:~:text=Try%20out%20the%20Address%20Autofill%20Demo ) Does this make more sense now?

PS: if you don't want to use the mapbox component (or logic) you could also go for the 80/20 approach that when the address is not recognized by the autocomplete that you store the full string in the _address input and leave all other attributes empty

[Paul-Bob]

IMO this would work great with a new field type as: :address backed to a JSONB column

Where the address component renders all those fields from the demo link and the information gets stored in one single column as JSONB