Can't use log scale with bar?

[domoritz]

For example, we can't add scale: {type: "log"} to the histogram example.

{
  "data": {"url": "data/movies.json"},
  "mark": "bar",
  "encoding": {
    "x": {
      "bin": {"maxbins": 10},
      "field": "IMDB_Rating",
      "type": "quantitative"
    },
    "y": {
      "aggregate": "count",
      "field": "*",
      "type": "quantitative",
      "scale": {"type": "log"}
    }
  }
}

[kanitw]

The culprit is that we for bar, we output

"y2": {"scale": "y","value": 0}

So we should avoid passing 0 through log scale) by default for bar / area.
The solution is probably don't include scale if the scale type is log by default.

@ayush29feb since you have to modify mark.properties, could you take care of this too? This should not take too much time to fix.

[jheer]

This is worth fixing. But for the examples, I recommend not using bar
charts over a log-scaled domain. A dot plot would be a better example of
what to do!

On Wed, May 18, 2016 at 2:49 PM, Kanit Wongsuphasawat <
notifications@github.com> wrote:

The culprit is that we for bar, we output

"y2": {"scale": "y","value": 0}

So we should avoid passing 0 through log scale) by default for bar / area.
The solution is probably don't include scale if the scale type is log by
default.

@ayush29feb https://github.com/ayush29feb since you have to modify
mark.properties, could you take care of this too? This should not take
too much time to fix.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1368 (comment)

[kanitw]

But for the examples, I recommend not using bar charts over a log-scaled domain. A dot plot would be a better example of what to do!

Yep. We definitely wouldn't include this in the example gallery.

More note for @ayush29feb, if we don't pass this through the scale, the correct value might not always be 0. For example, y-axis's value should be the height.

[domoritz]

@kanitw makes sense. Points work.

[ayush29feb]

Yeah I can take care of it while working on #1284 over the weekend

[domoritz]

Thanks

On Wed, May 18, 2016, 19:50 Ayush Saraf notifications@github.com wrote:

Yeah I can take care of it while working on #1284
#1284 over the weekend

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1368 (comment)

[domoritz]

@kanitw How should @ayush29feb get the height of the visualization/ cell? He needs to get it from the layout because the cellHeight may not be the actual height for instance with layering.

[kanitw]

If you have layering that two layers do not have the same cellHeight, both layer should have their own cellHeight (with the correct prefix) so I don't see why that is an issue.

[domoritz]

The cell height will only be available from the layout data source, though.

[kanitw]

The cell height will only be available from the layout data source, though.

If you have two layers that do not have the same layout, there should be more than one layout data sources.

[domoritz]

My question is how we access the layout from the mark properties?

[kanitw]

My question is how we access the layout from the mark properties?

Good question. I was wrong about this sentence. (My memory starts coming back.)

If you have two layers that do not have the same layout, there should be more than one layout data sources.

The correct one is "there should be more than one *-cellHeight fields in the layout data source.

[domoritz]

The correct one is "there should be more than one *-cellHeight fields in the layout data source.

This is not the issue. The issue is only how to access the layout data source.

[kanitw]

Actually, just like rule, you can use {group: 'width'} (or height)?

[ayush29feb]

Yeah @domoritz, I think you actually can do that.

[domoritz]

I see. So we don't need access to the layout data source. Perfect.

[kanitw]

Another case -- I think we have the same problem if scale.zero = false :)