Skip to content

Allow dup_axis within scale_x_date #2244

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

Closed
brianwdavis opened this issue Aug 20, 2017 · 16 comments
Closed

Allow dup_axis within scale_x_date #2244

brianwdavis opened this issue Aug 20, 2017 · 16 comments
Assignees
Labels
feature a feature request or enhancement scales 🐍

Comments

@brianwdavis
Copy link
Contributor


A question on SO led to wondering why duplicate axes aren't usable with scale_x_date or *_datetime. I worked up fairly hacky solutions by converting to numerics and working back from date_breaks, but it should "just work". While you're at it, I'm sure it would be nice to be able to have transformed sec_axis: e.g. hours on the x-bottom and days on the x-top.

See reprexes at: https://stackoverflow.com/a/45373735/3330437

example desired

@karawoo karawoo added feature a feature request or enhancement scales 🐍 labels Aug 21, 2017
@hadley
Copy link
Member

hadley commented Oct 30, 2017

@thomasp85 any chance you have time to take a look?

@thomasp85
Copy link
Member

When do you expect the next release? I can’t promise anything this week

@hadley
Copy link
Member

hadley commented Oct 30, 2017

I'll probably start the release process in 2-3 weeks.

@thomasp85 thomasp85 self-assigned this Oct 30, 2017
@thomasp85
Copy link
Member

I'll give it a shot

@thomasp85
Copy link
Member

Do you have any feelings regarding the transformations allowed with dual axis in the current implementation? To me it seems dual date axes is mostly for decorative purposes, though someone might conceivably want to plot a timeserie with both Chinese and Gregorian calendar..?

@hadley
Copy link
Member

hadley commented Nov 8, 2017

Yeah, it's not clear that this needs to support transformation, but maybe just different breaks/labels? (i.e. have years on top and months on bottom)

@thomasp85
Copy link
Member

That’s my feeling too, but is also the solution resulting in the worst API. It would require an additional set of sec_axis/dup_axis functions that blocks the transformation argument..?

@hadley
Copy link
Member

hadley commented Nov 8, 2017

Hmmm, but it probably needs a different sec_axis anyway for date_breaks() etc?

@thomasp85
Copy link
Member

I suggest we postpone it to after this release. I’m still interested in doing it but I don’t want to butcher the API to get it done, so I’ll need some time to think it through...

@hadley
Copy link
Member

hadley commented Nov 17, 2017

Ok, np.

@kevinwolz
Copy link

Another feature related to this is the ability to use two different columns/datasets from which to base the time axes. For example, I have a dataset with "actual time", which I would like to have label the bottom x-axis in date format, and "time since event", which I would like to have label the top x-axis in hours format.

This would be very useful for me, but I also have a feeling that it would be useful in many time series analyses. Not sure what the best approach would be to accomplish this, though.

@thomasp85
Copy link
Member

My feeling is that this is a simple transformation, and an argument for keeping the transformation argument in the Datetime implementation

@ldecicco-USGS
Copy link

I just need axis ticks on the top axis of my timeseries graphs:

ggplot(data = data.frame(date = seq.Date(from = as.Date("2010-01-01"),
                                          to = as.Date("2010-12-01"),
                                          length.out = 12),
                          y = 1:12)) +
  geom_point(aes(date, y)) +
  scale_y_continuous(sec.axis = dup_axis(labels = NULL)) +
  scale_x_continuous(sec.axis = dup_axis(labels = NULL))

That will make my life soooo much easier

@thomasp85
Copy link
Member

The road to hell is, unfortunately, paved with good intentions. While it would be easy to support your use case we might inadvertently end up with an api that cannot easily grow or be maintained. Thus, we/I will need some time to think about how to best implement this it.

Your needs have been noted though🙂

@ldecicco-USGS
Copy link

"Your needs have been noted though" - that's all I was going for. Thanks so much!

@lock
Copy link

lock bot commented Mar 17, 2019

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/

@lock lock bot locked and limited conversation to collaborators Mar 17, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature a feature request or enhancement scales 🐍
Projects
None yet
Development

No branches or pull requests

6 participants