Missing Mapillary images

[pnorman]

If I look at http://www.openstreetmap.org/edit?editor=id#map=17/48.38357/-122.33288, I see a limited number of tracks on the I 5. Looking at it on mapillary.com/map, I see several other sequences

Most of the other sequences are by myself, and are missing from iD for the I 5 between Canada and Seattle.

From mapillary/mapillary_issues#1264

[kammann]

It appears that only the first image of a sequence of images is displayed.
Example: http://www.mapillary.com/map/im/ztVkS8R9AWL41f-t54Gz-Q/map. The sequence consists of some 20 images, but https://www.openstreetmap.org/edit?editor=id#map=17/48.16850/11.53624 shows only the first image of this sequence.
Anyone able to fix this?

[pnorman]

After thought about this, it's a fundamental problem with their API (https://github.com/mapillary/mapillary_issues/issues/1264#issuecomment-145145129) where a request for a small bbox with a few pictures returns 357KB GeoJSON listing 5.7k images.

@gyllen, any eta on API changes?

[bhousel]

A lot is moving in #2720, so I wouldn't worry about this too much.

I am changing the Mapillary service to cache whatever data we request, and make it async, and break it up by actual tiles (instead of just requesting everything in the viewport bbox on every redraw event). Basically, make it work more like how we request data from the OSM API. The original Mapillary implementation was done kind of hastily, and now the streetsigns effort ended up just a copy of that, so I think we're at the point where we need to do better. And if I get this right, it paves the way for people to build other services that can be put into the Map Data panel and displayed as a data overlay (OSM Notes and QA tool results like KeepRight are two that could follow quickly).

I'm also probably going to replace the sequences api call with the one that just fetches all images - we don't have forward/backward buttons and just display everything anyway so sequences are kind of meaningless in this context. Like you said, I think the sequences api call misses a lot of images.

[pnorman]

Like you said, I think the sequences api call misses a lot of images

When I debugged the results, the Mapillary API returned a list of all the images, but something later on choked on 5k images.

[bhousel]

I'm planning to use max_results, maybe 100 per z17 tile, adjusting those numbers until it looks and performs ok. If there is a tiny cluster of 5000 images they won't all be shown, I'm ok with that.

[peterneubauer]

Any progress on this? I was not able to pinpoint the bottleneck, that's why I limited the amount of shown hits form Mapillary.

[bhousel]

As of 2729241 / #2720 this is working really well now.
iD will download all the Mapillary data it can, and will selectively show more images as you zoom in and the viewport is less cluttered.

[slhh]

It doesn't work here:
https://openstreetmap.us/iD/master/#background=Bing&map=18.56/11.58533/50.92755
iD shows one image only:

JOSM shows images everywhere:

[bhousel]

The code hasn't yet been merged to master..

[voschix]

I have just discovered this problem, using ID with Mapillary for the first time.
It puts drastic limitations on the use of Mapillary images in ID, as it makes it impossible to consult various views of the same situation. It looks to me that the culling process leaves typically the most recent pictures visible. The rest remains unreachable from ID. For my purposes (mapping details for cyclists) this makes the combination ID + Mapillary relatively useless.
To illustrate a case of extreme difference loo at this location location and the two attached screenshots.