Map warps to other side of the planet when map center hits antimeridian

[corepuncher]

What is the bug?

When I pan my map west to -180, instead of stopping like a wall, it flips around to the other side of the globe.

Is there a way to put the "wall" behavior back? I enjoyed that natural blocking behavior actually.

How can we reproduce it?

Unless it's something in my code specifically, just pan/fling westward beyond -180 and see what happens.

If you cannot reproduce, I'll give more info on my setup for troubleshooting.

Do you have a potential solution?

No response

Platforms

All

Severity

Minimum: Allows normal functioning

[josxha]

I'm not able to reproduce this with a normal pan gesture but with a fling gesture.

fling.bug.mp4

[JaffaKetchup]

This will occur when camera constraints are set. The end of the fling jumps past the constraints.

[JaffaKetchup]

The workaround is probably to inset the constraints a bit from the edge? But we need to look into this.

[corepuncher]

This will occur when camera constraints are set. The end of the fling jumps past the constraints.

I have no camera constraints set myself.

I see what is happening though.

Since the behavior around the international dateline has changed, my old logic no longer works.

Before: Panning map to -180 would simply stop there. I never had to deal with it.
Now: Panning across -180 flips the longitude to a positive value.

Old Logic: If map centerpoint goes EAST of -40 (or WEST of -180), I move the map to longitude -40 (or -180).

   if (newLat > globals.maxNorthBound) newLat = globals.maxNorthBound;
   if (newLat < globals.maxSouthBound) newLat = globals.maxSouthBound;
   if (newLon < globals.maxWestBound) newLon = globals.maxWestBound;
   if (newLon > globals.maxEastBound) newLon = globals.maxEastBound;


 if (newLat != position.center.latitude || newLon != position.center.longitude) {
     mapState.move(LatLng(newLat, newLon), position.zoom);
 }

But now, the map is allowed to move west of -180, to 180. My old logic sees 180 as > -40, so my logic below warps the map all the way to the other side of my domain to the east side (-40).

Any way to have a flag that puts the "barrier" at -180 back? If not, I'll have to think about how to mitigate. Perhaps if the fling stops anywhere between -180 and "a ways west" of there, snap back to -180, otherwise if they are over the Atlantic Ocean, snap back to -40, or something like that.

Using camera constraints would probably be optimal but I could never get it too "not" thrown an exceptions when changing device orientation, which many times causes it to go out of bounds.

[monsieurtanuki]

I've managed to reproduce the issue, only with camera constraints and fling gestures.

There are several points to address:

• a "standard" constraint wouldn't be enough, as we'll always end up with longitudes between -180 and 180
• the fling gesture would need to be stopped

We can disable the fling gesture "going too far" with this additional test in void _handleFlingAnimation(), before sending the "move the map" instruction to the controller:

    if ((_mapCenterStart.longitude < 0 && newCenter.longitude > 0) ||
        (_mapCenterStart.longitude > 0 && newCenter.longitude < 0)) {
      return;
    }

How should we set the "not beyond -180, not beyond +180" barrier parameter?

[JaffaKetchup]

I've also managed to reproduce a similar issue which occurs on flinging without a camera constraint. It bumps up against the edge rather than continuing the fling, then requires another gesture to break past it. I'm not sure if that changes things?

[corepuncher]

I've also managed to reproduce a similar issue which occurs on flinging without a camera constraint. It bumps up against the edge rather than continuing the fling, then requires another gesture to break past it. I'm not sure if that changes things?

That is interesting, as my map flings past 180 (also without camera constraint).