[core] Add support for data-driven styling

[jfirebaugh]

Core implementation of data-driven styling. Now needs SDK bindings.

Fixes #4860.
Fixes #6518.

[mention-bot]

@jfirebaugh, thanks for your PR! By analyzing this pull request, we identified @yhahn, @mollymerp and @ansis to be potential reviewers.

[jfirebaugh]

@brunoabinader Did you say you were able to reproduce the mysterious valgrind errors (Assertion 'tres.status == VexTransOK' failed.)? I haven't been able to reproduce them in my Ubuntu 14.04 VM.

[brunoabinader]

@jfirebaugh not that I remember of e.g. running the unit tests from this branch using valgrind 3.12.0 on my Linux Desktop (Ubuntu 16.04) it passed through w/ only minor suppressions from the NVIDIA GL driver.

[ivovandongen]

@jfirebaugh While implementing some examples for Android, I noticed that the source functions seem to have some caching issues:

This is on a fill layer with a categorical source function with three stops:

• Jordaan, rgba(0, 0, 1, 1)
• Prinseneiland, rgba(0, 1, 0, 1)
• Westerpark, rgba(1, 0, 0, 1)]]

Similar behaviour on the examples for exponential and interval source functions.

[jfirebaugh]

@ivovandongen Should be fixed in the latest push.

[ivovandongen]

@jfirebaugh Thanks for merging in #7752. Two things that I wanted to verify are not in this version yet:

• Exponential Functions: colorSpace
• Categorical Functions: default value

Both, I couldn't find in the conversion templates

@tobrun / @zugaldia Would you mind reviewing here instead of in #7752?

[jfirebaugh]

Yeah, go ahead and add it to the API. I'll probably be adding style spec support this week or next.

[ivovandongen]

@jfirebaugh I've added a commit for the default value conversion and squashed the android api + unit tests into the android commit.

Besides that, I've fixed up some issues from a recent rebase for the android side of things, but I think there are still some issues on the iOS side and with the codestyle script; it generates a lot of new files ending in " when running make codestyle cc @kkaefer

[jfirebaugh]

@ivovandongen Could you do a pass over the Android SDK to update it for 744487194e79badc91531ac31c11a0a7cf7c67fb (native counterpart of mapbox/mapbox-gl-js#4175)? Basically, the default value moved from being a member of CategoricalStops up to a property of SourceFunction and CompositeFunction.

[ivovandongen]

@jfirebaugh Worked in defaultValue for composite and source functions. Assuming CI clears, Android is good to go.

[albanm]

Hello,

I only read about IOS and android support, is data-driven styling available for node version too ?

I have a property based exponential function for a fill-color style that doesn't seem to work, but I am not sure if it is supposed to work.

[kkaefer]

@albanm data-driven styling is a feature of the renderer and stylesheet format. This is shared across all platforms, so you can use a stylesheet that uses data-driven styling with the Node.js bindings as well. The mentions of iOS/Android are specific to runtime styling support for data-driven styling. The Node.js bindings never had runtime-styling, so it doesn't apply to them.

[albanm]

@kkaefer Ok, thanks for the quick and clear reply !

[1ec5]

The Node.js bindings never had runtime-styling, so it doesn't apply to them.

Basic runtime styling support was added to the Node module in #5318, but it doesn’t include property functions. You can set property functions via style JSON but can’t yet manipulate them via the runtime styling API. #8495 tracks the remaining work.