functions without interpolation

[ansis]

The functions in the new dash implementation (mapbox/mapbox-gl-js#938) work a bit differently than existing functions. The would need to be treated differently from a ui perspective. It also raises a bunch of other questions. A bit of background on why they work the way they do:

Current functions are always interpolated. For any specific zoom, it finds the nearest step above, the nearest step below, and then interpolates both to get an exact value. This works great for line widths, etc.

But some other value types can't be interpolated like this. Functions for these properties would not be continuous. They would jump sharply when switching between steps.

fill patterns

If fill patterns had functions they might look something like this:

"fill-image": {
    "stops": [
        [0, "waves-small"],
        [8, "waves-medium"],
        [12, "waves-large"]
    ]
}

You can't interpolate the string "waves-small" with "waves-medium". I think you want it to choose just "waves-small" for zooms 0-7.99, "waves-medium" for 8-11.99, etc. Transitions between stops could be faded.

Line patterns would work the same way.

dashed lines

Dashes are a specific kind of line pattern. Just like line patterns, dash patterns need to stretch and reset so that the dashes don't look like they are sliding along the line. In the new dashed line implementation mapbox/mapbox-gl-js#938, dash functions work the same way the pattern functions above work:

"line-dasharray": {
    "stops": [
        [0, [5, 1]],
        [8, [3, 2]]
    ]
}

The two dash sizes, 5 and 3, are never interpolated to get a mixed value. It just chooses the pattern with the closest z <= the current z. So, for zooms 0-7.99 it uses [5, 1] and for zooms 8+ it uses [3, 2].

In the old dash implementation you could provide two separate functions for the dash and gap parts of the pattern. This isn't possible with the new approach.

Since the dash sizes are scaled by the line width you shouldn't need functions in most cases. You should only need functions when you want the proportions to look different at different zooms.

ui

A ui for styling would have to treat these functions differently from number functions. There probably wouldn't be a graph. The first thing that comes to mind is something similar to a table with [z, pattern] pairs, but there could be a better way.

questions

Do the proposed pattern functions work the way you would expect them to and the way they should?
Does it make sense to treat dashes the same way as patterns?
Would this new type of function cause ui problems?

@nickidlugash @edenh @jfirebaugh @peterqliu @lbud

[peterqliu]

For fade transitions between fill-images, will there be a parameter to adjust how long that transition will be? Put another way, the zoom duration that both images would overlap and be visible simultaneously, compared to the duration that only one image is visible.

[ansis]

For fade transitions between fill-images, will there be a parameter to adjust how long that transition will be?

Yes, a parameter could be exposed in the style. It might make sense to move away zoom-based overlap to only time-based overlap so that patterns are only crossfaded during timed transitions, not permanently. Separate issue for that: #236

I'm imagining something like this:

"line-dasharray": {
    "stops": [...],
    "duration": 300
}

[edenh]

Would this new type of function cause ui problems?

We can work to accommodate the new functions.

If we're going down this road, I think we should apply these new function types to transition-able array properties as well:

"fill-translate": {
  "stops": [
    [0, [0, 0]],
    [6, [10, 0]]
  ]
}

[nickidlugash]

If we're going down this road, I think we should apply these new function types to transition-able array properties as well

Is this for UI consistency? It will mean that the users unnecessarily loses the ability to set separate bases for each value in the array, but maybe that's not a big deal. For -translate, there's probably not too much of a use case for setting separate bases, although there could potentially be for raster-brightness, since numerical values for brightness don't correspond to perceived optical brightness.

[edenh]

For both UI and spec consistency. I think it would be strange is some array values are transitioned individually (-translate) and some as a whole (-dasharray).

[nickidlugash]

What about if make this change for all transitionable array values, but split raster-brightness into two separate properties, raster-max-brightness and raster-min-brightness?

[edenh]

👍

[nickidlugash]

If we're going down this road, I think we should apply these new function types to transition-able array properties as well

Just to be clear, we're just talking about making -translate functions follow the same written format, right? We're not talking about making -translate non-interpolated?

[edenh]

Just to be clear, we're just talking about making -translate functions follow the same written format, right?

Right.

[jfirebaugh]

Following up from last comments here and mapbox/mapbox-gl-js#976 (comment).

It seems like the consensus is to switch to the [0, [0, 0]] syntax for array-valued functions, but split raster-brightness into -min- and -max-. That sounds fine to me. @ansis if you agree please make it so.

[jfirebaugh]

🚢