Point-radius bounding box

Enter decimal-degree latitude and longitude for the center, plus a non-negative radius in meters; the tool returns min_lat, max_lat, min_lon, max_lon, a GeoJSON-style bbox array [west, south, east, north], angular latitude offset, and step-by-step notes for the mean-Earth spherical model. Negative radius values are rejected with invalid_input so callers never ship an inverted or meaningless search window.

What a point-radius bounding box is and when you need one

When the raw west or east edge crosses the antimeridian, longitudes are normalized into the closed interval from minus one hundred eighty to plus one hundred eighty and a flag marks that min_lon may be greater than max_lon after wrap—the classic antimeridian case map libraries already handle.

How to call the API and what comes back

Absolute latitude and longitude outside those closed ranges fail validation before any trig runs. Send a JSON body with three required finite numbers: lat (aliases latitude and center_lat) in degrees from minus ninety to ninety, lon (aliases longitude, lng, and center_lon) in degrees from minus one hundred eighty to one hundred eighty, and radius (aliases radius_m and r) in meters, non-negative and not larger than half the Earth circumference. On success the response echoes rounded lat, lon, and radius_m; sets earth_radius_m to the constant 6371000; sets delta_lat_deg to the latitude half-width in degrees; sets min_lat, max_lat, min_lon, and max_lon for the enclosing box; sets bbox to the four-tuple min_lon, min_lat, max_lon, max_lat in west-south-east-north order; sets full_longitude and crosses_antimeridian booleans; sets message to a short English summary; and sets steps to an ordered array of derivation lines you can show in logs or UI. Failed validation—missing fields, non-finite numbers, latitude or longitude out of range, negative radius, or an oversized radius—returns invalid_input and is never charged. Pricing is a flat $0.002 per successful request with unit item and zero marginal unit price.

Practical tips, limits, and related searches

Keep the center inside published latitude and longitude ranges; do not send web-mercator or projected coordinates. Remember that an axis-aligned degree box is a prefilter: points in the corners of the rectangle can be farther than the radius from the center, so refine with haversine or geodesic distance if you need a hard circular cut. Prefer this capability when you already have a center and meters and only need the rectangular envelope; if your source is a polygon or multi-point set, compute a true multipoint bbox instead. Prefer meters for radius so clients do not mix kilometers and statute miles; convert kilometers by multiplying by one thousand before the call. Near the poles expect full_longitude true for modest radii because longitude degrees shrink to zero meters. For Pacific-centered queries near the antimeridian, check crosses_antimeridian and split the query into two longitude intervals when your database cannot express a wrapped range. Pair examples: New York at about 40.71 latitude and minus 74.01 longitude with a five-kilometer radius for a city-scale store search; a zero-radius call that returns equal min and max to the center; and a deliberately negative radius that demonstrates the hard invalid_input path. This landing targets people searching for a point radius bounding box, lat lon min max from radius, or geofence envelope calculator; it is not a great-circle distance tool, not a geohash encoder, and not a polygon buffer. Failed tasks that return invalid_input do not consume prepaid balance, which keeps exploratory scripts cheap when learners deliberately send negative radii. Round-trip checks are easy: for mid-latitudes recompute delta latitude as radius over R times one hundred eighty over pi and confirm min_lat and max_lat match within the published twelve-decimal rounding.