Use of interpolate for functions is confusing

[pathmapper]

trafficstars

Maputnik version: master

• for data function and zoom function there is no difference for interpolate

• If you choose interpolatewith the following settings for line-width:

The JSON editor shows:

    "line-width": {
      "stops": [[5, 0.75], [18, 32]]
    }

Which is equivalent to

    "line-width": {
      "type": "exponential",
      "base": 1,
      "stops": [[5, 0.75], [18, 32]]
    }

• exponential is the default value for line-width function type
• the default value for base is 1

So whether line-width changes linear or exponential is determined by the base value.

It's confusing to have interpolate here and also exponential in the dropdown, see https://github.com/maputnik/editor/issues/709 (the part with Second attempt)

Interpolate isn't a function type at all.

The missing base input is tracked in https://github.com/maputnik/editor/issues/710.

[orangemug]

@pathmapper so what we're saying here is that before we had 2 types of old-style functions

• Zoom
• Data

We should instead just have 1 type 'data', the type should either come from the the type in the JSON definition or the default function type for the property.

Is that correct?

[pathmapper]

@orangemug basically yes, but I don't think all properties support all function types, especially exponential and interval. interpolate is not a function type and should be removed from the dropdown.

[orangemug]

@pathmapper so what maputnik has tried to do in the past is treat zoom functions as a special type of function that are different from data functions. Zoom functions were functions without a property set, whereas data functions were those with a property set. This was confusing because a zoom function was either exponential or interval based on the default type.

When I added the new UI I essentially added an interpolate option based off of the docs

Which is incorrect because the function could either be exponential or interval, where exponential is essentially what mapbox are referring to as interpolate.

So I think we can find out weather a function supports exponential with supportsInterpolation.

If a property supports interpolation then it I think it always defaults the function to exponential if a type isn't provided.

So plan for the UI. I agree we should get rid of interpolate because that's more confusing. Although I also think that having a exponential/interval with a property field is also confusing because if you don't supply a property then it'll fallback to using zoom which isn't very obvious to the user.

So maybe we should add a 'data driven'/'zoom' option box which enables the property field. That way if a style contains a property for a given function there will be an option labeled 'data driven' with a 'property' beneath. If it doesn't contain a property then the UI will have the 'zoom' option selected.

Does that make sense? Have I missed anything got anything wrong?

[pathmapper]

@orangemug thanks for writing this up, very helpful.

So I think we can find out weather a function supports exponential with supportsInterpolation.

I think this works for expressions not functions:

The result might be also true for functions but I'm not sure.

I agree we should get rid of interpolate because that's more confusing.

OK, so we only want the following types in the dropdown:

• identity
• exponential
• interval
• categorical

A bonus would be to only display the types which could be used for a property. Maybe the spec throws an error if a function type is used which is not available for a property which would be also sufficient if this error is displayed in the UI.

So maybe we should add a 'data driven'/'zoom' option box which enables the property field. That way if a style contains a property for a given function there will be an option labeled 'data driven' with a 'property' beneath. If it doesn't contain a property then the UI will have the 'zoom' option selected.

There are three sorts of functions and for two zoom is needed and for two property is needed in the UI:

	Zoom function	Property function	Zoom-and-property function
Property field needed		yes	yes
Zoom field(s) needed	yes		yes

I like your idea with the option box, so what about two option boxes, one for zoom and one for property?

---

Currently there are three options for the user in the UI:

• expression
• data function
• zoom function

I think we should have only two options

• expression
• function (which includes zoom, property and zoom-and-property function)

also because the legacy functions are deprecated and we shouldn't make functions so prominent in the UI compared to expressions.

[orangemug]

@pathmapper I had another look at this given your comments.

I think we can split our options into 2 groups, by-property and by-zoom

There is a partially working(ish) branch in https://github.com/maputnik/editor/pull/733 try water and background layers for the osm-liberty style. background should disable the 'by property' group.

There are lots of bugs, but I can fix those up easy enough if this gives us what we need.

Any thoughts/comments?

[pathmapper]

Good idea @orangemug, I think there is the third group by zoom and property missing (see https://docs.mapbox.com/mapbox-gl-js/style-spec/other/).

Otherwise this is what we need :+1:

[orangemug]

@pathmapper I think we do support all the different use cases in the UI in that PR, I think maybe I'm just labelling them poorly. Let me explain and you can tell me whether it's correct or not

Zoom based functions, in the 'by zoom' option group

Property + zoom based functions, from 'by property' option group

Property only functions, currently in 'by property' option group

Note: This one need fixes, we didn't really support this properly previously

If the above is technically correct, I suggest we change the dropdown to read

---

Note: A little aside from the mapbox-gl docs, I think this originally confused me

{
    "circle-color": {
        "property": "temperature",
        "stops": [
            // "temperature" is 0   -> circle color will be blue
            [0, 'blue'],
            // "temperature" is 100 -> circle color will be red
            [100, 'red']
        ]
    }
}

I think essentially what is happening here is because it's a 'function' without a type but with a property specified and the first argument is not an object (for example {zoom: 20, value: 0}) it defaults the type to a categorical.

Whereas if we removed the property in the above example the type would default to either interval/exponential depending on if the property supports 'interpolation'.

[orangemug]

...also 'base' should only be present on 'exponential property'/'exponential property + zoom' functions.

[pathmapper]

Thanks @orangemug, this looks good as far as I can see.

So for Property + zoom based functions currently the zoom input fields are missing in the PR (but the label is there).

I suggest we change the dropdown to read

This is only a demo, there will be more types for each group, right? Or are some types filtered out in the case visible on the image? E.g. i think for the by property group interval is missing.

But having the three groups in the dropdown is what I meant.

[orangemug]

This is only a demo, there will be more types for each group, right?

@pathmapper unless I'm mistaken I think this is the complete list of functions

So there are 4 types of function, however there are 6 options in total, because exponential and interval can exist without a property specified. Full list

• identity — 'property only'
• categorical — 'property only'
• exponential — 'zoom + property'
• exponential — 'zoom only'
• interval — 'zoom + property'
• interval — 'zoom only'

Am I missing some options?

[pathmapper]

@orangemug hmm, maybe I'm the one who is missing here something, but I would think that the following options are missing: interval — 'property only' exponential — 'property only'

because exponential and interval can exist also with property.

Here's a sample style: test_style.zip