Master ticket for remaining data-driven style properties

[jfirebaugh]

Property	Status
text-translate	#2731. High priority.
circle-translate	#2731. Medium priority.
circle-translate-anchor	#2731. Medium priority.
line-gradient	#8977. Medium priority.
fill-translate	#2731. Low priority.
fill-translate-anchor	#2731. Low priority.
line-translate	#2731. Low priority.
line-translate-anchor	#2731. Low priority.
icon-translate	#2731. Low priority.
icon-translate-anchor	#2731. Low priority.
text-translate-anchor	#2731. Low priority.
fill-extrusion-translate	#2731. Low priority.
fill-extrusion-translate-anchor	#2731. Low priority.
symbol-placement	Not ticketed. Needed for Mapbox Streets. Needs investigation of feasibility.
symbol-spacing	Not ticketed. Needed for Mapbox Streets. Needs investigation of feasibility.
text-optional	#8454
icon-optional	#8454
symbol-avoid-edges	Not ticketed. Needs compelling use cases / investigation of feasibility.
icon-allow-overlap	#8454
icon-ignore-placement	#8454
icon-rotation-alignment	Not ticketed. Needs compelling use cases / investigation of feasibility.
icon-text-fit	Not ticketed. Needs compelling use cases / investigation of feasibility.
icon-text-fit-padding	Not ticketed. Needs compelling use cases / investigation of feasibility.
icon-padding	#8454
icon-keep-upright	Not ticketed. Needs compelling use cases / investigation of feasibility.
text-pitch-alignment	Not ticketed. Needs compelling use cases / investigation of feasibility.
text-rotation-alignment	Not ticketed. Needs compelling use cases / investigation of feasibility.
text-max-angle	Not ticketed. Needs compelling use cases / investigation of feasibility.
text-padding	#8454
text-keep-upright	Not ticketed. Needs compelling use cases / investigation of feasibility.
text-allow-overlap	#8454
text-ignore-placement	#8454
circle-pitch-scale	Not ticketed. Needs compelling use cases / investigation of feasibility.
fill-antialias	Not ticketed. Lowest priority; we are considering removing support for this property (#4093).
line-miter-limit	Not ticketed. Lowest priority; we are considering removing support for this property (#4092).
line-round-limit	Not ticketed. Lowest priority; we are considering removing support for this property (#4092).
fill-extrusion-opacity	No planned support; prototyped in #9562.
visibility	No planned support; use a data or composite expression for filter instead.

---

Implemented:

Property	Status
line-dasharray	#3045. Implemented in #10591.
line-cap	#3045. Implemented in #10591.
text-line-height	Implemented in #10612
text-offset	#4435. Implemented in #4495 / mapbox/mapbox-gl-native#8539.
icon-image	#4304. Implemented in #4525 / mapbox/mapbox-gl-native#8592.
text-rotate	#3516. Implemented in #4521 / mapbox/mapbox-gl-native#8590.
icon-size	#4228. Implemented in #4455 / mapbox/mapbox-gl-native#8593.
text-size	#4228. Implemented in #4455 / mapbox/mapbox-gl-native#8593.
line-width	#3045. Implemented in #4773 / mapbox/mapbox-gl-native#9214
line-join	Implemented in #5020 / mapbox/mapbox-gl-native#9583
text-anchor	Implemented in #4997 / mapbox/mapbox-gl-native#9583
text-justify	Implemented in #5000 / mapbox/mapbox-gl-native#9583
text-max-width	JS, Native
text-letter-spacing	JS, Native
text-font	#5568. JS, Native
fill-pattern	#2732. JS, Native
line-pattern	#2732. JS, Native
fill-extrusion-pattern	#2732. JS, Native

[nickidlugash]

visibility #4288. Needs discussion; overlaps with filters; we may elect to satisfy the use case via other features.

I'm not sure how useful DDS visibility is (also, the Studio UI for visibility is a show/hide toggle in the layer list, which wouldn't be compatible with function values), but the other two properties in #4288 – minzoom and maxzoom – would be really useful.

[lbud]

line-dasharray #3045. High priority; high difficulty. Perhaps not feasible to support.

Curious — I know line-dasharray and line-width were grouped together in a high priority ticket and I assume that's because of the implementation quirks that tie them together, but in my understanding line-width was higher priority — is line-dasharray still high-priority?

[nickidlugash]

As we've started making more concrete plans/timelines for core style refactors, I just wanted to flag again the list of properties that we'll need implemented in order to do these refactors (they are already indicated in the list above as either "high priority" or "needed for Mapbox Streets"):

• line-dasharray
• line-cap
• line-join
• text-letter-spacing implemented in js
• text-anchor
• text-justify
• text-max-width implemented in js
• symbol-placement
• symbol-spacing
• minzoom/maxzoom (or would expressions in filter enable the same functionality?)

It looks like many of these have not yet been reviewed for feasibility. Would it be possible to get a review of these so we can plan accordingly for our styles? No single property is a complete blocker for style refactoring, but it would be helpful if we could have as many implemented as possible.

/cc @mapbox/gl-core @ian29

[nickidlugash]

Update: @ChrisLoer is helping me work through all the remaining symbol properties needed for core styles (see comment above). PR is up for text-anchor (#4997). We're expecting that text-justify, text-max-width, text-line-height, and text-letter-spacing will be straightforward.

symbol-placement and symbol-spacing seem like they may be tricky (symbol-placement because it affects a lot of the symbols code, and symbol-spacing because it requires symbol-placement). @anandthakker @ansis do you have any thoughts on the feasibility/difficulty of implementing these?

minzoom/maxzoom (or would expressions in filter enable the same functionality?)

@anandthakker Do you know the answer to this question? ^ If the answer is "yes", then would you suggest that we don't implement minzoom/maxzoom as DDS?

@lbud how difficult do you think it would be to implement the remaining line properties needed for core styles (line-dasharry, line-cap and line-join)?

[anandthakker]

minzoom/maxzoom (or would expressions in filter enable the same functionality?)

We haven't fleshed out all the details of using expressions in filters, but as of now I do believe expression-powered filters would allow for filtering features based on both zoom level and property data.

[ansis]

symbol-placement and symbol-spacing seem like they may be tricky (symbol-placement because it affects a lot of the symbols code, and symbol-spacing because it requires symbol-placement). @anandthakker @ansis do you have any thoughts on the feasibility/difficulty of implementing these?

Yeah, this would be hard. All the -rotation-alignment and -pitch-alignment properties would also be hard. This would require changing the shaders to support both paths. I think it's feasible, but a pretty deep change. symbol-spacing seems like it should be easier though.

[lbud]

@lbud how difficult do you think it would be to implement the remaining line properties needed for core styles (line-dasharry, line-cap and line-join)?

🕵️‍♀️

[nickidlugash]

Yeah, this would be hard. All the -rotation-alignment and -pitch-alignment properties would also be hard.

Re: symbol-placement: I originally thought it would be useful in the core styles to combine point and line labels, but this ability doesn't affect many features, so it's not very pressing. I've crossed it off the core styles refactor checklist for now.

[asheemmamoowala]

Updated OP for text-max-width and text-letter-spacing. Native implementation landed in: mapbox/mapbox-gl-native#9870

[nickidlugash]

@jfirebaugh can you elaborate on this status for text-font?:

No planned support; not feasible due to implementation constraints.

Is this referring to the limited number of fontstacks that can be used in a style in a performant way? And/or other constraints?

[jfirebaugh]

One of the constraints is being lifted with the introduction of per-tile glyph atlases. The other constraint is due to offline -- in order to store glyphs offline, we need to be able to statically determine what all the possible font stacks are. If text-font was data-driven, then its value could be an identity property function, and this would not be possible. (Similar to mapbox/mapbox-gl-native#9939.)

[nickidlugash]

@jfirebaugh gotcha, thanks. Commented here mapbox/mapbox-gl-native#9939 (comment)

[ericjames]

When will circle-translate be implemented? I could have multiple circles at the same coordinate and would like to set a property in the event they overlap. The getaround right now would be to create a new layer and thus paint style for each overlap.

[nickidlugash]

According to the this ticket, we have not yet reviewed the feasibility of adding DDS support for symbol-placement. Can we review this?

In our Mapbox Streets vector tiles, we have some label data layers that contain both line and point features, and we often style both geometry types very similarly (WRT filtering, text-size, text-color, etc). It would be helpful if we could style all these features in one style layer, and as far as I can tell, the lack of DDS support for symbol-placement is the only major blocker.

[joedjc]

We'd also like to see the 'symbol-spacing' property enabled. Our use case is we can use expressions to create spacing in real world units (e.g. meters). In theory this might allow us to set the spacing of icons in meters...such as a line of trees which are 10m apart.

[henrinormak]

Looking at the list, I don't see line-gradient in either section, is that something that is planned to get data-driven styling support? Use case is for the features on a layer to dictate the colours of the gradient. A workaround sort of exists where the client creates layer per feature manually, but that seems wasteful.