Incorrect bounding box for polylines across the antimeridian

[invliD]

Platform: iOS
Mapbox SDK version: 3.7.5

Steps to trigger behavior

1. Render a MapView
2. Add an MGLPolyline with (at least) two points around the antimeridian.
3. Center the polyline using mapView.setVisibleCoordinateBounds(line.overlayBounds, …) or mapView.showAnnotations([line], …).

Expected behavior

The map is centered around the line with its entire length in view

Actual behavior

The map shows as much of the world as possible with the current aspect ratio, splitting the line in two.
See screenshot of a geodesic line from San Francisco to Shanghai:

Additional information

MGLPolyline does not have its own implementation for overlayBounds, it falls back to MGLMultiPoint's. That implementation goes through all points and figures out the bounding box by min/maxing the next point's lat/long with the current bounds. This is not an unreasonable implementation as multiple points don't have any clear structure to them. It is, however, debatable whether the bounds of (0,179) and (0,-179) should actually be longitudes 179 to 181 instead of -179 to 179.
In an MGLPolyline, points actually have a structure, so I claim this behavior is definitely unexpected and unwanted most of the time.

An additional problem in the current implementation of overlayBounds is the fact that it returns an "empty" bounding box if a point is "invalid" (e.g. abs(longitude) > 180). Since using longitudes > 180 or < -180 is the mechanism to render lines across the antimeridian, all such lines will produce an incorrect bounding box.

[fabian-guerra]

Hi, @invliD. Thank you for using Mapbox. Please refer to the documentation to learn how to use coordinates that straddle the antimeridian.

[invliD]

I know how I could achieve this myself. This issue is about the unexpected/broken behavior of overlayBounds. It doesn’t even return a valid bounding box for any line that crosses the antimeridian.

[fabian-guerra]

Hi, @invliD. Thank you for the follow up and clarification. I am reopening this ticket.

[1ec5]

The fix is to apply a solution similar to #11265 in the overlayBounds property’s implementation.

[fabian-guerra]

Fixed in #11783