Styling - helper expressions

[lilleyse]

Before, a style with a conditions list would be able to store a single expression to make the style more concise:

{
    "color" : {
        "expression" : "regExp('^1(\\d)').exec(${id})",
        "conditions" : [
            ["${expression} === '1'", "color('#FF0000')"],
            ["${expression} === '2'", "color('#00FF00')"],
            ["true", "color('#FFFFFF')"]
        ]
    }
}

This idea can be broadened to work for any types of styles. An expressions object can exist at the top level of the style for use by any of the styles within:

{
    "expressions" : {
        "length" : "length(${POSITION})",
        "time" : "${tiles3d_tileset_time} * 0.1"
    },
    "color" : {
        "conditions" : [
            ["${length} < 0.1", "${length} * color('red')"],
            ["${length} < 0.5", "vec4(vec3(${temperature} * fract(${time})), 1.0)"],
            ["${id} < 750", "vec4(${secondaryColor} / 5.0, 1.0)"],
            ["${id} < 1000", "rgb(0, 0, Number(${secondaryColor}.x < 0.5) * 255)"]

        ]
    },
    "show" : "${length} < 0.9"
}

If this seems like a good change, one question I have is whether there needs to be a conditions object any more. It could just be:

    "color" : [
            ["${length} < 0.1", "${length} * color('red')"],
            ["${length} < 0.5", "vec4(vec3(${temperature} * fract(${time})), 1.0)"],
            ["${id} < 750", "vec4(${secondaryColor} / 5.0, 1.0)"],
            ["${id} < 1000", "rgb(0, 0, Number(${secondaryColor}.x < 0.5) * 255)"]
     ]

This was implemented in Cesium here CesiumGS/cesium#5232 and I'll have a spec PR in a bit.

[pjcozzi]

For the spec, please note the scope of the created identifiers in the expressions objects, e.g., can they have the same name as a feature's property? And if they do, do they have precedence?

Also, is expressions the best name? Or should it be something like variables or constants or defines?

[pjcozzi]

I have is whether there needs to be a conditions object any more. It could just be...

If I'm following - are you suggesting that an array can just be implicitly considered a conditions?

I would not suggest this since it prevents, for example, things like this in the future:

"color" : [255, 0, 0, 255]

[lilleyse]

Yeah that's what I was suggesting. That's a good future case.

[lilleyse]

For the spec, please note the scope of the created identifiers in the expressions objects, e.g., can they have the same name as a feature's property? And if they do, do they have precedence?

I think it is fine for the expression to have any name and always have precedence. It can even reference a feature's property within, like length : "${length} * 2". The one condition would be that expressions don't reference other expressions. This is how Cesium currently handles it.

[lilleyse]

Also, is expressions the best name? Or should it be something like variables or constants or defines?

The concept of variables already exists (https://github.com/AnalyticalGraphicsInc/3d-tiles/tree/master/Styling#variables) - so I would go with defines.

So overall... a variable can reference either a property or a define.

[pjcozzi]

#226 (comment) - these constraints sound fine to me, make they explicit in the spec.

[pjcozzi]

so I would go with defines...So overall... a variable can reference either a property or a define.

Sounds good.

[pjcozzi]

Initial implementation: #226