This is probably beyond what FM was designed for....BUT. Can I select records from a table based on an address field being physically closer to where the iOS device is?
I believe that you can if you have the GPS coordinates of the address and the GPS coordinates of the device, you can simply do the math ... the square root of ( (x1 - x2) ^ 2 + (y1 - y2) ^ 2 ).
That's "as the crow flies", of course.
Use the Location function for iOS devices. For street addresses, you might find a free web service you'd send the address to and retrieve the GPS via the Insert from URL script step.
(it's a big violin.)
Insert from URL, into a text field:
... then parse the <lat> and <lng> values from the response.
There's a lot of information in the response.
Google have a API called Directions that you can use for several addresses. You can then view one/more address in the same web viewer on your FileMaker layout.
After studyin' on it a bit, I find that this approach will only work in relatively small areas. That is, it wouldn't work on a global scale without modification.
As one travels towards the poles, the East-West distance between two points, represented by the "degrees longitude", gets smaller. So it gets complicated. If your scale is large - you should look into calculating "great circle" distances.
Great circle distances...
FileMaker Custom Function:DistanceBetweenPoints ( Lat1; Lon1; Lat2; Lon2; Units )
The sort answer is Yes.
Nicely put bigtom!
The long answer requires a few more details, by closer do you mean closer as the crow flies or driving/walking/public transport?
The distance custom function above is a handy tool to have if just by distance and you know the Lat Long, if you don't have the Lat Long then geocode those addresses to get the Lat/Long. If you want to do it by hand I suggest going to Google Maps and right clicking on the location and selecting "What's here", otherwise you want to 'Geocode' the address, any FREE method of Geocoding WILL get blocked if you request to many geocodes in a short period of time (Google used to be able to be pushed to give 1 Geocode per second for free), to do lots of address geocoding you will need to pay for that service and use the maps API.
I have also had varying results in the device location depending on network.
Sorting by distance will be computationally intensive because the distance needs to be unstored. Large record counts will be slow. How slow it will be and whether it's fast enough depends on the device. It may not be a problem.
Regarding the Lat-Lon, I developed a solution for which the Lat-Lon of the postcode (zip code) was sufficient. These were stored in a table and did not require a trip to a mapping app.
The computation can be done on server unless it is stand alone iOS.
I suppose you you use you post code application to narrow the calculation and reduce the record count.
It's possible to do this more efficiently than just calculating the distance to each record, and more accurately than looking up ZIP code. This blog post explains how. In summary: calculate the boundaries of a box around your location, and perform a find for coordinates in that box. (This presumes you've already geocoded all your addresses into coordinates.)
The boundary box method solves a different problem: how many records are within a set distance of the location. That's not the same as returning the closest record, or listing them in order of distance.
I'm guessing you didn't read all the way through the post. It covers finding closest records, too.
Their solution for finding the closest is to keep performing finds and making the box bigger until it hits something. How does that technique display related records in a portal?
Your message is the only one in the thread so far that mentions the word "portal"; but since you asked, you can grab the IDs from the bounding box found to set a multi-line key that's used by a portal relationship. At that point, you should have a small enough set of records in the portal that sorting on an unstored calculation of point-to-point distance shouldn't be so bad.
Alternately, you might try defining the portal relationship by the bounding box. Then you refresh the relationship with larger bounding boxes until you find enough records instead of performing finds. I haven't tested this, so I don't know how this performs relative to a find; but I'm confident it would at least be substantially faster than testing distance to a whole table of records one-by-one.
Retrieving data ...