uMap Freezes when editing big >2mb OSRM-GPX traces

[skyrl69]

Describe the bug
This is maybe more an unresponsiveness behavior than a bug, literaly speaking :
When I try to edit an imported GPX trace >2mb, made with OSRM, uMap will freeze with CPU 100%. After ten seconds or so the browser signals that uMap is not responding, and ask to wait or reload the page. Depending on the size of the GPX trace, the page will recover responsiveness, or will lead to crash of the browser.

• If I reload the page, all my modifications are lost. Obviously

To Reproduce
Steps to reproduce the behavior:

1. Go to https://umap.openstreetmap.fr/en/map/anonymous-edit/1089775:BrKRjkrNd8G6w-v0AX_7Gy5G8_7TMZhDyWFF-XikqgE (french instance of umap)
   or https://umap.openstreetmap.de/en/map/anonymous-edit/63092:Rhxx1irDhFVpNx-lNetLQo5ibufeyjHXnPuczC1s0M4 (german instance)
2. Click Edit button on top right corner of the view
3. Click on Import Button : It is the last button bottom-down the right edge of the screen (an upload arrow)
4. Choose a GPX trace >2mb, computed and exported by OSRM tool (https://map.project-osrm.org/)
5. The trace is quickly added to a new layer, and shown in uMap
6. Zoom and click on that trace (left mouse button) : two small context buttons will show, a pencil and a trashbin
7. Click on edit context button (the pencil) : Instantly the page is freezing

Expected behavior
Either :

• Allow to edit the trace in matter of seconds
• Says it will take too long to make the trace editable
• Forbid point editing since the trace's too complex for edition
• Offers a way to stop entering in edition mode
• At least not freezing, or at least a way to recover unsaved data...

Desktop : Win10 x64 Brave 1.67.123 Chromium 126 x64

Screenshots of normal behavior
🆗 1) 56 nodes 2489bytes GPX

🆗 2) 1716 nodes, 62kb GPX trace from Namur to Liege

Screenshots of enhancable behavior

⚠3) 29878 nodes, 1.05mb GPX trace from Paris to Berlin
Took 70sec CPU 100% to compute ! Thread reached 1.7gb in memory heap. After that, Chrome is keeping is responsiveness

❌4) 59869 nodes, 2.00mb GPX trace from Paris to Riga, Moscow, Venise

Took 11 minutes to process, thread reached 3.5gb in memory heap
After what, UI is stalling, not responsive, objects are not shown correctly, and nothing can be done anymore until the tab is closed

a)
b)
c)
d)
ProcessExplorer :

Desktop : Win10 x64 Firefox 113 x64

❌4) Same but on Firefox (59869 nodes, 2.00mb GPX trace)

Took 16 minutes to process, thread reached 3go in memory heap
After what, Firefox is a little more responsive than Chromium, but it takes always two to five minutes for any action

a)
b)
c)
d)
ProcessExplorer :

Additional context
You'll find the GPX traces in example here in a zip file :
bug umap GPX.zip

[davidbgk]

Trying to display (and edit!) 30k+ nodes on a potentially moving map in a browser is probably a bad idea and even if it works for your configuration it might not be on another user's setup 🤷

[skyrl69]

Trying to display (and edit!) 30k+ nodes on a potentially moving map in a browser is probably a bad idea and even if it works for your configuration it might not be on another user's setup 🤷

Thanks for your input,

You're right but yet, Google Maps is doing it perfectly fine ^^
And I think the examples I brought are classic holidays / road trip itinaries...

This is in the nature of route trace to generate a lot of nodes. The 30k+ nodes is only generated with a 2 points route : Paris to Berlin. But there's a lot of turnarounds in ~1000km distance.

But right, uMap is no Gmaps : Not handling 30k+ nodes is a thing I can understand. But freezing and crashing is another matter, don't you think ?

As a workaround, I found the idea to disable interaction for the whole layer. But neverless, one cannot edit those traces, even to change their properties, since editing the trace goes to crash. The only workaround to change aspect of the trace is to set the default settings for the layer encapsulating the trace...

Regards

[davidbgk]

There are a lot of tools to simplify tracks, for instance https://opengeo.tech/gpx-simplify-optimizer/

[yohanboniface]

A few ideas:

• differentiate editing the geometry and editing the properties
• do not display that much nodes at this zoom level (no sure what kind of algo could be used here), as it's simply useless (even if the browser could handle the points, there is no way to edit a path with that much nodes close one to each other)
• split the line in multilines (if it's not yet the case), and only edit one geometry line at a time
• use canvas for vertex as low zoom levels
• do not show nodes outside of bbox (so one may zoom in and then edit)