Displacement has lon and lat the wrong way around

[jc-harrison]

Describe the bug
In Displacement._make_query, the SQL string to calculate distance is created as

dist_string = get_dist_string("lat_home_loc", "lon_home_loc", "lat", "lon")

However, the calling signature of get_dist_string (as defined in utils.py) is

get_dist_string(lo1, la1, lo2, la2)

Displacement is passing lat and lon values the wrong way around, so distances will be incorrect.

Product
FlowMachine

Additional context
There is some inconsistency more generally around the ordering of "lat" and "lon" in FlowMachine (e.g. "versioned-site" level has columns ["site_id", "version", "lon", "lat"], but "lat-lon" level has columns ["lat", "lon"]). This is mostly not a problem, since the values are usually in columns referenced by name, but more consistency around this would reduce the chance of these bugs popping up. I'm attempting to make this consistent as part of my spatial unit refactoring, choosing ["lon", "lat"] ordering for consistency with the order required by ST_Point().

[maxalbert]

I think at the very least we should enforce always passing lon/lat values as named keyword args.

Probably better would be to have Point or Geolocation class so that we don't need to pass the values around individually.

If this fits naturally with the spatial unit refactoring then would be great to roll it in, but also happy to keep it as a separate PR because it probably requires a lot of little changes all over the place.

[maxalbert]

Just to note that this is not just an issue within our code base - different third-party packages also use different orderings for lon/lat, so it's even more important to enforce the correct values by name and/or a dedicated object.

[jc-harrison]

Yes, I like the idea of a Point class. In the interest of keeping the spatial unit refactoring PR from getting too much larger than it's already going to be, I think it's probably best to keep this as a separate PR.