Hi folks, wanted to highlight a new feature of the Mapillary API: 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. We are also using it in the Mapillary API demo to power the functionality of showing an image when you search for an address.
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:
Select all images within the radius
Select images that have POI in view
Select most recent images
Select 360° images
If this does not return any images do a second pass but without filter #2:
Select all images within the radius
Select most recent images
Select 360° images
If this does not return any images do a third pass but without filter #3:
Select all images within the radius
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.
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!
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.
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.
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.
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.
Having said that, a boolean