Add line-gradient property #6303

lbud · 2018-03-08T22:35:29Z

This PR adds support for gradient lines, with the following limitations:

line-gradient can only be used for lines with GeoJSON sources
- the GeoJSON source used for these lines must specify the "lineMetrics": true option
line-gradient cannot be used in conjunction with line-dasharray or line-pattern
like heatmap-color, line-gradient must be specified using an expression with a special line-progress property: for example,

"line-gradient": [
    "interpolate",
    ["linear"],
    ["line-progress"],
    0, "rgba(0, 0, 255, 0.5)",
    0.5, "red",
    1, "#ffff00"
]

Overview of changes:

Adds a lineMetrics option to GeoJSON sources, which is passed through to geojson-vt in order to track distance metrics for linestring features
Adds a line-gradient line paint property, which specifies a gradient and is used in the same way heatmap-color is used to write a 256x1px texture containing the gradient
- Changes HeatmapColorProperty to ColorRampProperty to be used for both, and abstracts color ramp image creation into a utility module for use in both
LineBucket:
- checks for the presence of mapbox_clip_start and mapbox_clip_end properties, which are special properties added by geojson-vt when lineMetrics=true, and if so
- precalculates the total distance of the tiled feature in tile units, and
- scales the distance attribute of each vertex to [0, 2¹⁵) relative to the length of the entire original line geometry
Adds new line_gradient shaders which sample from the line gradient texture based on the distance varying.

Refs #4095.

Benchmarks:

http://bl.ocks.org/lbud/raw/e96f30170bfc39a6e3f1ddd2c0cc8fa1/ — the only benchmark I'd expect to potentially be affected by this is LayerLine, which in the linked benchmarks looks like it improves but when repeatedly running benchmarks actually stays just about equal. I also added a temporary LayerLineGradient benchmark (bottom of page) and it is, expectedly, just a little bit slower than the plain LayerLine, which doe not render to or sample from a texture.

Launch Checklist

depends on Calculate distance metrics for line features geojson-vt#93 being merged and released
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

jfirebaugh · 2018-03-09T23:54:55Z

build/generate-style-code.js

@@ -44,8 +44,8 @@ global.propertyType = function (property) {
        return `DataDrivenProperty<${flowType(property)}>`;
    } else if (/-pattern$/.test(property.name) || property.name === 'line-dasharray') {
        return `CrossFadedProperty<${flowType(property)}>`;
-    } else if (property.name === 'heatmap-color') {
-        return `HeatmapColorProperty`;
+    } else if (property.name === 'heatmap-color' || property.name === 'line-gradient') {


It's great that we have a second property with the same semantics as heatmap-color -- that increases the likelihood that heatmap-color is not some odd exception (and as we know, the odd exceptions are disproportionately expensive to maintain).

Since we now have two similarly-behaving properties, it's worth finding a generic way to capture that the style spec and replace the property name comparisons here with the use of a semantic property like isDataDriven uses. Such a property would probably be useful for Studio as well. As a schema design question, it intersects with #4194 -- although in light of this new information, I'm not sure my proposal there is still the best choice. @lbud do you want to think about this and come up with a proposal?

lbud · 2018-03-30T22:57:28Z

It's great that we have a second property with the same semantics as heatmap-color -- that increases the likelihood that heatmap-color is not some odd exception (and as we know, the odd exceptions are disproportionately expensive to maintain).

Since we now have two similarly-behaving properties, it's worth finding a generic way to capture that the style spec and replace the property name comparisons here with the use of a semantic property like isDataDriven uses. Such a property would probably be useful for Studio as well. As a schema design question, it intersects with #4194 -- although in light of this new information, I'm not sure my proposal there is still the best choice. @lbud do you want to think about this and come up with a proposal?

I'm working on this (#6389) but ended up splitting it off this branch as it complicates things quite a bit and conflates two different issues. I'm thinking maybe we should merge this as is (not as part of the 0.45 release) and follow it up immediately with a PR accomplishing #6389 (comment). Does that sound alright?

jfirebaugh

LGTM. Can you post benchmarks results?

Instead of indexing all features for querying, index only those that are actually within the tile boundaries. This prevents duplicate results from being returned for point features. This is only a partial fix for the duplicate results problem (lines and polygons can still return duplicate results).

…e of consistency with vector tiles), necessitating splitting MultiLineString features into individual LineStrings so they can hold their own distance attributes * Add render test

* Add unit tests for color ramp rendering

…s), clean up style-spec ref, add validation to ensure gradients are only used with geojson sources

…[ci skip]

@lbud