Open jypeter opened 7 years ago
I'm not sure it is our place to explicitly state we are the replacement for basemap. That would be up to the basemap folks I think. However, there may be the chance to at least mention basemap somewhere, or offer an objective comparison.
That's what was implied at the end of the thread I mentioned. There may be some politics involved but it would help users to know if there is anything official
I can tell you that @weathergod is only maintaining Basemap for a couple more years and is advising users to move to CartoPy.
I declared the EoL for Basemap last year on the webpage: https://matplotlib.org/basemap/users/intro.html#cartopy-new-management-and-eol-announcement
I encourage everyone to move to Cartopy because it is a superior API design. I have also advertised this for the past two SciPy conferences. Basemap just has no hope of being maintained.
I should point out that you will soon be getting some competition from the GMT project as they move into the python space, but they don't integrate at all with matplotlib, and there isn't any hope for interactive plotting at the moment. But, their figures are very pretty...
Side note: I am the sole remaining "Basemap folks". I am just making sure the lights are turned off before I leave.
What I really meant was I'd be happy to advertise cartopy as something that can replace basemap, but not to claim that it should or currently is the replacement. How to replace basemap is up to the user to decide. They may be relying on some of the few things that basemap does but cartopy can't, or they may just prefer the Python GMT route.
This kind of information would be quite useful in the home of the cartopy web site!
I'm not a heavy and experienced user of matplotlib and basemap yet (I'm a uvcdat user), but knowing that basemap will slowly get less support and that cartopy offers similar looking maps, tightly integrated with matplotlib, sugests that I might as well jump to cartopy
More details on some of the few things that basemap does but cartopy can't would be useful as well
I mentioned in a couple threads that the limited ability to label meridians/parallels and the limited selection of projections (these were examples, here's the full list of basemap
projections; in the class of Mollweide, popular projections missing from cartopy
include Hammer and Aitoff) are both potential deal-breakers for someone looking into cartopy
. Publication-quality figures really need to have the labels, especially when a non-global plot is shown. And Hammer (for example) is popular in my fieldas an equal-area and aesthetically-pleasing projection.
Would love to contribute on these issues but as a self-taught programmer, I feel I have a lot to learn before that is possible. If these are addressed, then most of my peers and I (our field is atmospheric science) would happily move to cartopy; I agree that the more object-oriented approach of cartopy
and its integration with matplotlib
is greatly superior/simpler.
Thanks @lukelbd for the information! We may find what we need in the available projections, but I completely agree that nice labels for meridians/parallels are important.
Actually, I have just had a look at:
The cartopy projections' examples don't have any label, and the GMT have lots of labels. Does this mean that cartopy cannot handle these labels, or just that the labels have been left out in order not to clutter the plots?
If you guys can do labels, it would be really nice to include them in the examples! I have also checked the cartopy gallery, and there is only one example that uses labels (with projection=ccrs.PlateCarree
). I have then checked the iris gallery and there is no example that shows some lon/lat projection with meridian/parallel labels!
To clarify things: Unfortunately, cartopy
currently can only handle labels on two projection types; calling GeoAxes.gridlines()
with draw_labels=True
on any other types yields the error
TypeError: Cannot label gridlines on a <insert-projection-here> plot. Only PlateCarree and Mercator plots are currently supported.
Because the Gridliner
class already has the Basemap
-like options xlabels_top
, xlabels_bottom
, ylabels_left
, ylabels_right
, it seems the most logical approach would be to change xlabels
/ylabels
to mlabels
/plabels
, and then add the options mlabels_left
/mlabels_right
(where meridians cross the left/right "edge" of the axes) and plabels_top
/plabels_bottom
(where parallels cross the top/bottom "edge"). These options would trigger calls to a new labelling function.
Here is an example from the Basemap
documentation with a Lambert conformal projection (they labelled longitudes on the left/bottom, latitudes on the top/right).
+1. I just started using python for manipulating geographic data today, and I defaulted to Basemap, mostly because of the very nice docs in the python data science handbook. I looked at cartopy, but given no information about the EOL of basemap I stuck with it. Since @WeatherGod has given the explicit blessing that basemap is EOL (this is pretty explicit) and people should start switching I'd suggest including this info on the cartopy site.
As one contemplating the slightly painful switch (in view of the need to port code) from basemap to cartopy, I'm a little concerned about the meridion/parallel labeling issue as well as the smaller set of available projections. In addition, I'm still uncertain whether cartopy has something similar to basemap's support for cyclic boundary conditions. Is there a plan to address these and any other significant limitations before basemap is put out to pasture?
@gpetty For the labelling, see #1117 which should hopefully be merged soon (but not quite in time for next week's release)
For the cyclic boundary conditions, there's cartopy.util.add_cyclic_point
.
In general, basemap and cartopy are developed by entirely separate teams of people, mostly volunteers, so we have no control over when basemap ceases maintenance. We're interested in extending cartopy to cover more of basemap's functionality, so feedback like yours is helpful.
It would be great if there were some docs somewhere to guide conversion from basemap to cartopy, and detail any complexities involved. (It would also make an appropriate place to cite basemap's deprecation and their succession recommendation.)
This is relevant as the python 2 end-of-life motivates projects to migrate.
Could someone explain why the cartopy folks are so cagey about basemap? Basemap explicitly names cartopy as its replacement, and Ben Root even showed up in this thread to reiterate this fact. @dopplershift @QuLogic could you shed some light on this? Do you just not want cartopy to be on the hook for providing all of basemap's features? Or is there somethine else? Is @ajdawson simply being excessively pedantic?
@mablem8 I'm not really sure what you mean by cagey or more importantly what the issue is with what's been said.
Given that Basemap and CartoPy are completely separate, independent projects, with different motivations and designs, I'm personally just not wild about the branding of "Cartopy is a Basemap replacement." They're both packages in the solution space of plotting on maps with matplotlib. One is maintained, one isn't.
To me, it feels really weird in cartopy's docs to say: "You shouldn't use Basemap anymore." Maybe that's just me though.
The cartopy introduction does not mention basemap, but an old basemap thread I started concluded that basemap would be gradually phased out in favor of cartopy: https://github.com/matplotlib/basemap/issues/267
If that's (still) the case, it would help the users a lot to get that information at the beginning of the documentation, because: