Mapillary nodes overwhelm Rapid

[VLD280]

Description

Turning on Mapillary traces in area with lots of mapillary data completely locks up Rapid. I turned on the traces at a zoom ~15-16 and I cannot zoom or pan at all. I unchecked the mapillary traces in the map data, but they will not de-render from the map. any action in the menu/toolbar is very laggy, and changing background imagery or map data selection has no affect on the view. I was using Mesa County 2024 imagery as my background. Refreshing the page did resolve the issue, as it automatically returned to the default map data selections, but the whole page took a long time to reload and was very laggy for several minutes after it loaded.

Screenshots

Version

2.4.0-pre.0

What browser are you seeing the problem on? What version are you running?

Firefox v130.0

The OS you're using

mac

Steps to reproduce

1. Find an area like Grand Junction, CO with dense Mapillary data.
2. Zoom in to a higher zoom level (~17-18)
3. turn on mappillary traces in the map data menu
4. Zoom out to a lower zoom level (~15-16)
5. try to pan
6. try to unselect mapillary traces

The browser URL at the time you encountered the bug

https://rapideditor.org/canary#map=15.92/39.0722/-108.5574&background=MCGIS-County-Valleywide-Imagery-2024&datasets=fbRoads,msBuildings&disable_features=boundaries&photo_overlay=mapillary

The auto-detected useragent string for your browser (leave blank if you're manually filling this form out)

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:130.0) Gecko/20100101 Firefox/130.0

[bhousel]

Yes, there are definitely places where you can ask Rapid to show a silly amount of data and it will get overwhelmed. This is #557.

Most places don't have anywhere near this much data, so scrolling around at zoom 15 works fine.

[VLD280]

Glad to hear it is an edge case. I know other tools like Overpass Turbo will give you a warning when you try to query/display potentially problematic amounts of data. Maybe a feature like that could be used to prevent a user from accidentally locking up their instance.

[bhousel]

Yep, part of the issue is that we really don't know how much data the user will be shown until we start fetching it, and also we really don't know how well the user's GPU will handle the data until we start trying to render things and then measure how bad it's struggling.

This is one way that Rapid is kind of a special kind of application. Most apps built with WebGL and Pixi.js are browser-based games, where the developers have more control how much detail the scene contains.

[VLD280]

That is a tricky issue. It looks like Mapillary solves this in their viewer by only rendering the traces, not the nodes, until you zoom in much further (Z16). Maybe something similar could be done here?

[eneerhut]

Yes that's exactly right @VLD280. I'll talk to the Mapillary team about the default API response. Maybe Mapillary could be more opinionated about what is shown if an area has a lot of imagery. E.g. show only 360º images >x date. The user would be able to view additional imagery if they wanted to with the client making further API calls to retrieve the data.