菜单
Non-obvious MapLibre GL JS expression gotchas: legacy vs modern filter syntax, when to use 'match' vs 'in' for categorical membership, and other traps LLMs commonly fall into. Use when writing filters, paint expressions, or default_filter/default_style config for MapLibre layers.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Map of the boettiger-lab data-and-agent stack — which GitHub repo owns which piece of the data → STAC → MCP → LLM-agent chain. Use when unsure which repo to edit for a given problem, when routing cross-repo issues, or when the root cause could plausibly be in more than one layer.
Manage S3 object storage on the NRP (National Research Platform) Nautilus cluster, which uses Ceph S3 (not AWS). Covers public vs internal endpoints, rclone usage, bucket creation, public-read policies, CORS configuration, credential handling, and syncing to source.coop. Use when working with S3 buckets on NRP Nautilus, uploading or downloading data, configuring bucket access, or syncing datasets to source.coop.
Use when storing, versioning, or sharing large files alongside a GitHub repo — model checkpoints, datasets, build artifacts, binaries, fixtures — and you want collaborators to use their GitHub access rather than separate cloud credentials. Covers ghcr.io, oras CLI, content-addressing, public/private access, and the tradeoffs vs git-lfs, S3 buckets, and GitHub Releases.
Use when browsing, querying, or reasoning about what datasets exist in a STAC catalog — especially before concluding a dataset is missing or absent. Triggers include STAC browser URLs, s3 stac-collection.json links, or any question about what data is available in a catalog.
Analyze geo-agent app behavior from LLM proxy and MCP server logs, identify inefficiencies, and trace root causes to the correct layer: STAC metadata, MCP tool descriptions, geo-agent framework, or app system prompt. TRIGGER when: reviewing agent behavior, analyzing LLM logs, improving system prompts based on observed failures, debugging tool-use loops, or optimizing query patterns in geo-agent apps.
Deploy and manage workloads on the NRP Nautilus Kubernetes cluster. Covers batch jobs (opportunistic priority class, resource requests, GPU node avoidance), ingress with HAProxy CORS and timeout annotations, NRP usage policies, and credential wiring. TRIGGER when the user mentions: kubectl, k8s, kubernetes, NRP, Nautilus, rollout, restart deployment, apply yaml, pod, job, namespace, ingress, or any cluster operation. Namespace is 'biodiversity'. Always load this skill BEFORE running any kubectl command.
| name | maplibre-expressions |
| description | Non-obvious MapLibre GL JS expression gotchas: legacy vs modern filter syntax, when to use 'match' vs 'in' for categorical membership, and other traps LLMs commonly fall into. Use when writing filters, paint expressions, or default_filter/default_style config for MapLibre layers. |
| license | Apache-2.0 |
| metadata | {"author":"boettiger-lab","version":"1.0"} |
For general MapLibre expression syntax and available functions, see the MapLibre expression docs. This skill covers only the parts that commonly trip up LLMs.
MapLibre has two filter syntaxes. The legacy one is still parsed but deprecated and should never be written in new code.
"in" with a bare string field name// WRONG — legacy syntax (deprecated)
["in", "RANGE", "CRUWYL", "CRUWIN", "CRUSWR"]
This looks plausible but uses the old style where the field is a bare string rather than a ["get", ...] expression. It works in some MapLibre versions but is not the expression system.
match for categorical membership (preferred)// RIGHT — modern expression, preferred for categorical membership
["match", ["get", "RANGE"], ["CRUWYL", "CRUWIN", "CRUSWR"], true, false]
match is the right tool when checking if a property equals one of several known values. It returns any output value, so it works identically in both filters and paint expressions.
in with literal array (modern form)// RIGHT — modern expression using in + literal
["in", ["get", "RANGE"], ["literal", ["CRUWYL", "CRUWIN", "CRUSWR"]]]
The modern in operator takes (needle, haystack). The haystack must be a ["literal", [...]] expression — a plain JSON array is not valid here. Use this form when the set of values is dynamic or computed at runtime.
match vs in| Situation | Use |
|---|---|
| Check if property equals one of several known string/number values | match |
Same check in a paint expression (e.g. fill-color) | match |
| Check membership in a runtime-computed or large array | in + ["literal", [...]] |
| Substring check within a string value | in (needle is a string, haystack is ["get", ...]) |
Default to match for categorical membership — it's more readable, consistent between filters and paint, and avoids the literal wrapping requirement.
The same match expression works directly as a paint property value:
{
"fill-color": ["match", ["get", "RANGE"],
"WIN", "#5B9BD5",
"CRUWIN", "#0D47A1",
"SWR", "#FF8C00",
"#BDBDBD"
],
"fill-opacity": 0.5
}
The final argument is always the fallback (no corresponding key).
in — ["in", "FIELD", ...] is legacy syntax. Use ["match", ["get", "FIELD"], [...], true, false] instead.["in", ["get", "FIELD"], ["CRUWYL", ...]] — The array must be wrapped in ["literal", [...]]; a raw JSON array is not a valid expression.match — match always requires a final fallback value; omitting it is a runtime error.match in a filter without returning boolean — Filters must evaluate to true/false; ["match", ..., true, false] is correct, not ["match", ..., "yes", "no"].