openstreetmap
Mapillary reintroduce filter by username
Description
In 2021 the filter by username was removed due to API changes.
- https://github.com/openstreetmap/iD/pull/8372#issuecomment-792609506
- https://github.com/openstreetmap/iD/commit/7a0d8adb7b074cbf4a40cfbfe47a3f0cfc09ddaf
Recently the API was updated and now allows to work with user data again.
- https://www.mapillary.com/developer/api-documentation?locale=de_DE
Image (…) creator - { username: string, id: string }, the username and user ID who owns and uploaded the image. Image search (…) creator_username - string, the username who owns and uploaded the image.
- Source
We should be able to show the username now as we completed a LAMA to allow this.
Looking at the API quickly, it looks like we could now use the username to request only images by this user. The previous implementation used to fetch all images and filter them in the browser AFAIR.
Screenshots
No response
Hey there, I would like to work on this issue, if you could assign me.
Feel free to work on this issue, you don't have to be assigned here to do so.
Possibly related to this API change, but since when did we lose the ability to navigate to the particular image from the Mapillary window in iD? Previously there was a username link and a date link in that window, now there is only a date (not hyperlinked) and Mapillary's copyright, which just takes to the Mapillary homepage.
Nevermind, fixed in https://github.com/openstreetmap/iD/issues/10135#
After digging into this for #10142, it turns out that the Mapillary vector tiles do not actually contain the username information, but instead only contain the user id (creator_id in the mapillary api docs). And I could not find an API endpoint to translate usernames to user ids on Mapillary's API. //cc @eneerhut: Are we overlooking something here?
As any alternative options (e.g. a "workaround" of performing dummy search images requests like https://graph.mapillary.com/images?creator_username=…&bbox=…&limit=1&fields=creator for every username typed into the filter box to get the respective id) are pretty inefficient, I would say this has to wait until Mapillary properly returns usernames as part of the vector tiles again (or provides an API to translate usernames into user ids).
@tyrasd I don't believe you're missing anything, but looping in @ptpt who implemented the changes. We're limited in what we can expose via the 3P API.
I agree the dummy search to get the username is probably more hassle than it's worth.
@tyrasd so the current setup relies on the vector tiles, yes? Hence a rework to use the api endpoint that returns GeoJSON would be too much rework? My to cents: That one would allow a per URL filter by bbox, date and username. It is limited to 2k pictures per response and it does tend to require retries in my experience, so it will require some edge case handling. The response format is also a bit different, eg. the panorama flag from the vector tiles needs to be created manually.
Correct, the current implementation is based on the coverage vector tiles. Using the /images search endpoint should indeed work, but would require reworking "significant" parts of the code. It would probably be slightly slower, but my guess is that it would be still fine.
As a side note: the username filter used to work for multiple (comma separated) usernames, which the search endpoint would not support. But I'd say we can live with that restriction.
Hey @tyrasd we don't have APIs that translate usernames -> user FBIDs. Let me discuss with the team the feasibility to add it @eneerhut
But for FBID -> username, all you need is graph.mapillary.com/<USER_FBID>
