-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VegaFusion treats pandas categoricals differently than Altair's default transformer #402
Comments
Oh I noticed that Vegafusion displays the desirable behavior with integers as well! That's great and resolves the issue I had when openeing vega/altair#3140 in the first place. Now I really want use to bring that behavior into altair's base transformer too if possible... |
VegaFusion doesn't actually support categoricals internally, and "expands" them during the conversion to arrow, so it makes sense that you see the same behavior as with integers in this case. For integers parsed as temporal columns, VegaFusion currently interprets them as years: I honestly don't recall why I put that logic in there. I thought it was to match an Altair or Vega-Lite example, but maybe not. I think this could be a change to propose in Vega's date parsing. I'm really not sure what it's currently doing, I would have guessed that the alternative to treating integers as years would be to treat them as UTC milliseconds, but that doesn't appear to be happening either given the As an alternative, Altair could re-interpret integer columns as years by adding a custom |
I see, I do find that the Vegafusion behavior adds a lot of convenience here, so I would be in favor of re-implementing that solution in Altair as well, although I would prefer if it could be added in Vega so that we don't have to depart from VL (although I think this is a smaller departure). I found a Vega issue where this was initially discussed and suggested the change there again vega/vega#1681. There is also an issue in Altair from the same time vega/altair#1365 |
The chart from the spec below renders differently with vegafusion enabled. vegafusion handles it better than the the default transformer and creates a more reasonable x-scale (the same result can be obtained in altair by casting to a string instead of a category as in vega/altair#3140 (reply in thread)). If we can have altair render the chart the same without vegafusion that would be great, but depending on what vegafusion actually does here that might not be possible.
The text was updated successfully, but these errors were encountered: