Globe panning is reverted when North pole facing the user

[jcolot]

See video: moving the mouse on the left of the globe and to the bottom rotates the globe clockwise, unexpectedly:

Screen.Recording.2025-01-06.at.20.38.18.mov

A way to solve it would rely on something like versor (https://github.com/d3/versor), tracking the rotation with quaternions.

maplibre-gl-js version 5.0.0:

Expected Behavior

Homogenous panning all over the globe, non-blocking at the poles (for instance: https://observablehq.com/@jcolot/versor-panning)

Actual Behavior

Unexpected behaviours related to the poles

[HarelM]

I think this method was used in panTo and other programmatic movements but not with user interactions, feel free to open a PR to solve this.

[jcolot]

Reading the code, it might have been considered as a feature rather than a bug:

maplibre-gl-js/src/geo/projection/vertical_perspective_camera_helper.ts

Line 132 in d8c36bc

// We avoid using the "grab a place and move it around" approach from mercator here,

Still I think quaternion based dragging could be an option. I'll try to propose something.

[HarelM]

I wouldn't read too much into this comment. I do think the behavior is intentional in general and this this comment is there, but not the bug that is reported here, I don't think it is intentional.
I also think there's a similar bug in the southern pole, right?

[kubapelc]

Hi, I'd like to add context to that comment, since I wrote the current globe controls.

In mercator, when you click and hold the map to pan it and the move the mouse, the place you originally grabbed will always stay under the cursor, which very intuitively emulates something like grabbing a piece of paper and moving it. Same thing happens with zoom: the place under the cursor stays under the cursor while zooming in or out. Let's call this the "mercator behaviour".

And globe does actually do both these things as well! But it is only limited to relatively high zoom levels, since if you were to try these approaches at the scale of the entire planet, it would not behave very well at all. If you used mercator-like panning on a planet, you would be unable to move the map more than 90° and you would get weird speed changes based on how close to the planet's horizon you grabbed the map. You would get similarly unpleasant results with zooming. (And you would also somehow need to handle the fact that the map is a sphere in the middle of the screen and there is a lot of pixels that do not have the map under them, so it is unclear what panning or zooming on these pixels would do.)

In the end I used a very simple control scheme for the low zoom level panning: left/right moves the map east/west, up/down moves it north/south. Also the speed of these movements is roughly matched to what you would get with mercator panning, but is only determined by the zoom level, not by where you grabbed the map. This is then smoothly blended into mercator behaviour as the zoom increases.

This issue, the effect of the map moving in seemingly the opposite direction than what is should when you grab the opposing hemisphere, is a direct result of the panning only being zoom dependant at low zooms. This is not ideal, but the current solution is also very simple and works well in I think all other cases. But there might very well be a better way of doing things.

[kubapelc]

I looked at how other maps solve this and google maps in particular has a very simple and elegant solution: it just limits the view so that the user can never really see over the poles. I think that would be by far the simplest solution here as well.

[jcolot]

Yes, Google Maps limits the pitch, but Google Earth offers a more flexible way of panning, allowing to pan over the poles. Possibly there could be two modes. Looking at the code, one issue I see is that the function setLocationAtPoint is solving an equation without allowing bearing to change. This equation will often have no solution near the poles. Allowing the bearing to change allows more solutions (any point on the surface can rotated to any other point on the surface of the globe). I have a draft PR using quaternions to find those solutions. An issue is that it's a bit less precise and it fails some tests which require a precision with epsilon 10ˆ-11 while I have 10ˆ-8 precision when allowing the bearing to change with quaternions, so I'm keeping the old way of doing thing in case the bearing is kept fixed (which I keep as the default).

#5330

Behaviour on my branch:

Screen.Recording.2025-01-14.at.14.43.39.mov

[kubapelc]

I intentionally avoided changing map bearing while the user is panning the map, because I find it very confusing when maps do that. But I'm definitely not opposed to having the quaternion-based control scheme as an option, though I'm glad you want to keep the current one as default. I tried your PR and it works nicely