Add line-sort-key and fill-sort-key

[ahk]

This pull request adds support for two new style-spec layout properties: line-sort-key and fill-sort-key.

These properties mirror the symbol-sort-key in terms of function and allow for features of either line or fill type to specify their own sort order. Sort keys are expected to be float values in ascending order (back to front). Features with larger sort keys will be drawn in front of features with smaller sort keys.

Addition of the sort key property was motivated by cross-tile draw order issues for symbol and circle layers. line and fill do not suffer from the same cross-tile sorting issues, but these properties are still useful for designers and are supported for flexibility and consistency.

Launch Checklist

• briefly describe the changes in this PR
• write tests for all new functionality
• document any changes to public APIs
• post benchmark scores
• manually test the debug page
• tagged @mapbox/studio and/or @mapbox/maps-design if this PR includes style spec changes
• tagged @mapbox/gl-native if this PR includes shader changes or needs a native port

cc @mapbox/studio @mapbox/map-design-team @mapbox/gl-native

[ansis]

Overall this looks great! The only changes that need to be made are updating the js version number that will support this feature to 1.2.0

[ansis]

This should be 1.2.0

[ansis]

This should be 1.2.0 as well

[tmpsantos]

• tagged @mapbox/gl-native if this PR includes shader changes or needs a native port

Thanks for the heads up

[andrewharvey]

👍

Though it looks like this won't support sorting based on feature-state:

fill-sort-key: "feature-state" data expressions are not supported with layout properties.

That's okay, but it would open up more use cases of this feature in the future if it was supported.

[chloekraw]

Though it looks like this won't support sorting based on feature-state. That's okay, but it would open up more use cases of this feature in the future if it was supported.

@andrewharvey my understanding is that the limitation you describe is rooted in the fact that feature-state broadly speaking has not been extended to layout properties, as opposed to a specific choice that we made for the implementation in this pr. but let me know if I'm missing something

[andrewharvey]

👉 #8467

[shayke]

Is there a reason why feature-state is not supported?
In our case, we color line features per state and it's mandatory to sort the features per status (selected ones should be on top). Currently we solve that by separating the layer into hovered, selected, normal lines to support hover -> selected -> normal z-index which kind of defeats the purpose of feature-state anyway (since before all you could do is separate layers and apply filters).

[andrewharvey]

@shayke I believe the reason is in #8383 (comment), it's just because no one has implemented feature-state for layout properties, as far as I know. Your workaround is exactly what I would suggest.