Fix distance calculations

[Gregliest]

Currently, the app has a separate method to calculate and cache distances from the user's current location. That method doesn't seem to be getting called in the appropriate places. It also seems like a workaround for a speed issue. We can probably refactor this to work in real time and not have any syncing issues.

cc @yeahphil

[yeahphil]

We should make a lat/lon bounding box around the user and check if the reach is in that box (currently the put-in is used as the location to test). That will be a pretty cheap query and should be fine.

I took a look the other day to try and do this, and turns out it's made much trickier, b/c lat/lon are currently stored in Core Data as string, not a numeric type. So that thwarts this.

So before this can happen need to do one of: 1) migrate the Core Data model to use more appropriate types 2) add numerically typed lat/lon in addition to the attributes that are already stored for Reach. (This is an easier & more automated migration) 3) drop Core Data and replace it with some other form of local persistence.

[Gregliest]

Sounds like we should do # 2 for now. Can we have the getters lazy load the string versions if the numeric version doesn't exist? That would eliminate the syncing problem.

Also, I think it's cool to keep a radius instead of a bounding box. Obviously not a huge deal, but I'm wondering if there is a more efficient algorithm we can use to calculate all distances at once. Two quick brainstorm ideas:

• Do the calculation in a single matrix, and compare to the square distance to save a call to sqrt.
• Do the calculation in polar coordinates (although I'm not sure how expensive it is to convert to polar).

I'm happy to take a stab at the algorithm

[Gregliest]

https://github.com/AmericanWhitewater/aw-ios/pull/257 Changes where the distances are updated, which is a step in the right direction. We're planning to rip out core data, which should allow us to lazy load this calculation, which is the eventual goal.