Moving the map around generates a corner case:

The data is not present, it's as if instead of going back to the same view we're viewing different maps.

Is there a way to handle this gracefully?

Before, in OpenWISP Monitoring, the map was jailed so we couldn't move around like that, but it caused very bad UX for users in geographic locations that are very close to the world bounds (eg: Australia or Alaska) because the view would bounce from the world limit towards the center of the map.

We made a few changes in OpenWISP monitoring to deal with this:

• [change] Copy points out of world map only when needed #531 openwisp-monitoring#539
• [fix] Fixed bugs in map bounds #548 openwisp-monitoring#549
• [fix] Fixed duplication of points when map bounds are crossed #575 openwisp-monitoring#581

However, it would make a lot of sense to handle these in our library instead of having users deal with it and duplicate the same implementation many times.

I wonder if there's a better way to solve this than what we have done in OpenWISP Monitoring? I'd be super happy to find a good solution and do some clean up of the old workarounds/hacks.

Help from ChatGPT

I got the following information when I asked suggestions about this topic to chatGPT.

Map wrapping issue near ±180° longitude

When panning the map across the ±180° longitude (e.g., from Asia to the US), vector layers (e.g., nodes and links) are not visible on the wrapped side of the map, even though the base map tiles wrap correctly. This causes the illusion that the map resets or that the graph disappears when crossing the world bounds.

Cause

Leaflet does not automatically wrap vector layers (GeoJSON features, markers, etc.) across the antimeridian, unlike tile layers.

Workaround / Suggestions

• Enable worldCopyJump: true in the Leaflet map config to improve user experience when panning.
• Manually duplicate vector features by shifting longitudes ±360° and rendering them as additional layers to simulate wraparound.

function shiftLng(coord, delta) {
  return [coord[0] + delta, coord[1]];
}
// Apply to all coordinates in features and add clones at +360° and -360°

worldCopyJump

This seems to be what we need, I think it's worth a try! If this works well we can enable it by default in the geographic map.