Plot space that crosses 180 degrees about iris HOT 12 CLOSED

I think you need to set up your GeoAxes with a chosen central longitude (default is 0).

import matplotlib.pyplot as plt
import cartopy.crs as ccrs
import iris
import iris.quickplot as qplt

cube = iris.load_cube("pacific_example.nc")
ax = plt.subplot(111, projection=ccrs.PlateCarree(central_longitude=210))
qplt.pcolormesh(cube, axes=ax)
plt.show()

Arguable Iris could/should be more clever about choosing that for you automatically.

from iris.

@SciTools/peloton There are a number of potential causes for the graph not working as expected, to pinpoint the problem we would need to recreate the cube or have access to the data. Could you upload a single timestep of the cube?

Thanks for raising this!

from iris.

Maybe have a look at Cartopy's gridlines method for axis labels. xticks is a Matplotlib thing, and Matplotlib doesn't know anything about Cartopy's special transforms.

import matplotlib.pyplot as plt
import cartopy.crs as ccrs
import numpy as np
import iris
import iris.quickplot as qplt

cube = iris.load_cube("pacific_example.nc")
ax = plt.axes(projection=ccrs.PlateCarree(central_longitude=210))
qplt.pcolormesh(cube, axes=ax)

ax.gridlines(draw_labels=True, linewidth=0, xlocs=[160, 180, -160, -140, -120, -100, -80])

plt.show()

from iris.

pacific_example.zip

Thank you!

from iris.

Can replicate the issue in the latest iris version.

import iris
import iris.quickplot as qplt

cube = iris.load_cube("pacific_example.nc") 
qplt.pcolormesh(cube)

If I plot the data manually using a PlateCarree projection I get a contiguous plot as expected

import matplotlib.pyplot as plt
import cartopy.crs as ccrs

ax = plt.axes(projection=ccrs.PlateCarree())
plt.pcolormesh(cube.data,transform=ccrs.PlateCarree())

And the cube doesn't have any coord_system attached so it should be using PlateCarree

print(cube.coord_system())
None
print(cube.coord("latitude").coord_system
None
print(cube.coord("longitude").coord_system
None

That's my initial ideas, any other thoughts on the cause of this issue?

from iris.

Update:
Though I have not changed my code at all, the effect of setting the limits of the plot has changed:
Now if I set the limits to [160-360, -80] it will show me [-180,-80];
and if I set the limits to [160, 360-80], it will show me [160,180],
but the only way to see both at the same time is to not limit the x-axis, in which case the figure still spans from -180 to 180 with a large section of no data in the middle, as before.
(setting the limits to [160, -80] still shows just the area with no data)

Any further thoughts in the meantime on how to deal with this issue @HGWright?

from iris.

@SciTools/peloton Do you need further assistance @rebeccaherman1 with this issue?

from iris.

Yes, @bjlittle, I think there's more to say.
Thanks @rcomer for the tip. This seems to work well as long as I don't mind having no axes labels on my plot. However, I want the viewer to know what they are seeing.

I am now avoiding the subplot hack and using the following code:

    ax = plt.axes(projection=ccrs.PlateCarree(central_longitude=220))
    qplt.pcolormesh(cube, axes=ax) 
    ax = plt.gca()
    ax.coastlines()

This produces the following plot:
(I am now plotting a slightly different quantity, but it shouldn't make any practical difference.)

However I have just realized that this results in relabeling 220E as 0, which means that I can no longer access the original longitude values for adding xticks to the plot, dramatically reducing the advantage of having the data in a cube. I'm working on a workaround for my present code now that I understand the problem, but I do not think this is a general sufficient approach. I agree with @rcomer that Iris should handle this automatically.

from iris.

Thank you, that is helpful.

I must say that I find the available functions somewhat frustrating. I don't like that gridlines() labels 4.5N and S rather than 5N and S, which mark the top and bottom of the plot. If I try to include these ticks forcibly, qplt elongates the plot to include up to 8N and S with no data there. Something similar happens when I try to use set_extent instead of the matplotlib xlims. Any ideas on how to avoid this?

For another plot, I believe I need to use set_extent because for some reason the plot fills in all the missing space with the color of the last point, and it also adds white space at the top.

Without set_extent:

With set_extent:

from iris.

I'm not sure about the set_extent behaviour, but set_ylim seems to work as expected for me. If you look at the bounds of your latitude coordinate, they only extend to +/- 4.71 degrees, so that will determine the default axis limits.

For your EOF plot, the most likely explanation is that the circular property of your longitude coordinate is set to True when it should be False.

from iris.

Thanks for the explanation and the idea, @rcomer.

I'm not sure about the set_extent behaviour, but set_ylim seems to work as expected for me. If you look at the bounds of your latitude coordinate, they only extend to +/- 4.71 degrees, so that will determine the default axis limits.

I think I wasn't expecting this because I had called extract_region using [-5,5]. Would the bounds be lower because of the grid? Or because they mark the center of the grid point rather than the edge?

For your EOF plot, the most likely explanation is that the circular property of your longitude coordinate is set to True when it should be False.

This is a property of the cube itself, right? It was a good idea, but I have checked, and the circular property of all components is set to 0. Incidentally, I wondered if this was potentially a reason why I was having trouble plotting the pacific_example, and if setting the coordinates to circular could stand in for setting the center of the plot. However, this does not help.

However it does have an effect exactly like what I see in the EOF plot, but it doesn't seem to be the cause in the EOF case. Any ideas of other fields that could have the same effect?

from iris.

@SciTools/peloton We are converting to a discussion as it seems to have moved on from the original question.

from iris.