[iOS] visibleCoordinateBounds inaccurate when longitude discontinuity around +/-180 is visible on screen

[pietrasm]

Hello,

It seems like visibleCoordinateBounds returns longitude range of -180 degrees to 180 degrees whenever the longitude discontinuity around +/-180 is visible on screen.

Do you have any plans on handling this corner case?

SDK version: 3.2.0rc-1

Thanks,
Michal

[1ec5]

This code should be removed, because a constrain mode of HeightOnly no longer allows world wrapping (#4655).

[1ec5]

There is some question as to what we should return in that case. We could return unwrapped coordinates, in which case you’d see the bounds extend beyond ±180° longitude, but that may be a breaking change: for compatibility with MapKit, this API has always used wrapped longitudes.

[pietrasm]

MapKit returns a single point and size which avoids the issue by design and I think that's the cleanest way of doing it. I think the least breaking change to the current API would be to return wrapped coordinates. For example, if the area begins from 10 degres to the West from the discontinuity and ends at 10 degrees to the East you can return visibleCoordinateBounds.sw.longitude == +170.0 and visibleCoordinateBounds.ne.longitude == -170.0. It still might be a breaking change as there might be expectation that visibleCoordinateBounds.sw.longitude < visibleCoordinateBounds.ne.longitude but it also would be a good indication that the area contains +/-180 longitude. Another idea would be to return two rectangles - one to the left of discontinuity and one to the right.

[1ec5]

For example, if the area begins from 10 degres to the West from the discontinuity and ends at 10 degrees to the East you can return visibleCoordinateBounds.sw.longitude == +170.0 and visibleCoordinateBounds.ne.longitude == -170.0. It still might be a breaking change as there might be expectation that visibleCoordinateBounds.sw.longitude < visibleCoordinateBounds.ne.longitude but it also would be a good indication that the area contains +/-180 longitude.

I like both these ideas. We could have visibleCoordinateBounds.sw.longitude < visibleCoordinateBounds.ne.longitude for now. (That change would not be a breaking change because we don’t currently document the behavior when straddling the antimeridian.) When we’re ready for a major version bump, we can then change it to visibleCoordinateBounds.sw.longitude == +170.0 and visibleCoordinateBounds.ne.longitude == -170.0.

[pietrasm]

Sounds good, thanks a lot. I would really appreciate it. Just to clarify, this change will make it possible that visibleCoordinateBounds.sw.longitude > visibleCoordinateBounds.ne.longitude, not the other way around.

[1ec5]

To recap, there are two main ways of indicating that a bounding box straddles the antimeridian:

• The southeast coordinate’s longitude is greater than the northwest coordinate’s longitude. The Android map SDK took this approach in bounds can go over the antimeridian / date line. #10892. This approach doesn’t work for shapes, because a line segment can travel in either direction across the antimeridian.
• The southeast coordinate’s longitude is less than −180° or the northwest coordinate’s longitude is greater than 180°. This same approach also works for arbitrary shapes.

for compatibility with MapKit, this API has always used wrapped longitudes

This changed in #6088: the way to make a shape cross the antimeridian is to have one or more vertices lie beyond ±180° longitude. For consistency, you can also set visibleCoordinateBounds to a coordinate bounds that extends beyond ±180° longitude to put the center coordinate somewhere near the antimeridian (#9731, #9804).

The last remaining piece is to have -[MGLMapView convertRect:toCoordinateBoundsFromView:] and the visibleCoordinateBounds getter return a meaningful bounds that somehow indicates it straddles the antimeridian. #11265 does this by returning a bounds in which one side has a longitude greater than or less than 180°.

[1ec5]

Fixed in #11265, which will is in the release-boba branch for iOS SDK v4.0.0 / macOS SDK v0.7.0.