Make collision detection take into account "text-offset" and size changes #1196
Labels
Comments
|
this case was found in https://www.mapbox.com/bites/00108, but reproducible anywhere. |
ansis
added a commit
that referenced
this issue
Feb 5, 2016
fix #1196 Symbols can size change within a single zoom level. When size changes all the units that are relative to size, like text-offset, change. Collision detection can't handle boxes that scale at different rates so we try to create a collision box that will cover the symbol at all sizes within that zoom level. It used to just use the size at z+1 with the assumption that text always increases and that the anchor is always within the collision box. This commit makes it use both the size at z and z+1 so that symbol is always within the collision box.
2 tasks
ansis
added a commit
that referenced
this issue
Feb 5, 2016
fix #1196 Symbols can size change within a single zoom level. When size changes all the units that are relative to size, like text-offset, change. Collision detection can't handle boxes that scale at different rates so we try to create a collision box that will cover the symbol at all sizes within that zoom level. It used to just use the size at z+1 with the assumption that text always increases and that the anchor is always within the collision box. This commit makes it use both the size at z and z+1 so that symbol is always within the collision box.
lucaswoj
changed the title
|
@ChrisLoer @ansis Is this fixed with recent text rendering changes? |
|
Plain offsets are handled correctly now (watch Washington DC offset in both X and Y directions):
But for zoom-interpolated values the collision box can still end up looking different than the label:
|
|
→ #4798 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the Y direction, the symbol simply outruns its bounding box. Looking at
France, going from [0,-10] to [0,0] to [0,10]:In the X direction... it's bizarre. Looks like the box both scales and shifts. Going from [-10,0] to [0,0] to [10,0]:
cc/ @ansis
The text was updated successfully, but these errors were encountered: