Style spec: add option to disable y-position sort for symbol features

[ChrisLoer]

We've automatically sorted symbols based on their projected y-position since #470 -- the reasoning was roughly (1) they're often not likely to be in any meaningful order in the source data, and (2) sorting them makes them look more visually coherent.

#4361 tracks adding a general purpose feature sorting functionality - something that would allow you to generate arbitrary sort keys via expressions.

The status quo is that non-symbol features are drawn in the order they appear in the underlying data. It can be cumbersome to maintain your data in such a way that you get the draw order you want, but for some use cases it works out pretty well. We have some users that would like to be able to use the same source-based ordering for symbols.

I think implementing this is just adding a style spec property something like symbol-sort-by-y that defaults to true. If it's false, then we just skip the y-sorting step.

/cc @lilykaiser @mapbox/maps-design @mapbox/studio

[nickidlugash]

they're often not likely to be in any meaningful order in the source data

Just want to flag that all data in Mapbox Streets Source (including for symbols) has meaningful sort order. I am pretty sure that removing the y sorting would be beneficial to our core styles (but would definitely want to visually confirm this).

I think implementing this is just adding a style spec property something like symbol-sort-by-y that defaults to true. If it's false, then we just skip the y-sorting step.

Since sorting by y-position is only beneficial for symbol layers that allow overlap, should we consider setting the default to auto, where it is true if either *-allow-overlap or *-ignore-placement is true, and false otherwise?

[ChrisLoer]

Since sorting by y-position is only beneficial for symbol layers that allow overlap, should we consider setting the default to auto, where it is true if either *-allow-overlap or *-ignore-placement is true, and false otherwise?

This is pretty much already the case: sorting only happens for symbols that can overlap with other symbols in the same layer, because otherwise sorting wouldn't make any difference. Because the core styles rarely use overlapping symbols, I think this is mostly irrelevant for them.

The tricky distinction here is that this is sorting draw order, not placement order. Placement order is always determined by the order in the data. It's also mostly orthogonal here because in the overlapping case items within a layer usually won't be colliding with each other. I think there are some edge cases with combined icon/text labels where only one of them allows overlap -- you could potentially have slightly different collision detection results than you'd get if placement order matched draw order, although you'd be hard-pressed to notice.

[1ec5]

sorting them makes them look more visually coherent

To elaborate on this point, #470 (comment) does a good job of demonstrating the single use case for y sorting: billboard-style marker icons that always depict the front of an upright object regardless of the map’s pitch. By contrast, a puck-like or non-skeuomorphic marker icon wouldn’t benefit from y sorting and might as well be sorted by source order. This distinction might be helpful to include in the symbol-sort-by-y property’s documentation.