Don't infer x/y coordinates interval breaks for cartopy plot axes
See original GitHub issueThe DataArray.plot.pcolormesh()
method modifies the x/y coordinates of its plots. I’m finding that, at least for custom cartopy
projections, the offset applied here causes some real issues downstream.
@clarkfitzg - Do you see any problem with treating the x/y offset in the same way as the axis limits?
Issue Analytics
- State:
- Created 8 years ago
- Comments:9 (8 by maintainers)
Top Results From Across the Web
Understanding the transform and projection keywords - SciTools
The transform argument to plotting functions tells Cartopy what coordinate system your data are defined in. First we'll create some dummy data defined...
Read more >Source code for proplot.wrappers
GeoAxes ` API, you need to pass ``transform=cartopy.crs.PlateCarree()`` if your data coordinates are longitude and latitude instead of map projection ...
Read more >What's New — xarray 0.9.1 documentation
Fixed an issue where plots using pcolormesh and Cartopy axes were being distorted by the inference of the axis interval breaks. This change...
Read more >Matplotlib - Water Programming: A Collaborative Research Blog
The main packages we'll be using for this are cartopy and matplotlib to create ... A parallel axis plot is a simple way...
Read more >Matplotlib - The University of Texas at Austin
has no affect on plot(); see axes.color_cycle. #lines.marker. : None. # the default marker. #lines.markeredgewidth : 0.5.
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
I think a keyword argument is a pretty solid way to handle this. Detecting uniform coordinates specified with floating point numbers is pretty error prone.
What got us in trouble before was the approach we took to infering the interval breaks. If you’re willing to work through the logic related to 1d and 2d non-uniform coordinates, we can address this.