@snowman2 Have you ever had different experiences with proj from Linux to Windows on what it accepts? Pyresample had some old documentation that was doing the equivalent of
Proj({'proj': 'eqc', 'lon_0': 0.0, 'lat_0': 0.0}) and it seems to error on Windows with RuntimeError: b'major axis or radius = 0 or not given' with pyproj 1.9.6 but with pyproj 2.3 it is fine. I would have assumed pyproj/proj to get more strict, not less strict. And I've never seen this error before. FYI this is PROJ 5.2.0 on Windows that fails.
$ conda list proj
# packages in environment at /home/snowal/miniconda3/envs/geocube:
#
# Name Version Build Channel
proj4 5.2.0 he1b5a44_1003 conda-forge
pyproj 1.9.6 py36h516909a_1002 conda-forge
(geocube) snowal@snowal-lx2:~$ python
Python 3.6.7 | packaged by conda-forge | (default, Jul 2 2019, 02:18:42)
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pyproj import Proj
>>> pj = Proj({'proj': 'eqc', 'lon_0': 0.0, 'lat_0': 0.0})
>>> pj
pyproj.Proj('+units=m +proj=eqc +lon_0=0.0 +lat_0=0.0 ', preserve_units=True)
>>> import pyproj
>>> pyproj.__version__
'1.9.6'
@snowman2 Just because I'm a pain, ETA on pyproj 2.3.1?
FYI, did you know you can do
pip install git+https://github.com/pyproj4/pyproj.git?
(no need to make a release)
can even add
@branch-or-tag
will have to search through PROJ source for where it is coming from
*working
Hey all, I'm working on upgrading pyproj from 1.9.4 to a more recent version. But I can't get past a change in output from pyproj.transform if I go to 2.2.1 and higher.
import pyproj
result = pyproj.transform(pyproj.Proj(init='EPSG:4326'),
pyproj.Proj(init='EPSG:31370'),
-50, -50)
print(result)
# 2.2.1: (-16648000.756625965, -13287157.707139067)
# 1.9.4: (-16647936.738681808, -13287195.77167615)The outputs are in the comments, and the difference is really too big to ignore.
What exactly is going wrong here?
so use
pyproj.Proj('EPSG:4326') instead
I also have been struggling with this (also with EPSG:31370 ;)), but thought for me the difference was smaller (not in the meters order)
I do have smaller differences with more realistic data rather than
But still..
-50, -50149372.267141, 175495.954088 vs 149372.214872, 175495.952055.But still..
In [27]: import pyproj
...: result = pyproj.transform(pyproj.Proj(init='EPSG:4326'),
...: pyproj.Proj(init='EPSG:31370'),
...: 4, 50)
...: print(result)
(123563.57130448119, 76585.07875370234)In [14]: import pyproj
...: result = pyproj.transform(pyproj.Proj(init='EPSG:4326'),
...: pyproj.Proj(init='EPSG:31370'),
...: 4, 50)
...: print(result)
(123563.56657479196, 76585.07854289468)In [17]: import pyproj
...: result = pyproj.transform(pyproj.Proj('EPSG:4326'),
...: pyproj.Proj('+proj=lcc +lat_1=51.16666723333333 +lat_2=49.8333339 +lat_0=90 +lon_0=4.367486666666666 +x_0=150000.013 +y_0=5400088.438 +ellps=intl +towgs84=-106.869,52.2978,-103
...: .724,0.3366,-0.457,1.8422,-1.2747 +units=m +no_defs'),
...: 4, 50, always_xy=True)
...: print(result)
(123563.5712753858, 76585.07851246372)
this gives yet another result, but is closer to the result of pyproj 1.9.6. The difference here has to do with the
+towgs84 which is not considered part of the EPSG:31370 definition
But on your original example, why the difference is so big for unrealistic (outside of the area of use) coordinates, I am not sure
Ah yes, so it's not the transform, but the parsing of the
Proj that makes the big difference. # 1.9.4:
# EPSG : (-16647936.738681808, -13287195.77167615)
# proj4: (-16647936.738681808, -13287195.77167615)
# 2.2.1:
# EPSG : (-16648000.756625965, -13287157.707139067)
# proj4: (-16647936.738681737, -13287195.771676153)
hello! I have an installation question, as I can't seem to get Proj to update by updating pyproj. I've tried updating pyproj and proj4 via conda but Proj is still locked at 4.9.3, does anyone know how to get Proj updated to use some of the coordinate systems that depend on Proj version 5.2 in pyproj?
and do you have strict channel priority set?
The newest versions of pyproj will be on conda-forge, but it also depends on what versions of other libraries you are using. Some libraries may not be built for the newest versions of PROJ. There are also some limitations about the versions of libraries available on Windows (like GDAL 3.x)
do you have other PROJ related libraries installed @joemcglinchy? Like rasterio? cartopy? gdal?
I think it is recommended that you set conda-forge as the channel for the entire environment (I always set it globally) and it is usually best to look in setting a channel_priority to "strict". Otherwise you end up with some packages from the defaults channel and some from conda-forge and they may conflict. What do you get when you do conda install -c conda-forge "pyproj>=2"? Note that pyproj 2.0+ depends on PROJ 6 so this is higher than the PROJ 5.2 that you want, but it's also the newest version so it'd be a good idea to upgrade now if you can.
@djhoese i do have other libraries installed. There was a conflict wiht my rasterio version (0.36). I tried installing a fresh environment w/ python 3.7, then installing geopandas (which successfully installed gdal and proj 5.2), but now have issues with installing rasterio. That is a whole other can of worms, though.
Or maybe it is a limitation on geopandas?
@joemcglinchy A lot of this can be fixed if you force strict channel priority. You may not need it configured globally, but you should at least use it when first creating the environment with all of your main dependencies. What is happening is that conda is looking at packages from conda-forge and defaults and mixing them together, however for C libraries or C-heavy libraries like GDAL, PROJ, rasterio, and pyproj, things can easily get messed up. You can tell this by looking at where the packages are coming from when you do your install/update commands. You'll likely see results from conda-forge and defaults. There are only a few libraries that should actually be coming from defaults; most of them are pretty low-level
@snowman2 Sanity check: PROJ/pyproj have no way of guessing the datum from a PROJ string unless it is explicitly set.
I realized today that newer versions are automatically converting a/b to ellps if it matches a definition (ex.+ellps=GRS80), but wondering if there is a way to define PROJ parameters to have it do the same for the datum. I'd assume there aren't PROJ parameters to define a datum completely
@snowman2 one more: Ever experienced a bug in rasterio/GDAL where it drops some of the projection parameters? I have a WKT rasterio CRS object that has the Latitude of natural origin and Longitude of natural origin for a
laea projection, but after saving to a geotiff with rasterio it has those parameters set to 0