-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compatibility with libproj v9.3 #539
Comments
The problem seems to be linked to the missing |
We don't currently have PROJ 9.3.0 available to us through conda-forge. Given that, would it be possible for you to get a full print out of the comparison? Or I guess modify |
|
I've been looking at this and I am very confused. Based on the comparison done in the test (new first, old second) I would assume that the As far as I can tell |
Indeed the AreaDefinition comparison doesn't even look at the pyresample/pyresample/geometry.py Lines 2045 to 2052 in 04ea38d
However, since you've identified PROJ as being the cause for this error, I wonder if the CRSes are considered not equal. |
Wait...how do you have PROJ 9.3.0? That isn't even completely released yet? |
It is not currently listed here: https://proj.org/en/latest/download.html |
Yes, it is an RC |
Ok, that makes it a little more difficult for me to mix in with the rest of my dev environment. If you have any way to get a python interpreter with the PROJ RC and pyproj, then I think we could try a few things to be sure. I could maybe also look at the PROJ release notes and guess what might be breaking things. Bottom line is that pyresample is doing some pyproj So the original starting
But I see in the error message you posted that it says:
So we can clearly see the PROJ.4 isn't exactly the same, but that's not always a problem as PROJ figures it out anyway. I just ran it with my environment and these are equal, see: In [1]: from pyproj import CRS
In [2]: crs1 = CRS.from_proj4("+proj=laea +lat_0=90 +lon_0=0 +a=6371228.0 +units=m")
In [3]: crs1.to_proj4()
Out[3]: '+proj=laea +lat_0=90 +lon_0=0 +x_0=0 +y_0=0 +R=6371228 +units=m +no_defs +type=crs'
In [4]: crs2 = CRS.from_user_input(crs1.to_proj4())
proj = self._crs.to_proj4(version=version)
In [5]: crs1 == crs2
Out[5]: True |
>>> from pyproj import CRS
>>> crs1 = CRS.from_proj4("+proj=laea +lat_0=90 +lon_0=0 +a=6371228.0 +units=m")
>>> crs1.to_proj4()
/usr/lib/python3/dist-packages/pyproj/crs/crs.py:1293: UserWarning: You will likely lose important projection information when converting to a PROJ string from another format. See: https://proj.org/faq.html#what-is-the-best-format-for-describing-coordinate-reference-systems
proj = self._crs.to_proj4(version=version)
'+proj=laea +lat_0=90 +lon_0=0 +x_0=0 +y_0=0 +R=6371228 +units=m +no_defs +type=crs'
>>> crs2 = CRS.from_user_input(crs1.to_proj4())
>>> crs1 == crs2
True
>>> import pyproj
>>> pyproj.show_versions()
pyproj info:
pyproj: 3.6.0
PROJ: 9.2.1
data dir: /usr/share/proj
user_data_dir: /home/antonio/.local/share/proj
PROJ DATA (recommended version): 1.15
PROJ Database: 1.2
EPSG Database: v10.094 [2023-08-08]
ESRI Database: ArcGIS Pro 3.1 [2023-19-01]
IGNF Database: 3.1.0 [2019-05-24]
System:
python: 3.11.5 (main, Aug 29 2023, 15:31:31) [GCC 13.2.0]
executable: /usr/bin/python3
machine: Linux-6.2.0-31-generic-x86_64-with-glibc2.37
Python deps:
certifi: 2022.9.24
Cython: 0.29.36
setuptools: 68.1.2
pip: 23.2 |
Well wait, that says PROJ 9.2.1. I thought the problem was with 9.3.0? |
Yep. |
Ok, well with your |
My only other test that I can think of is to do the same test I gave you, but start with the other projection information in the test areas.cfg. So I guess:
If these all say they are equal when they go through this round trip test then...I don't know. |
Dear @djhoese, for all the proj strings that you suggest the result is always
By the way I noticed the the yaml files written in the two cases is different:
$ diff -u areas-libproj9.2.1.yaml areas-libproj9.3.yaml
--- areas-libproj9.2.1.yaml 2023-08-31 15:14:31.686634333 +0000
+++ areas-libproj9.3.yaml 2023-08-31 15:10:20.858926002 +0000
@@ -1,39 +1,23 @@
ease_sh:
description: Antarctic EASE grid
projection:
- proj: laea
- lat_0: -90
- lon_0: 0
- x_0: 0
- y_0: 0
- R: 6371228
- no_defs: null
- type: crs
+ EPSG: 3409
shape:
height: 425
width: 425
area_extent:
lower_left_xy: [-5326849.0625, -5326849.0625]
upper_right_xy: [5326849.0625, 5326849.0625]
- units: m
ease_nh:
description: Arctic EASE grid
projection:
- proj: laea
- lat_0: 90
- lon_0: 0
- x_0: 0
- y_0: 0
- R: 6371228
- no_defs: null
- type: crs
+ EPSG: 3408
shape:
height: 425
width: 425
area_extent:
lower_left_xy: [-5326849.0625, -5326849.0625]
upper_right_xy: [5326849.0625, 5326849.0625]
- units: m
pc_world:
description: Plate Carree world map
projection: Not sure if this is relevant or not. |
Oh very very interesting. That must be it then.
So...I guess I would maybe consider this a bug in PROJ 9.3? |
When you run the above code with 9.3, what do you get when just printing
|
The two crs are considered equal, which seems to be the correct behaviour, but the representation is still different (like in libproj v9.2.1). In [1]: from pyproj import CRS
In [2]: crs1 = CRS.from_proj4("+proj=laea +lat_0=90 +lon_0=0 +a=6371228.0 +units=m")
In [3]: crs2 = CRS.from_epsg(3408)
In [4]: crs1.to_proj4()
/usr/lib/python3/dist-packages/pyproj/crs/crs.py:1293: UserWarning: You will likely lose important projection information when converting to a PROJ string from another format. See: https://proj.org/faq.html#what-is-the-best-format-for-describing-coordinate-reference-systems
proj = self._crs.to_proj4(version=version)
Out[4]: '+proj=laea +lat_0=90 +lon_0=0 +x_0=0 +y_0=0 +R=6371228 +units=m +no_defs +type=crs'
In [5]: crs2.to_proj4()
/usr/lib/python3/dist-packages/pyproj/crs/crs.py:1293: UserWarning: You will likely lose important projection information when converting to a PROJ string from another format. See: https://proj.org/faq.html#what-is-the-best-format-for-describing-coordinate-reference-systems
proj = self._crs.to_proj4(version=version)
Out[5]: '+proj=laea +lat_0=90 +lon_0=0 +x_0=0 +y_0=0 +R=6371228 +units=m +no_defs +type=crs'
In [6]: crs1.to_epsg()
Out[6]: 3408
In [7]: crs2.to_epsg()
Out[7]: 3408
In [8]: crs1 == crs2
Out[8]: False
In [9]: crs1 == CRS.from_proj4(crs2.to_proj4())
/usr/lib/python3/dist-packages/pyproj/crs/crs.py:1293: UserWarning: You will likely lose important projection information when converting to a PROJ string from another format. See: https://proj.org/faq.html#what-is-the-best-format-for-describing-coordinate-reference-systems
proj = self._crs.to_proj4(version=version)
Out[9]: True
In [10]: print(repr(crs1))
<Projected CRS: +proj=laea +lat_0=90 +lon_0=0 +a=6371228.0 +units= ...>
Name: unknown
Axis Info [cartesian]:
- E[south]: Easting (metre)
- N[south]: Northing (metre)
Area of Use:
- undefined
Coordinate Operation:
- name: unknown
- method: Lambert Azimuthal Equal Area (Spherical)
Datum: unknown
- Ellipsoid: unknown
- Prime Meridian: Greenwich
In [11]: print(repr(crs2))
<Projected CRS: EPSG:3408>
Name: NSIDC EASE-Grid North
Axis Info [cartesian]:
- X[south]: Easting (metre)
- Y[south]: Northing (metre)
Area of Use:
- name: Northern hemisphere.
- bounds: (-180.0, 0.0, 180.0, 90.0)
Coordinate Operation:
- name: US NSIDC Equal Area north projection
- method: Lambert Azimuthal Equal Area (Spherical)
Datum: NSIDC International 1924 Authalic Sphere
- Ellipsoid: International 1924 Authalic Sphere
- Prime Meridian: Greenwich |
Ok, but now in PROJ 9.3 (as you showed with your diff) the |
@avalentino I think a newer version of PROJ fixes the issue(s) identified here. Can you confirm that builds are passing for you or do you think there is more work to do? |
Nevermind, PROJ 9.3.1 isn't released yet. |
FYI it looks like PROJ 9.3.1 was released in December. The bug fix to make pyresample tests pass should be included in that. |
I confirm that all works now. |
Code Sample, a minimal, complete, and verifiable piece of code
Problem description
Unittests fail with PROJ 9.3.0.
Error detected on Debian sid.
More details available in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050774
and
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1050774;filename=pyresample_1.27.1-1.1_amd64.build;msg=5
Expected Output
All tests pass successfully.
Actual Result, Traceback if applicable
Versions of Python, package at hand and relevant dependencies
The text was updated successfully, but these errors were encountered: