Which is the latest (stable) version of basemap? 1.0.8 or 1.0.7 (or other?)

[jypeter]

I'm afraid this may be a stupid question, but I have found conflicting information about the latest basemap version and I'd like to know the correct answer. And maybe someone can improve the available information

• The matplotlib basemap pages mention a 1.0.8 version, of February 13, 2014: http://matplotlib.org/basemap/api/index.html
• According to the github releases page, the latest version is 1.0.7, on 17 Aug 2013: https://github.com/matplotlib/basemap/releases
• The github basemap homepage says download basemap-X.Y.Z.tar.gz (approx 100 mb) from the sourceforge download site but does not provide the latest X.Y.Z information and the link to the appropriate sourceforge page : https://github.com/matplotlib/basemap
• The matplotlib basemap installation page (http://matplotlib.org/basemap/users/installing.html) provides a sourceforge link for Windows binary installers or source tarballs, where you can find a 1.0.7 version dated August 2013 : https://sourceforge.net/projects/matplotlib/files/matplotlib-toolkits/
• pypi provides the 1.0.7 version (without mentioning a release date): https://pypi.python.org/pypi/basemap/1.0.7

In summary, it seems you can get a 1.0.7 stable release, and there is a more recent virtual (?) 2-year old 1.0.8 release ? This is a bit confusing

[micahcochran]

I believe the answer is 1.0.7. There might be a new release in the near future.

The github development version is labeled 1.0.8.

The documents stating 1.0.8 were probably generated on that date using the development version.

[jypeter]

OK, so 1.0.8 is for now whatever are the latest files you can grab on github then?
But wouldn't it be less confusing to have the documentation page mention 1.0.7, the stable release that's also referenced by Pypi?

[WeatherGod]

Micah, I was trying to figure out how that inconsistency arose, and I think
you figured it out.

Jean-Yves, yes, once I figure out how to update the readthedocs page, I
will do so (I am the new maintainer, and I haven't gone through a release
cycle yet).

On Tue, Feb 23, 2016 at 5:23 AM, Jean-Yves Peterschmitt <
[email protected]> wrote:

OK, so 1.0.8 is for now whatever are the latest files you can grab on
github then?
But wouldn't it be less confusing to have the documentation page mention
1.0.7, the stable release that's also referenced by Pypi?

—
Reply to this email directly or view it on GitHub
#267 (comment).

[davidedelvento]

It would be less confusing if the development version would be label dev instead of future.release.number (currently 1.0.8) as it's the case for all the other software.

[davidedelvento]

Also, there are rumors that the @jswhit is recommending cartopy instead of basemap, see e.g. SciTools/cartopy#525 -- However it looks like there is a fair amount of development in basemap, so those rumors sound strange. Are they true?

[efiring]

My impression is that Jeff is tired of supporting basemap, and sees cartopy as a promising replacement, long-term, with some potential advantages. At present, however, I don't think that one can easily do all of the things with cartopy that software using basemap can do. I expect I will be relying on basemap for quite a while. If I had no software already using basemap, and if cartopy were able to do everything that I needed (and expected to need in the next year or two), then I would probably use it instead.

[WeatherGod]

@jswhit is no longer the maintainer of basemap, and it isn't a rumor that
he recommends using cartopy for new developments/projects. Jeff has handed
the reins for basemap over to me with the understanding that I plan on
taking the project on its death march. I will make sure that it works for
the most recent versions of its dependencies; I may even make incremental
improvements here and there. I will also review and accept any PR with new
features and bugfixes for the next few years.

However, the codebase isn't very conducive to any refactors, and the test
suite is next to nothing, so any major work would be very risky.

I know I have kept on promising to do a release soon. The big barrier for
me is finding the time to learn how to actually do a release. If I don't
figure it out before SciPy 2016, I suspect that there will be several very
qualified people there that will be able to walk me through the process.

On Thu, Jun 9, 2016 at 8:04 PM, Eric Firing [email protected]
wrote:

My impression is that Jeff is tired of supporting basemap, and sees
cartopy as a promising replacement, long-term, with some potential
advantages. At present, however, I don't think that one can easily do all
of the things with cartopy that software using basemap can do. I expect I
will be relying on basemap for quite a while. If I had no software already
using basemap, and if cartopy were able to do everything that I needed (and
expected to need in the next year or two), then I would probably use it
instead.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#267 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AARy-E1Xh12CyKxORXgY-8b6He9v18_kks5qKKoZgaJpZM4Hc6DK
.

[QuLogic]

At present, however, I don't think that one can easily do all of the things with cartopy that software using basemap can do.

Such as, if I may ask?

[davidedelvento]

@WeatherGod - thanks for the frank response!

[efiring]

@QuLogic, Undoubtedly part of the problem is that I am not aware of much in the way of cartopy examples and documentation, so I don't see how to do things. I have been using basemap for a long time, and I have written wrappers to make some basic things easy for me. I think the set of supported projections in cartopy is smaller, although it does have the advantage of providing the InterruptedGoodeHomolosine.
As an example of the sort of plots I need to make, see http://currents.soest.hawaii.edu/nbpalmer/.
My primary wrapper code is mainly in http://currents.soest.hawaii.edu/hgstage/pycurrents/file/729f3ecff26b/plot/maptools.py with the main entry point being the mapper function.
Peripherally related: are there plans to keep the scitools channel more up to date in the future? I see that cartopy 14.0 has been out for a couple months, but the latest on scitools (at least for py3.5) is 13.1.

[jypeter]

Thanks @WeatherGod for taking over basemap, because there are (still) lots of basemap users out there! I don't have much experience with cartopy, except that it looks nice and probably provides the tools I need. I also like the fact that there is some dedicated support available on stackoverflow, should I need it: https://stackoverflow.com/questions/tagged/cartopy

The only thing I can say is that last time I tried to install cartopy into an existing python distribution (UV-CDAT), I quickly ran into dependency related problems that I did not have with basemap. But that was a while ago and has possibly been solved since. As far as I remember, basemap was much easier/lighter to install and I hope you can keep it that way

[crazyBaboon]

There is also Basemap in stackoverflow :)

https://stackoverflow.com/questions/tagged/matplotlib-basemap

[jypeter]

For the record (adding to my June 2016 comment) I had no dependency problems when installing cartopy into the conda-based UV-CDAT 2.10 (but I had problems with 2.8)

[molinav]

The latest stable release of basemap is out there for almost a week now (1.3.0). This version includes a signficant refactoring of the library into three parts, similarly to how Anaconda does (basemap, basemap-data and basemap-data-hires).

Furthermore, basemap is now offered in PyPI with precompiled binary wheels available for Windows and GNU/Linux, for x86 and x64 architectures, for Python 2.7 and 3.5-3.9. I am willing to provide also binary wheels for MacOS but I didn't have the time and knowledge to do it for now:
https://pypi.org/project/basemap
https://pypi.org/project/basemap-data
https://pypi.org/project/basemap-data-hires

From my side, basemap will be still developed for the moment at least to fix all current known problems as well as the open issues here in GitHub. Just note that I do this mostly in my free time, so I depend a bit on my availability.

[jypeter]

Thanks for the update @molinav ! It's good to know that basemap is still supported

[jypeter]

@molinav could you make basemap-data available on conda-forge? It does not seem to be there (see below)

Also, if basemap is (thankfully) still maintained for Python 3, you may want to update the information in Cartopy, New Management, and EoL Announcement and similar places

>mamba install basemap-data

Looking for: ['basemap-data']

pkgs/r/linux-64          [====================] (00m:00s) No change
pkgs/r/noarch            [====================] (00m:00s) No change
pkgs/main/noarch         [====================] (00m:00s) Done
pkgs/main/linux-64       [====================] (00m:00s) Done
conda-forge/noarch       [====================] (00m:01s) Done
conda-forge/linux-64     [====================] (00m:05s) Done
Encountered problems while solving.
Problem: nothing provides requested basemap-data


>mamba install basemap-data-hires

Looking for: ['basemap-data-hires']

[...]
Transaction

  Prefix: /home/share/unix_files/cdat/miniconda3_21-02/envs/cdatm_py3

  All requested packages already installed

[WeatherGod]

On conda-forge, the basemap package comes with what is effectively "basemap-data" on PyPI.

…

On Mon, Jan 3, 2022 at 10:17 AM Jean-Yves Peterschmitt < ***@***.***> wrote: @molinav <https://github.com/molinav> could you make basemap-data available on conda-forge? It does not seem to be there (see below) Also, if basemap is (thankfully) still maintained for Python 3, you may want to update the information in Cartopy, New Management, and EoL Announcement <https://matplotlib.org/basemap/users/intro.html#cartopy-new-management-and-eol-announcement> and similar places >mamba install basemap-data Looking for: ['basemap-data'] pkgs/r/linux-64 [====================] (00m:00s) No change pkgs/r/noarch [====================] (00m:00s) No change pkgs/main/noarch [====================] (00m:00s) Done pkgs/main/linux-64 [====================] (00m:00s) Done conda-forge/noarch [====================] (00m:01s) Done conda-forge/linux-64 [====================] (00m:05s) Done Encountered problems while solving. Problem: nothing provides requested basemap-data >mamba install basemap-data-hires Looking for: ['basemap-data-hires'] [...] Transaction Prefix: /home/share/unix_files/cdat/miniconda3_21-02/envs/cdatm_py3 All requested packages already installed — Reply to this email directly, view it on GitHub <#267 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACHF6CR4UJHJYWPKPPN273UUG4ZXANCNFSM4B3TUDFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[molinav]

Yes, the conda-forge recipe will need an update from version 1.3.0, since the package structure has changed. This development takes place in another repo in which I do not have control:
https://github.com/conda-forge/basemap-feedstock

The rationale behind this split of basemap-data was to decrease the size of the uploaded packages in PyPI. If this data were placed inside the precompiled binary wheels, we will basically be uploading this 20 MB of data several times, for each architecture, operating system and Python version. In this manner, all the basic data is in one single binary wheel which basemap depends on.

There is some slight difference between the basemap-data-hires from PyPI and Anaconda. In PyPI, the intermediate resolution files go into basemap-data instead of basemap-data-hires. Otherwise, basemap-data-hires was exceeding the maximum package size in PyPI.

It is safe to install the latest basemap-data and basemap-data-hires using pip inside a conda environment because they have no dependencies. For basemap, however, I would recommend you to install with python -m pip install --no-deps basemap and install the dependencies yourself from the conda channels. The list of dependencies is in the requirements file.

Ideally we should be able to have basemap available in conda-forge, but this has not happened yet.

[molinav]

Just for the record, I notified the need to update the conda recipe for basemap in conda-forge/basemap-feedstock/issues/87, but there is still no reply.