selection on fields=[fieldname:N] generates :N in vega-lite fields but should not
See original GitHub issueCopied from https://github.com/vega/vega-lite/issues/5710:
if I call selection = alt.selection_multi(fields=["advance_mode:N"], bind='legend')
, Altair 4.0.0 generates
"selection": {
"selector009": {
"type": "multi",
"fields": ["advance_mode:N"],
"bind": "legend"
},
but I believe it should drop the :N
and generate
"selection": {
"selector009": {
"type": "multi",
"fields": ["advance_mode"],
"bind": "legend"
},
The latter has the intended behavior AFAICT.
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Field | Vega-Lite
1) A string representing the data field. For example, we can set field to "precipitation" to map it to x position.
Read more >Selection Parameters | Vega-Lite
Selections projected over aggregated fields / encodings can only be used within the same view they are defined in. Interval selections can only...
Read more >Axis | Vega-Lite
Simply put, axes visualize scales. By default, Vega-Lite automatically creates axes with default properties for x and y channels when they encode data...
Read more >Bindings, Selections, Conditions: Making Charts Interactive
Selection Targets: Fields and Encodings These control what data properties are used to determine which points are part of the selection. For example,...
Read more >Predicate | Vega-Lite
To check if the state field's value is greater than "Arizona" by string comparison, we can use ... For a parameter predicate, a...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
The reason Altair doesn’t do this automatically is because it requires assuming too much about user intent. For example, it’s possible to have dataframe columns with colons in their names.
We could go down the rabbit hole of checking dataframe column names against specified field names to try and infer the intent of the user, but then what about remote data? And what about transforms that define new data fields? There are a ton of potentially surprising corner cases and pitfalls as soon as you try to infer user intent from incomplete information, and so Altair has chosen to avoid that. As they say, explicit is better than implicit.
Totally sensible. I appreciate the explanation!