Fixed compatibility issue with pyproj 2.0+ #454
Conversation
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.
|
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). |
|
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... |
|
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. |
Since version 2.0, pyproj comes with an internal data directory that is used in favor of the one set by the PROJ_LIB environment variable (or, on Linux, of the default proj folder set by PROJ.4). It appears this internal directory sometimes does not contain the epsg file (at least on Linux), which may however be found by looking up those other locations. This commit therefore adds attempts to look up for the epsg file when it cannot be found in pyproj's internal datadir.
FileNotFoundError is not part of built-in exceptions in Python 2. This commit allows to use it in Python 3, and replace it with a RuntimeError in Python 2.
|
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. |
|
I don't think the |
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. |
|
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. |
TODO: add license file regarding epsg, based on terms of use, which are found here: http://www.epsg.org/TermsOfUse.aspx
|
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? |
|
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? |
|
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. |
|
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. |
|
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. |
|
License file was added in PR #460 |
Starting with version 2.0, the
pyproj.pyproj_datadirconstant was deprecated in favor of thepyproj.datadir.get_data_dir()constant.A minor alteration to Basemap's
__init__.pyfile allows compatibility with both the newer and older versions of pyproj regarding this breaking change.