Open kidanger opened 2 weeks ago
This is by design. The reason this is the case is to prevent using the PROJ_DIR for a different PROJ installation that is incompatible. The PROJ database must be the one provided for that specific PROJ version and should not be interchanged.
If you have a separate PROJ installation, you should install pyproj from source instead of from a wheel if that is what you would like to use.
Thank you for the fast answer.
Then I'm not sure why pyproj.datadir.set_data_dir
would have precedence over pyproj internal data but PROJ_DATA
doesn't, but I don't know all the details of pyproj and proj. Maybe this is not the goal of PROJ_DATA
. My use-case is to bundle specific datum grids during the distribution of a software, to avoid network downloads or relying on user folders.
Feel free to close the issue, if the behavior in intended.
I'm not sure why pyproj.datadir.set_data_dir would have precedence over pyproj internal data but PROJ_DATA doesn't
The reason set_data_dir
exists is to set the data directory if it cannot be found automatically. It is guaranteed to be for the specific instance of pyproj and not for another installation of PROJ.
With multiple installations of PROJ on a single machine, PROJ_DATA could potentially point to an incorrect directory that shouldn't be used by pyproj.
Hello,
Currently, setting the environment variable PROJ_DATA has no effect on pyproj when the installation of pyproj brings its own data. I think it would be good to lower the priority of the internal data, and let users override the proj data with the environment variable in more cases.
Example: (from a fresh virtual env, python 3.12)
(related discussion: https://github.com/NixOS/nixpkgs/pull/282139)