I have been using the Mapillary-js 4.1.2 runtime in a web page to display a map and navigate through street level imagery for some time. I use the jsdelivr version.
I mostly use default viewer constructor options, with caching enabled but with the sequence UI disabled (default is enabled, not sure if this matters). The cover is disabled too.
Not sure if this is important but the problem can happen, eg., with SF downtown imagery.
In all cases when landing, caching is performed and the spatialedges event is eventually fired with status.cached = true. This seems logicial.
However, I currently observe two issues, which I am developing below.
Very often, I get the following errors (many entries) in the Javascript console:
Origin: GraphService.ts:340
Test: Failed to cache tile data (SOME_ID). MapillaryError: Failed to fetch data
at GraphDataProvider.ts:282:22
The spatialedges event nevertheless does fire, with status.cached=true, and navigation arrows show up.
Sometimes, navigation arrows do not show up at all, when they should. In rare instances, only one faint (low opacity) arrow shows up. Recreating the viewer from scratch using the same imageId does show all arrows, however just calling viewer.moveTo() using the same id does not cure the problem, which is very problematic.
In the Network pane of Edge, I see no errors at all, just 200 status codes. Everything seems ok. Some āimages?ā¦ā graph queries return 0-byte content, but still with a 200 status code. āimages?ā¦.ā queries matching SOME_ID (as introduced above) seem to return valid content.
One thing I tried is to disable caching. This seems to solve the problem, but offers a less smooth navigation experience obviously.
Do you have any idea about could be wrong? I have a Maplibre map inset somewhere in my page that downloads coverage tiles when landing too, and this is working fine.
Thanks for reporting! I think maybe image density in the area (you mention SF downtown) could be the cause here. Can you share some image IDs where youāve experienced this behaviour in the past?
Sure, this definitely happens around image id 802941794144066, typically upon landing. It does not always happen, though, just very frequently.
Also, disabling caching only seems to solve the issue (of arrows not showing up). I canāt be sure because I have not tested enough and the API does not let me determine if arrows are indeed fully āloadedā or not (beyond the spatialedges event which does not seem to be sufficient for this purpose).
Thanks! Looks like the API requests get very close to timeout (30 seconds) in the area around that image so I can imagine that there could be situations where the requests time out and that would be the cause of the errors you see. Weāll look into optimizing this API query for areas with high image density.
Sounds good. It is true this area is very dense. I will just disable caching for now and see how it goes in the future. Thanks for your insight and quick replies.
Just as I was sending the message I did notice I also got the same warnings in the console and the same unexpected behavior (missing arrows) with caching disabled :-(.
Weāve made updates to optimize the loading experience and now the arrows load significantly faster and you should not experience missing arrows even in the most densely captured area. Let us know if you experience any more problems.
I donāt know if I have done something wrong, but the situation seems much worse than before.
I am now getting plenty of errors, such as:
Failed to cache spatial images (556151223013153). MapillaryError: 105 (MLYApiException, AAc4NZL5ā¦ā¦ā¦..auQ): The parameter image_ids must have at most 30 elements, 200 found.
Actually, I canāt get arrows to load at all in that area anymore.