Skip to content
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

Seaborn for plotting #109

Open
vpapaioannou opened this issue Jun 25, 2020 · 4 comments
Open

Seaborn for plotting #109

vpapaioannou opened this issue Jun 25, 2020 · 4 comments

Comments

@vpapaioannou
Copy link

Is your feature request related to a problem? Please describe.
The various 'plot()' functions found in pysal/explore module have their own interface and signature while the same matplotlib.pyplot plot() function is used in the end.

Describe the solution you'd like
A unified flexible interface.

Describe alternatives you've considered
Seaborn module for all plots will solve this problem while providing additional capabilities for free.

@sjsrey
Copy link
Member

sjsrey commented Jul 3, 2020

Thanks for raising this. I think it is more appropriate to continue this thread over in splot, so I'm relocating the issue there.

@sjsrey sjsrey transferred this issue from pysal/pysal Jul 3, 2020
@slumnitz
Copy link
Member

@vpapaioannou thank you for raising this issue! I'd be happy to have a look at unifying this!

I'd like to first double check with you: pysal/explore has a lot of functionality some of the plotting functionality is based on splot other plots are not. I.e. it can pysal/explore can be part of the giddy or esda packages. Would you mind giving me a pointer to which classes you have used in pysal/explore that have the same backend functions you are referring to? We could potentially start with unifying these.

@vpapaioannou
Copy link
Author

I used the plot() of simulated envelopes that is now deprecated and the PointPattern plot().

@slumnitz
Copy link
Member

@sjsrey are these covered by splot? If not maybe worth a thought adding them to the functionality as one plot? Otherwise this might be more appropriate to solve in the respective packages?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants