Look the other way when placing icon at start of line

[1ec5]

This PR fixes a bug exposed by #1840. When an anchor is at the beginning of a line, it is coincident with its segment, resulting in an angle of 0°. In that case, consider the next segment instead.

This change also fixes a rarer bug: for some reason, clipLines() inserts a duplicate point at the beginning of the line for this way, so we must check whether the anchor is coincident with its segment; we can’t simply check whether segment is 0.

This before and after shows that all the one-way arrows are pointing the right way again. However, collision boxes aren’t being generated for the icons being placed along tile boundaries, so they tend to run right up against icons in adjacent tiles.

Fixes #2474.

/cc @nickidlugash @ansis

[friedbunny]

However, collision boxes aren’t being generated for the icons being placed along tile boundaries, so they tend to run right up against icons in adjacent tiles.

What's up with that?

[1ec5]

The same problem – an anchor coincident with its segment – is tripping up CollisionFeature::bboxifyLabel().

[1ec5]

With d9aaefd3e20065df92e0caa20249137c3a662215, there are bounding boxes, but they don’t keep the anchors from running into anchors in other tiles:

I don’t see a clear way to give each CollisionFeature enough context about surrounding tiles to keep them from colliding.

[1ec5]

Also, this line doesn’t achieve the intent of the comment above it when the tile is overscaled: “Offset the first anchor by… half the spacing if the line is continued.”

[1ec5]

Extraneous one-way arrows are now tracked in #2547.

[1ec5]

I reverted the change that added collision boxes because it introduces a latent bug: index should never be less than 0 because it’s used to index into an array. The extra collision boxes did nothing anyways, because cross-tile collision isn’t supported yet.