Respect text-offset in line-placed symbol collision handling

[anandthakker]

We currently do not respect the value of text-offset when determining whether two symbol instances collide.

Example -- in this style:

{
  "version": 8,
  "metadata": {
    "test": {
      "height": 64,
      "collisionDebug": true
    }
  },
  "center": [ 0, 0 ],
  "zoom": 0,
  "sources": {
    "geojson": {
      "type": "geojson",
      "data": {
        "type": "Feature",
        "properties": {},
        "geometry": {
          "type": "LineString",
          "coordinates": [
            [-20, -20],
            [20, -20],
            [20, 20],
            [-20, 20]
          ]
        }
      }
    }
  },
  "glyphs": "mapbox://fonts/mapbox/{fontstack}/{range}.pbf",
  "layers": [
    {
      "id": "guid",
      "type": "line",
      "source": "geojson"
    },
    {
      "id": "text",
      "type": "symbol",
      "source": "geojson",
      "layout": {
          "symbol-placement": "line",
          "symbol-spacing": 115,
          "text-size": 10,
          "text-allow-overlap": false,
          "text-ignore-placement": false,
          "text-field": "A",
          "text-font": [
              "Open Sans Semibold",
              "Arial Unicode MS Bold"
          ],
          "text-keep-upright": false,
          "text-offset": [0, -3]
      }
    }
  ]
}

We'd expect only one of the 'A' instances to be rendered, but both are:

[anandthakker]

The above JSON should work verbatim as an integration test -- I'm holding off on adding it because I'm not sure whether it's well defined which of those two labels should be shown.

cc @ansis @ChrisLoer

[ChrisLoer]

It's not totally ignored: it feeds into the "top" and "bottom" values of the shaped text, which feeds into CollisionFeature as the shaped parameter. For point labels, those values are fed into the single collision box, but they're essentially ignored for line labels (they feed into "height" and "width" but the offset won't make a difference).

Empirically, it's still partially broken for point labels:

Maybe something to do with boxScale being in different units then we're using at shaping time... that stuff is hard to keep track of. (Looks like it's pretty much accurate at zoom levels <n>.99, so that's a pretty good hint)

[ChrisLoer]

I've started looking at this in conjunction with #6075 (combing text-offset with text-rotate). Point placement is looking pretty straightforward, line placement may still be a bit tricky.

[ChrisLoer]

I'm going to address point-placed symbols in #6075, and leave this as the line-placed version of the bug. I started exploring an implementation, and it's tractable but a bit more than I'm ready to take on right now. Because we don't know what the offset will be until we actually project the line, we have to modify collision circles on the fly at the time we're doing projection in placeCollisionCircles. To make the collision debug shaders accurate, we'd have to implement logic similar to what the symbol shaders currently do for calculating offsets.