How to test for nulls with new expression syntax?

[stevage]

I'm not sure if this is a support request, a comment on the new API or a feature request.

I'm loading a GeoJSON layer which contains some nulls. I want to create a color property which displays the null values differently from other values. (Yes, I could create two layers and a filter, as a workaround). My code looks like this:

        paint: {
            "circle-color": 
                ["case",
                    ["all", 
                        ["!=", ["get", "Enrolments_2017_Total"], null],
                        ["!=", ["get", "Capacity_Total"], null]],
                    [
                        "rgb",
                        ["max",
                            0,                    
                            ["min", 
                                255, 
                                ["+", 
                                    -200, 
                                    ["*", 
                                        400, 
                                        ["/", 
                                            ["get", "Enrolments_2017_Total"], 
                                            ["get", "Capacity_Total"]]]]]],
                        0,
                        200
                    ],
                    "yellow"
                ],

Problem:

If I use ["!=", ["get", "Enrolments_2017_Total"], null],, I get an error.

Error: layers.school-points.paint.circle-color[1][1]: Expected arguments of type (number, number) | (string, string) | (boolean, boolean) | (null, null), but found (value, null) instead.

Can this be right? Is it literally saying you can only compare a null literal to another null literal (["!=", null, null])? Um, why would you want to do that? :)

If I use ["has", "Enrolments_2017_Total"] then that test always passes, because every feature "has" that property, it's just sometimes null.

If I use [">", ["get", "Enrolments_2017_Total"], 0],

I get:

Error: layers.school-points.paint.circle-color[1][1]: Expected arguments of type (number, number) | (string, string), but found (value, number) instead.`

Is there something I'm missing here?

[stevage]

Hmm, this method almost worked:

[">", ["to-number", ["get", "Enrolments_2017_Total"]], 0],

but didn't seem to always get the right result.

This method worked:

["==", ["typeof", ["get", "Enrolments_2017_Total"]], "number"],

It feels quite cumbersome and not very intuitive, considering the equivalent in the old syntax was:

["!=", "Enrolments_2017_Total", null]

[anandthakker]

I think you're right that having a (null, null) overload for == doesn't really make sense.

There are three ways in the current API designed for this sort of null-handling:

1. The typeof-based approach you mentioned above, ["==", ["typeof", ["get", "Enrolments_2017_Total"]], "number"]. The most universal, but also the most cumbersome.
2. Using a fallback value in the "number" type assertion: [">", ["number", ["get", "Enrolments_2017_Total"], -1], 0]. Only works if there's a value like -1 that's unused in the actual feature data, so that it can stand for 'null'.
3. Convert to boolean: ["to-boolean", ["get", "Enrolments_2017_Total"]]. The most concise, but would also be false if the value of Enrolments_2017_Total was 0 (since 0 gets converted to false).

Other, less cumbersome options we could consider:

• Add "==-null", "!=-null" operators: ["!=-null", ["get", "Enrolments_2017_Total"]]
• Add type-aware versions of has (has-number, has-string, etc.): ["has-number", "Enrolments_2017_Total"]

[jfirebaugh]

Another option would be to replace the (null, null) overload for == with (null, value) and (value, null) overloads.

[stevage]

Yeah, @jfirebaugh's suggestion is intuitively how I expected it to work. It was confusing and unexpected to me that "value" is a distinct type, and that you have to explicitly use casts everywhere. It was also very unintuitive that null is considered a unique type, rather than just a special value of every other type.

[anandthakker]

Another option would be to replace the (null, null) overload for == with (null, value) and (value, null) overloads

A sort of similar problem to the one in this issue is doing something like ["==", ["get", "thing-one"], ["get", "thing-two"]]. Currently, this wouldn't compile without type assertions around the gets. I'm wondering (again) whether it's really valuable to force the per-atomic-type overloads here, rather than just having it be (value, value).

The only benefit I can think of is that, if the arguments to == were a bit complicated, it would be possible to accidentally author an expression where the two arguments are (always) incompatible types (e.g. string, number) and then be confused why it always evaluates to false. The current approach protects against that, but if we went with (value, value), we could have a bit of extra validation for == that fails if the arguments were (statically) typed as two incompatible types.

Meanwhile, the most common case is likely just ["==", ["get", "x"], some_literal] -- and in that case, the (value, value) approach is basically equivalent to the current approach with enhanced type inference.

[stevage]

Awesome, glad I was useful.

[dominijk]

Is this documented somewhere? I have data with null values and want to filter these out, the data can be string or numeric.

[kuanb]

+1 to @dominijk question

[palamago]

@kuanb use ['has', field]

[mvl22]

After encountering the same problem, I thought it would be useful to provide examples:

Use in an expression, to switch styling between normal and null value:

This will keep the feature present (e.g. for hover purposes), but show it is as transparent:

const expression = [
	'case',
		['has', fieldname],    // check that the property for the named field is not null
			'green',       // value for the normal value colour
		'transparent'          // or whatever you want your NULL value to be shown as
];

The value for the normal state can itself be an expression, e.g. if you have a step/case expression for a range of values, you can wrap that with the above:

const expression = [
	'case',
		['has', fieldname],
			['step',
				['get', fieldname],
				'green'
				5, 'orange'
				10, 'red'
			],
		'transparent'
];

Use as a filter when defining addLayer, to exclude features entirely:

This will filter out null features entirely, i.e. not even shown/selectable at all.

map.addLayer ({
	...
	filter: ['has', fieldname],
});

See example at:
https://docs.mapbox.com/mapbox-gl-js/example/cluster/