Mapillary API: why so bad?

Mapillary API got seriously nerfed going v3->v4.

It lost filters and information, including uploader info, camera info etc.
This has caused problems for JOSM and other developers.

This is also causing problems for individual users.
As an OpenStreetMap contributor, I wanted to obtain timestamped coordinates of all my images in a bbox, taken with a particular camera.

It does not seem to be possible. Requests cannot filter on user or camera anymore, that information is not returned for any post-processing either.

Mapillary seems to have ignored all feedback on the API becoming so bad.

Why is the API so bad now?

2 Likes

I guess this affects the level of trust :slight_smile:

1 Like

Thanks for the feedback @Richlv. V4 was developed to support Mapillary’s transition to Facebook infrastructure. Your feedback is super valuable as we think about future updates to the API now that these major backend changes are behind us.

Your feedback and @trekview’s are really helpful and we appreciate you taking the time to share it. We’ll report back and balance any API changes with the other exciting things on our roadmap.

2 Likes

Thank you for the reply Edoardo, truly appreciated.
I guess you can see the concerns this raises - it’s difficult to trust a solution if such major features can be removed and all reports completely ignored for a long time.

Understandably, this is in no way something the community would blame on you personally, knowing your major contributions and efforts to improve Mapillary. For all we know, you could be held hostage, with somebody giving you corporate response to post, while mumbling “we intentionally made API bad for nefarious reasons, and we do not intend to fix it, ever” :slight_smile:

@Richlv I can put some time into helping both with the docs and with the API capabilities. Can you give me a list, as long as you have time for, of operations you’d like to do but which you cannot do with API v4?

Then I can see if I can either see A) yes you can actually do this, but the documentation needs to be clear on how or B) yes we can add this functionality or in a hopefully rare case C) something limits this from happening and I can explain why

What I would hope to see is a set of examples to go with the documentation, the way something like MapLibre does and even our MapillaryJS library does. Code examples do exist in the current docs which I added awhile back, but a compendium of examples in other APIs and libraries has always helped me a lot, so I think the same is good for Mapillary

We are definitely interested in improving here

2 Likes

Extremely happy to hear that, thank you guys.
Things I’ve desperately missed as an OSM contributor:

a) Return user for images/sequences.
b) Return camera info for images/sequences.
c) Allow filtering by user for images/sequences.
d) Allow filtering by camera for images/sequences.

The filtering theoretically can be performed clientside, but sometimes I want to grab all my images with a particular camera in some region, and that would likely not succeed because of the max 2000 image limit:
“limit - int: the maximum number of image entities to return. Max and default is 2000.”

If you’re interested in additional feedback, it would be great to check with the JOSM Mapillary plugin maintainer - they have used your API much more and might have seen additional usecases.

Examples sounds like a great idea - if you’re also interested in “anything that’s maintained”, there’s a simple script at perlscripts/mapillary_to_gpx.pl at master · richlv/perlscripts · GitHub .

1 Like