search

matplotlib / basemap

Plot on map projections (with coastlines and political boundaries) using matplotlib
MIT License
780 stars 392 forks source link

Fixed compatibility issue with pyproj 2.0+ #454

Closed pandrey-fr closed 5 years ago

pandrey-fr commented 5 years ago

Starting with version 2.0, the pyproj.pyproj_datadir constant was deprecated in favor of the pyproj.datadir.get_data_dir() constant. A minor alteration to Basemap's __init__.py file allows compatibility with both the newer and older versions of pyproj regarding this breaking change.

WeatherGod commented 5 years ago

Hmm, doesn't seem to be working for some of the travis builds (other travis builds are failing due to not having Cython installed.... that seems to be unrelated, I hope).

pandrey-fr commented 5 years ago

The Python 2.6 and 3.4 travis builds failed to install pyproj because they (appear to) lack cython, which is unrelated to my fix (although it is indeed an issue).

For the other travis builds, I think it comes from the fact that epsg is not comprised in pyproj by default (I had this issue on my own machine, and copied the epsg file from /usr/share/proj to the /share/proj subfolder of my pyproj installation, which on the other hand contained most of the other projection files).

So, basically, we have to look into what other things changed with pyproj and how to remediate the issue...

pandrey-fr commented 5 years ago

An alternative could be to try and bypass the pyproj data directory in favor of either /usr/local/share/proj (on Linux) or the PROJ_LIB environment variable (on other platforms or in case the former does not exist). This is in fact what proj.4 does, and what pyproj would do if it did not comprise its own data directory (see this file), which for some reason seems not to include epsg, at least for the latest versions on Linux platforms.

pandrey-fr commented 5 years ago

I updated the code with the previous idea, but the travis builds are still failing, as it appears that the epsg file is not found in any of the expected locations on the machines... I would say it is about a change in the installation of pyproj, but I have not looked it up yet.

cgohlke commented 5 years ago

I don't think the epsg file is distributed with "standard" PROJ 6 or pyproj 2. Why not simply include the file in the basemap data directory?

pandrey-fr commented 5 years ago

I don't think the epsg file is distributed with "standard" PROJ 6 or pyproj 2. Why not simply include the file in the basemap data directory?

Thank you for confirming this; I will check the licensing of the file and commit a change to include it asap -- it the build passes, @WeatherGod will be able to judge whether it is pertinent to actually make this change to basemap or not.

pandrey-fr commented 5 years ago

I have not had time to include the file (and change the code) yet, nor update legal mentions accordingly; but the terms of use of the espg seem to allow its distribution as part of basemap. They can be found here.

pandrey-fr commented 5 years ago

As expected, adding the file directly as part of basemap fixes the issue, and travis builds succeed - or fail for unrelated issues that seem to be caused by Cython when compiling either pyproj or (for the nightly python version) numpy. I am no expert in Travis, but I would guess it has to do with the virtual machines' configuration...

On the other hand, I did not include a proper licensing of the epsg file (and used one that may be out of date as I did not download the latest from the epsg website). @WeatherGod (or somebody else), would you take care of that, as I am no legal expert nor am entirely clear about the organization of legal mentions in the package?

pandrey-fr commented 5 years ago

I went through the travis file and the builds' output stacks, and it appears that:

By the way, 2.6 is long-deprecated (as is 2.7, but I can get the point of maintaining it), and 3.4 has been deprecated after the update from March 18th, so do we really need to test for those systems, knowing that in fact people who might chose to stay on those systems can either stop updating their packages or figure out issues that are related to dependencies and not basemap itself?

WeatherGod commented 5 years ago

So, the failures appear to be related to whenever we build using the internal libgeos. This is a completely separate problem, and I won't hold up this PR over it.

WeatherGod commented 5 years ago

Where did you download the epsg file from? I need to determine its source in order to place the right license file in the source tree.

pandrey-fr commented 5 years ago

Where did you download the epsg file from? I need to determine its source in order to place the right license file in the source tree.

To be honest, I had it on my computer and do not remember exactly where it came from, but probably from an older version of PROJ.4. I went through the history of their repository, and found that the latest version to include epsg coordinates as a flat file is 5.2 ; I am therefore going to make a commit replacing the file I initially updated with the one found here.

On the other hand, I registered on the epsg website in hope to download the latest version of the file, but it now seems to only be distributed as a microsoft database file, which would need conversion to proj4 format - and I don't know how to do that.

pandrey-fr commented 5 years ago

I think we should thus refer to PROJ.4's licensing, which can be found here for the version I took the file from, and states that everything (including data files) can be re-used.

WeatherGod commented 5 years ago

License file was added in PR #460