# NEW: Radius API to find the best images near a lat/long 🎯

**URL:** <https://forum.mapillary.com/t/new-radius-api-to-find-the-best-images-near-a-lat-long/10424>\
**Category:** Mapillary integrations\
**Created:** [June 5, 2026, 7:52am UTC](https://forum.mapillary.com/t/new-radius-api-to-find-the-best-images-near-a-lat-long/10424 "2026-06-05T07:52:13Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![boris](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/boris/32/71767_2.png) [@boris](https://forum.mapillary.com/u/boris)\
**Post date:** [June 5, 2026, 7:52am UTC](https://forum.mapillary.com/t/new-radius-api-to-find-the-best-images-near-a-lat-long/10424/1 "2026-06-05T07:52:13Z")

</div>

Hi folks, wanted to highlight a new feature of the Mapillary API: [Radius search](https://www.mapillary.com/developer/api-documentation#image-radius-search).

This new API allows you to search for images near a geographic point using latitude, longitude, and a radius. By default this will return the 1 best image in a 50 meter radius. “Best” is defined as a combination of proximity to the lat/long, the recency of the image, and whether or not it is 360° (preferred). (Finding images near a point was previously possible as well, but it was more convoluted and didn’t offer best image sorting.)

##### **Parameters**

- `lat` - latitude of the center point for radius search, in degrees (-90 to 90). Must be used together with `lng`. Cannot be combined with `bbox`, `tile`, `image_ids`, `s2`, or `sequence_ids`.
- `lng` - longitude of the center point for radius search, in degrees (-180 to 180). Requires `lat`.
- `radius` - search radius in meters around the point defined by `lat` and `lng` (default: 50, max: 50). Requires both `lat` and `lng`.
- `limit` - how many images maximum you would like returned (default: 1, max: 100)

[Give it a try](https://www.mapillary.com/developer/api-documentation#image-radius-search). We are also using it in the [Mapillary API demo](https://github.com/mapillary/api-demo) to power the functionality of showing an image when you search for an address.

Cheers,

- Boris

---

<div class="post-metadata">

**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\
**Post date:** [June 5, 2026, 1:58pm UTC](https://forum.mapillary.com/t/new-radius-api-to-find-the-best-images-near-a-lat-long/10424/2 "2026-06-05T13:58:28Z")

</div>

Mapillary’s work on features is always appreciated. However, none of my test cases actually show much of an improvement in the demo. Yes, the search selects the most recent image in the proximity now but none of the images actually has the lat/lon position of interest in view, despite there are enough (potentially older but better suited) candidates. So, I think you may need to adjust the priorities filter:

1. Select all images within the radius
2. Select images that have POI in view
3. Select most recent images
4. Select 360° images

If this does not return any images do a second pass but without filter #2:

1. Select all images within the radius
2. Select most recent images
3. Select 360° images

If this does not return any images do a third pass but without filter #3:

1. Select all images within the radius
2. Select most recent images

This is just a clarifying illustration. An optimized version does not necessarily need to do multiple passes. 😉 Having said that, a boolean `prefer_360` parameter might also be useful because not all integrating apps can or want to display a 360° viewer.

---

<div class="post-metadata">

**Author:** ![boris](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/boris/32/71767_2.png) [@boris](https://forum.mapillary.com/u/boris)\
**Post date:** [June 5, 2026, 2:20pm UTC](https://forum.mapillary.com/t/new-radius-api-to-find-the-best-images-near-a-lat-long/10424/3 "2026-06-05T14:20:24Z")

</div>

Thanks for taking a look and the feedback as always @GITNE! If you want to ensure that you only get images very close to the lat/long you provide you can change the “radius” param from the default 50 to something smaller (like 20). The reason we do 50 by default is that as we know location information from GPS is imprecise, so it is hard to guarantee that images are taken exactly where they say they are.

Exposing the underlying parameters for folks to control is a good feature request for the backlog, thank you!

---

<div class="post-metadata">

**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\
**Post date:** [June 5, 2026, 2:24pm UTC](https://forum.mapillary.com/t/new-radius-api-to-find-the-best-images-near-a-lat-long/10424/4 "2026-06-05T14:24:55Z")

</div>

> [@boris](#):
>
> If you want to ensure that you only get images very close to the lat/long you provide you can change the “radius” param from the default 50 to something smaller (like 20).

I think there may be a misunderstanding here. Most people primarily want the POI in view. Recency or image freshness usually comes second. Tightening the radius will not guarantee either.

---

<div class="post-metadata">

**Author:** ![boris](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/boris/32/71767_2.png) [@boris](https://forum.mapillary.com/u/boris)\
**Post date:** [June 5, 2026, 2:45pm UTC](https://forum.mapillary.com/t/new-radius-api-to-find-the-best-images-near-a-lat-long/10424/5 "2026-06-05T14:45:56Z")

</div>

Right, there is no POI concept here though - it is just lat/long (so sometimes it’s an address, sometimes its a piece of the street, etc)

---

<div class="post-metadata">

**Author:** ![zufir](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/zufir/32/72959_2.png) [@zufir](https://forum.mapillary.com/u/zufir)\
**Post date:** [June 9, 2026, 6:43am UTC](https://forum.mapillary.com/t/new-radius-api-to-find-the-best-images-near-a-lat-long/10424/6 "2026-06-09T06:43:20Z")

</div>

I think @GITNE means that we are not interested in finding cameras that were located at the given coordinates, but we are interested in cameras that were aimed at the selected coordinates.

---

<div class="post-metadata">

**Author:** ![boris](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/boris/32/71767_2.png) [@boris](https://forum.mapillary.com/u/boris)\
**Post date:** [June 9, 2026, 8:10am UTC](https://forum.mapillary.com/t/new-radius-api-to-find-the-best-images-near-a-lat-long/10424/7 "2026-06-09T08:10:42Z")

</div>

Got it, that makes sense as a potential future feature. We are actually doing work right now to improve our computed compass angles so that we can enable this sort of thing more reliably in the future.

---

<div class="post-metadata">

**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\
**Post date:** [June 16, 2026, 7:48pm UTC](https://forum.mapillary.com/t/new-radius-api-to-find-the-best-images-near-a-lat-long/10424/8 "2026-06-16T19:48:27Z")

</div>

The new radius API basically _just_ fixes the recency issue on the server side, which is nice but not much. Clients could do the same already with a standard bbox query and by sorting images by timestamp and distance from the bbox center. So, not much improvement there. Sure, clients can also compute potential POI visibility in an image by using `computed_compass_angle` or `compass_angle`. But, it is **extremely inefficient** to do it **on a client** , especially on battery powered devices and when you consider that the server side already has all the data to do such a complex search. Searching for images with a POI in view within a certain radius is a very common need and therefore only a function that delivers this is going to add true value for users.
