Introduction

Finding all latitude-longitude points within a given radius is a classic geospatial filtering problem. The standard practical solution is two-stage: first reduce the candidate set with a bounding box, then compute an accurate spherical distance such as Haversine only for the remaining candidates.

Why You Usually Need Two Steps

If you compare the target point to every stored point with a full spherical distance formula, the query becomes expensive as the dataset grows. A bounding box makes the search much cheaper by eliminating points that are obviously too far away.

So the usual algorithm is:

1. compute a bounding box around the target point
2. keep only points inside that box
3. run an exact distance formula on the survivors
4. return those within the requested radius

This scales much better than doing exact great-circle math against every row.

Haversine for Accurate Distance

The Haversine formula computes great-circle distance on a sphere and is accurate enough for many applications.

1from math import radians, sin, cos, sqrt, atan2
2
3EARTH_RADIUS_KM = 6371.0
4
5
6def haversine_km(lat1, lon1, lat2, lon2):
7    dlat = radians(lat2 - lat1)
8    dlon = radians(lon2 - lon1)
9    lat1 = radians(lat1)
10    lat2 = radians(lat2)
11
12    a = sin(dlat / 2) ** 2 + cos(lat1) * cos(lat2) * sin(dlon / 2) ** 2
13    c = 2 * atan2(sqrt(a), sqrt(1 - a))
14    return EARTH_RADIUS_KM * c
15
16
17print(haversine_km(43.6532, -79.3832, 43.7000, -79.4000))

This gives you the exact filter after the candidate set has already been reduced.

Compute a Bounding Box First

For a target point and radius, you can estimate latitude and longitude limits that form a search rectangle.

1from math import cos, radians
2
3
4def bounding_box(lat, lon, radius_km):
5    lat_delta = radius_km / 111.0
6    lon_delta = radius_km / (111.0 * cos(radians(lat)))
7
8    return (
9        lat - lat_delta,
10        lat + lat_delta,
11        lon - lon_delta,
12        lon + lon_delta,
13    )
14
15
16print(bounding_box(43.6532, -79.3832, 10))

This approximation is not the final answer, but it is very effective for prefiltering.

Full Example on an In-Memory List

Here is a complete Python example that combines both stages.

1locations = [
2    ("A", 43.6532, -79.3832),
3    ("B", 43.7000, -79.4000),
4    ("C", 43.9000, -79.7000),
5]
6
7
8def nearby_locations(center_lat, center_lon, radius_km, items):
9    min_lat, max_lat, min_lon, max_lon = bounding_box(center_lat, center_lon, radius_km)
10    result = []
11
12    for name, lat, lon in items:
13        if not (min_lat <= lat <= max_lat and min_lon <= lon <= max_lon):
14            continue
15
16        distance = haversine_km(center_lat, center_lon, lat, lon)
17        if distance <= radius_km:
18            result.append((name, round(distance, 2)))
19
20    return result
21
22
23print(nearby_locations(43.6532, -79.3832, 10, locations))

That pattern is perfectly fine for small or medium in-memory datasets.

Database Queries Need Spatial Indexes

For large datasets, the algorithm should move into the database or spatial engine rather than loading all points into application memory.

Common choices include:

• PostGIS for PostgreSQL
• MySQL spatial features
• dedicated search engines with geo queries

Even in a database, the same logic applies conceptually: use an index-friendly prefilter first, then apply exact distance checks.

For example, a SQL query often starts with latitude and longitude range filtering before applying a distance function.

Edge Cases You Should Not Ignore

There are two famous edge cases:

• points near the poles
• points near the antimeridian around +180 and -180 longitude

A naive longitude range can break when the bounding box crosses the antimeridian. In that case, the longitude filter must wrap correctly instead of assuming a simple min <= lon <= max check.

For small city-scale searches, many systems never hit this edge case. For global systems, you absolutely need to handle it.

When Euclidean Distance Is Good Enough

If all points are within a very small local region and the application does not need geographic precision, projecting coordinates into a local plane and using Euclidean distance may be acceptable.

But once the search area grows or the application spans wider geography, use spherical or ellipsoidal formulas. Do not pretend latitude and longitude are ordinary Cartesian coordinates at all scales.

Common Pitfalls

A common mistake is running Haversine against every row without any prefiltering. That becomes unnecessarily expensive on large datasets.

Another issue is using a bounding box as if it were the final answer. A box includes corner points that may still be outside the actual radius.

Developers also often forget antimeridian and polar edge cases when they generalize a local solution into a global one.

Finally, if the dataset is large, do not pull everything into memory. Use a spatial index where the data lives.

Summary

• Use a bounding box to cut down the candidate set quickly.
• Use Haversine or another geodesic formula for the exact distance check.
• For large datasets, move the query into a spatially indexed database.
• Handle antimeridian and polar edge cases if the system is global.
• Bounding-box plus exact-distance filtering is the standard practical solution.