Store user geolocation

[CeciliaHinga]

From tenfour-archive created by mackers: ushahidi/tenfour-archive#1562

TenFour backend updated to store user locations

Suggested Spec:

• create table users_location
• table has user id, location_text, location_geo, created_at, updated_at columns
• table can have multiple rows for each user
• when user address is changed or added, the address is geocode to lat/lng
• row is updated/added
• may need to think about geo precision/scale (i.e. if only a city is recorded for a user, this table needs to know that the user is in a city area, not just precide lat/lng)

[CeciliaHinga]

@rowasc this work needs to be done regardless of final UX/ethics decisions for alerts

Can you start on this please?

[CeciliaHinga]

ok

location_geo would be a geo type, right?

when user address is changed or added, the address is geocode to lat/lng

So in the backend we would call a geolocation api like google maps API and do this conversion ? or would the frontend do this instead?

location_text

is this the full text address of the user? (or city+"state/department/etc"+ country if that's what they provide)

may need to think about geo precision/scale (i.e. if only a city is recorded for a user, this table needs to know that the user is in a city area, not just precide lat/lng)

Yes.

[CeciliaHinga]

ok, thanks.
If we plan on having the ability to let users select an area of interest OR do point in polygon lookups locally for some situations (like we currently do in our mariadb-compatible lambda query) , geo will be necessary. If not, we might get away with a text field.
Might be a mysql version thing. I'll check it out.

[CeciliaHinga]

Yes, backend should call the geocode API.

I'm not sure the geo support in laravel. The location_geo column in replies seems to be just a TEXT column. I think last time we visited, there was an issue using the geo column type. I'll invite you to investigate the best solution to this.

location_text is the address they provide.