You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the old deprecated filter syntax, there is very useful operator in, which can be easily used to test property value against number of possible values. It does not work with expressions, so I guess my only option is to use combination or any and == (and possibly number).
So this clear statement: [ "in", "country", "BGR", "BIH", "GBR", "ROU", "SVN" ]
become this: [ "any",["==", ["get", "country"], "BGR"], ["==", ["get", "country"], "BIH"], ["==", ["get", "country"], "GBR"], ["==", ["get", "country"], "ROU"], ["==", ["get", "country"], "SVN"]]
(or even worse with numbers).
Is there any good reason not to have in operator in expressions syntax? I believe it can maybe even provide better performance (since JS have functions to test for elements in arrays)
The text was updated successfully, but these errors were encountered:
In the old deprecated filter syntax, there is very useful operator
in
, which can be easily used to test property value against number of possible values. It does not work with expressions, so I guess my only option is to use combination orany
and==
(and possiblynumber
).So this clear statement:
[ "in", "country", "BGR", "BIH", "GBR", "ROU", "SVN" ]
become this:
[ "any",["==", ["get", "country"], "BGR"], ["==", ["get", "country"], "BIH"], ["==", ["get", "country"], "GBR"], ["==", ["get", "country"], "ROU"], ["==", ["get", "country"], "SVN"]]
(or even worse with numbers).
Is there any good reason not to have
in
operator in expressions syntax? I believe it can maybe even provide better performance (since JS have functions to test for elements in arrays)The text was updated successfully, but these errors were encountered: