Representing locations as a single pair of coordinates is insufficient, because it does not account for the extents of the location, which can be a building, a street, a city, an administrative division (county, state, province...) etc.
I propose we represent locations as:
- a name
- a specific point on Earth
- a radius around that point, based on the type of location (building, street, city)
- a hierarchy of administrative divisions (starting at county/parish for the US) that entirely contain the location.
For example, "Palo Alto" would be:
- 37.442156, -122.1634471
- 10km radius (city)
- Santa Clara County, California, United States
"University Ave" would be:
- 37.4466552,-122.1626787
- 500m radius (street)
- Santa Clara County, California, United States
"353 Jane Stanford Way Stanford California" would be:
- 37.4299908,-122.175519
- 100m radius (building)
- Santa Clara County, California, United States
"my current location" (assuming I'm at Gates) would be:
- 37.4299908,-122.175519
- 1m radius (GPS)
- Santa Clara County, California, United States
Two locations are ==-equal if the intersect. This should give the right semantics for location filters.
Representing locations as a single pair of coordinates is insufficient, because it does not account for the extents of the location, which can be a building, a street, a city, an administrative division (county, state, province...) etc.
I propose we represent locations as:
For example, "Palo Alto" would be:
"University Ave" would be:
"353 Jane Stanford Way Stanford California" would be:
"my current location" (assuming I'm at Gates) would be:
Two locations are
==-equal if the intersect. This should give the right semantics for location filters.