Repository navigation
Map pitch not accounted for in text orientation #4376
Description
From @ajashton #3057 (comment):
Noting that one specific aspect of this is that perspective is not accounted for in text orientation. If you look at this JSFiddle First, 2nd, & 3rd Streets should be rotated 180° to be closer to "upright", but if you change the pitch to 0 the same orientation is correct.
Metadata
Metadata
Assignees
Labels
No labels
Activity
nickidlugash commentedon Mar 27, 2017
@ChrisLoer We haven't yet discussed this issue, but this may (or may not) be something worth thinking about in conjunction with other pitched label rendering refactors.
Right now if text is kept upright, we calculate which orientation of glyphs we should not add to symbol arrays based on the angle of the glyph, but this doesn't account for how the final angle may change based on pitch.
I'm not sure how vertical text is affected – this issue is not as evident in vertical-enabled line labels, but that may just be because there are four possible orientations so the flip between orientations is more subtle and an "incorrect" orientation is not as suboptimal.
ChrisLoer commentedon Mar 27, 2017
Hmm, interesting -- yeah, this is something we could tackle at the same time.
This is another case where doing the fully correct solution at high speed requires sending a lot more information down to the GPU. Consider these two views of 15 St NW:
Panned to lower left
Panned to lower right
Both views came from a map at the same pitch/angle/zoom: the only difference was panning left and right.
We could calculate the right glyph to show in the SDF vertex shader, but we'd have to send down two copies of each glyph (one "upside down" copy). Alternatively, we can try to do this calculation at placement time and re-trigger placement whenever there's a pan operation. It would take a little longer for labels to flip to the right orientation, and it would add CPU intensity.
ChrisLoer commentedon Mar 28, 2017
From discussion with @lucaswoj , there are two issues here that aren't accounted for by
text-pitch-alignment:ChrisLoer commentedon Apr 25, 2017
There's a closely related problem: collision tiles also don't account for the parallax effect, with the result that you can start to get collisions near the right and left sides of the screen. Check out "Riviera Country Club" in this screenshot:
The collision logic is separate from the text orientation logic, but the shape of the problem is the same: we need to (1) account for perspective at placement time, and (2) periodically re-do placement to account for perspective changes.
ChrisLoer commentedon Jun 3, 2017
#4781 should address this!
ChrisLoer commentedon Jun 19, 2017
Fixed with #4781 (although not the collision issue mentioned in #4376 (comment))