Polyline annotations have miter join

[andrewstay]

Platform: iOS
Mapbox SDK version: ios-v3.4.0-beta.7

Steps to trigger behavior

1. Instantiate MGLMapView
2. Set a delegate
3. Instantiate MGLPolyline as following:

            CLLocationCoordinate2D nw = //make coordinate
            CLLocationCoordinate2D ne =  //make coordinate
            CLLocationCoordinate2D se =  //make coordinate
            CLLocationCoordinate2D sw =  //make coordinate
            CLLocationCoordinate2D points[5] = {nw, ne, se, sw, nw};
            MGLPolyline *line = [MGLPolyline polylineWithCoordinates:points count:5];

4. Add overlay to the map
5. Return 20.0f for the line width in -[MGLMapViewDelegate mapView:lineWidthForPolylineAnnotation:]

Expected behavior

Line should be either smoothly joined or the join style should be somehow exposed by SDK to the client

Actual behavior

Bad line joining

[boundsj]

Thanks @andrewstay. Can you say if there is a reason you are not using the new (in 3.4.0) runtime styling API? That API would allow you to fully control line joins, caps, etc.

[1ec5]

This seems to be a regression from v3.3.0. You can see the original behavior in #1771 (comment): not perfect in all cases, but better than what you’re seeing. See also #1734 (comment), which would’ve exposed more styling options for annotations.

As @boundsj notes, the runtime styling API provides many more styling options for polylines. That API should serve as a workaround for this issue, and indeed you may find that it better suits your needs than the annotation API.

/cc @incanus

[jmkiley]

There also seems to be an issue with the way that line ends meet with MGLPolylineFeatures, but there is a possible workaround.

Here is the code that I used: https://gist.github.com/jmkiley/7296db34d52a51f5b1b2b4ebee1e903f

The corner looks fine initially, but the line overlap becomes visible once you zoom in:

The other corners render as expected for both MGLPolylineFeature and MGLPolyline:

One potential workaround is to use a MGLPolylineFeature with MGLLineCapButt, then have the line ends meet at a straight portion of the line.

[1ec5]

Thanks @jmkiley – apparently I misread the original issue description. It looks like we automatically produce a miter join at some zoom levels but fail to do so at other zoom levels, which is surprising. Postponing to v3.5.0, because a fix would need to happen in mbgl.

[jfirebaugh]

cc @lbud @kkaefer, who were looking at line join issues recently.

[lbud]

From the core side, the failure to join endpoints here is not a bug. This is the behavior of a feature added as an MGLPolylineFeature and of its equivalent LineString added from a GeoJSON file: we don't join the beginning and end of a line, even if they are at the same point. However, if you add the same shape as an MGLPolygonFeature, or as a GeoJSON Polygon, styled as a line layer, it does join as expected, because polygons are interpreted to be closed.

Left: polygon; right: polyline:

I do find it strange that it joins smoothly when zoomed out. I assume this has to do with how we simplify GeoJSON. @mourner @jfirebaugh, I'm looking through this but can't tell for sure — would geojson-vt-cpp simplify a LineString with identical beginning and endpoints into a Polygon?

[incanus]

would geojson-vt-cpp simplify a LineString with identical beginning and endpoints into a Polygon?

No.

[jfirebaugh]

This behavior looks like a bug to me, and happens because the code decides whether or not to join the start and end point together not based on whether the feature is a LineString or Polygon in the source feature, but whether or not the geometry has coincident coordinates at the first and last position. But that condition can vary based on how the feature gets clipped across tile boundaries, which is why a LineString feature sometimes gets joined but sometimes not.

[jfirebaugh]

To clarify: Polygon (MGLPolygon) features will always render joined, and that is the recommend way to get joinless lines. The bug here is that LineString (MGLPolyline) features are sometimes joined at coincident start/end coordinates, and the expected behavior is that they never are.