Global extent failure

[rhattersley]

ax = plt.axes(projection=PlateCarree())

# Works OK
ax.set_extent((-40, 40, -30, 30))

# Crashes
ax.set_extent((-180, 180, -90, 90))
...
File ".../cartopy/mpl_integration/geoaxes.py", line 244, in set_extent
    x1, y1, x2, y2 = r.bounds
ValueError: need more than 0 values to unpack

[pelson]

Looks like this could be a dupe of #4 but with slightly different impacts. Not sure at this point though.

[pelson]

P.S. Workaround: ax.set_extent((-180, 180, -90, 90)) -> ax.set_xlim([-180, 180]); ax.set_ylim([-90, 90])

[pelson]

Once this is done, I will look into #3 to see if we can get gshhs functionality back.

[pelson]

@esc24 : Were you working on this issue the other day or am I miss remembering?

[esc24]

I wasn't but I believe I've hit it recently. It may be because:

>>> cartopy.crs.PlateCarree().transform_point(180.0, 90.0, cartopy.crs.PlateCarree())
(180.00000000000003, 90.00000000002777)

which is outside the domain/boundary.

[pelson]

That is consistent with a problem @rhattersley was talking about the other day (suppose you wanted to project a polygon from PlateCarree to OSGB, and the polygon were bigger than the domain of OSGB. Currently, I believe the result will be an empty polygon, which clearly is not what is desired...)

[rhattersley]

That is consistent with a problem @rhattersley was talking about the other day (suppose you wanted to project a polygon from PlateCarree to OSGB, and the polygon were bigger than the domain of OSGB. Currently, I believe the result will be an empty polygon, which clearly is not what is desired...)

See #116.

[pelson]

For the record, I do not think #131 will fix this issue.

[rhattersley]

As pointed out by @esc24, the corners of the requested extent (+/- 180, +/- 90) project to just outside the projection domain. (The correct source CRS is Geodetic, not PlateCarree, but this just makes the discrepancy larger.)

So CRS.project_geometry(), as used within GeoAxes.set_extent(), is doing the right thing with the LineString it is given and returning an empty geometry. (Accessing the bounds property of this empty geometry gives an empty tuple instead of a 4-tuple, which is where the unpack error comes from.)

I'm tempted to try putting in a special-case check to catch this kind of thing and use the projection domain directly (instead of projecting the requested extent). Then once we've fixed the "big poly" problem in #116, we should be able to remove the special-case code and switch GeoAxes.set_extent() to use a Polygon instead of a LineString.

@pelson - how does that sound?

[pelson]

@pelson - how does that sound?

Sounds like a reasonable sticking plaster to move us forwards - though obviously solving #116 is the ideal solution.

[rhattersley]

@pelson and/or @esc24 - please take a look at #271.

[pelson]

Fixed by #271.