label layer priority order

[ansis]

The list of layers in the style is bottom up. The last layer is drawn above the first layer.

Currently labels in earlier layers will block labels in later layers. This seems weird considering earlier layers are below later layers.

Should we make later layers block labels in earlier ones?

The order isn't specified in the spec but this styles would still need to be migrated.

[ansis]

I talked with @nickidlugash and @peterqliu and they agree that we should reverse the order that labels are placed. This would mean that labels that are more important would come later in the style sheet. For example, country labels would come after road labels.

@jfirebaugh does adding this to v8 sound ok?

To migrate, all symbol layers would need to be reversed. This wouldn't work perfectly if a symbol layer is between two non-symbol layers, but I don't think we have any of those in real styles.

[jfirebaugh]

Adding this to v8 sounds good to me.

[peterqliu]

This wouldn't work perfectly if a symbol layer is between two non-symbol layers, but I don't think we have any of those in real styles.

It's currently used in Emerald for state labels, but those are meant to be in the background and obstructed if necessary

[jfirebaugh]

Removing from v8; not critical to shipping /app.

[ansis]

-js implementation: https://github.com/mapbox/mapbox-gl-js/tree/v8-label-priority
migration script: https://github.com/mapbox/mapbox-gl-style-spec/tree/v8-label-priority
test-suite: https://github.com/mapbox/mapbox-gl-test-suite/tree/v8-label-priority

Migration script was tested against mapbox-gl-styles and everything looks good.

I think it would be good to get this for v8 because it's a breaking change. For each symbol layer we can either preserve it's priority related to other label layers or it's draw order. Not both. The migration script chooses the right thing to preserve in all the example styles, but there may be unintended effects. It might be good to make the change before we have more user styles to migrate.

Should I double check and merge tomorrow, or should this wait for after v8?

[jfirebaugh]

/cc @mapbox/appbox -- thoughts on whether this should be in v8?

[nickidlugash]

This wouldn't work perfectly if a symbol layer is between two non-symbol layers, but I don't think we have any of those in real styles.

@ansis can you say a bit more about what wouldn't work perfectly? Is this just in relation to migrating styles, or in general? Although rare, I think there is definitely a use case for sandwiching symbols between non-symbols, e.g. placing oneway arrows between tunnel/road/bridge layers, so that the arrows are properly obscured if there is a road or bridge going over the oneway road. However, it seems like flipping the label layer priority order would actually help in this case and in most similar cases, because if you're drawing a label layer that can be obscured by geometry, then it's more likely that you want that layer to have a lower priority. Right now the only reason we don't place the oneway arrows between the road geometry layers is because we don't want them to have the highest priority, and so this implementation might allow us to do it.

[ansis]

Is this just in relation to migrating styles, or in general?

In relation to migrating styles. In general some things won't be possible but other new things will be possible. Before, sandwiched layers had higher priority than all the label layers on top of the map. After this, sandwiched layers will have lower priority than the label layers on top of the map.

Flipping the order will let oneway arrows be sandwiched and lower priority than most label layers.

The migration will preserve priority for all the regular label layers on top of the map, and it will preserve the position of sandwiched layers. It will only change the priority of sandwiched layers. I think all the sandwiched layers in mapbox-gl-styles don't actually use collision prevention, so this shouldn't break anything.

There is one theoretical case that would break: a sandwiched layer that used collision detection and was intended to be higher priority. It would be lower priority after the migration.

[jfirebaugh]

We decided to include this in v8.