-
Notifications
You must be signed in to change notification settings - Fork 365
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
REF: Use pyproj 3+ for PROJ 8+ migration #1808
Conversation
snowman2
commented
Jun 24, 2021
•
edited
Loading
edited
- Closes Convert to proj v5 API #1140
- Closes Port to use pyproj v2 #1477
- Closes segmentation fault when instantiating Proj4Error #1718
- Potentially solves Add cylindrical equal-area projection (epsg 6933) support #1098
- Potentially solves How to mediate between cartopy vs. rasterio CRS? #923
- Potentially solves Create Cartopy projection from pyproj.Proj #813
- Related to WIP: Updating to PROJ 6+ proj.h C API #1252
0a41861
to
1b1b3c0
Compare
lib/cartopy/crs.py
Outdated
y1 = self.area_of_use.north | ||
lons = np.array([x0, x0, x1, x1]) | ||
lats = np.array([y0, y1, y1, y0]) | ||
points = self.transform_points(self.geodetic_crs, lons, lats) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be helpful here: https://pyproj4.github.io/pyproj/stable/api/transformer.html#pyproj.transformer.Transformer.transform_bounds
It looks like you took some of the CRS code from Cython up into Python with the Maybe we should add in timing durations output for the tests to see if the N slowest are changing between this PR and the base, to figure out if it is specific tests that are slower or just overall everything is slower. |
Really excited to see this. Looks like the last vestige of PROJ directly are for the geodetic stuff? |
913eabf
to
0f211c5
Compare
Got more tests passing. Current state of things:
The good news is that it seems to be much faster now. |
That is great news! Do you know what you did to get the speed up again? It might be good to document that somewhere so that we don't introduce the speed regression later on. |
Yes, that is the current state of things with this PR.
I am not entirely sure what changed as I just noticed it after fixing some bugs. Possible that bugs were causing the troubles 🤷♂️ |
96d1ceb
to
ab65ca8
Compare
With the original test and
With pyproj:
At the bottom of the current version, the projection actually changes the coordinates somehow. But, for the new version no change occurs. I would expect no change to occur because the source and destination CRS are both |
I think that is due to us allowing PlateCarree input ranging from (-180, 360), but the output is always wrapped to (-180, 180) unless you've moved your central_longitude. Does pyproj take a shortcut if source and destination are the same? We may want to force the transform anyway for situations like this... |
Funny you mentioned _copytobuffer. I just made this change: pyproj4/pyproj#905 |
Hm... I just tried to test that out and see if it helps, but I can't import cartopy when using the latest pyproj (v3.1.0 from source works). Python 3.9.6 | packaged by conda-forge | (default, Jul 11 2021, 03:39:48)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cartopy
Traceback (most recent call last): Something with the Mercator projection having an unknown
File "pyproj/_crs.pyx", line 2323, in pyproj._crs._CRS.__init__
pyproj.exceptions.CRSError: Invalid projection: +proj=merc +ellps=WGS84 +lon_0=unknown +x_0=0.0 +y_0=0.0 +units=m +no_defs +type=crs: (Internal Proj Error: proj_create: invalid value for lon_0) bisects to pyproj4/pyproj@ea2cc18 |
Glad you were able to catch the change. It corresponds to pyproj4/pyproj#902. The benefits of this change is that the This commit in the |
I think this should do it: pyproj4/pyproj#912 |
I just pushed up two commits to try and speed things up.
Running the slowest example currently, the all UTM, we get the following timings:
On master:
|
Thanks @greglucas 👍, that is great! I am -1 on requiring the global context. This impacts all other applications in the python environment that use pyproj. Also, with PROJ 8.1+ there isn't a significant benefit to using the global context in many instances. |
pyproj == comparison is slow, so if we are comparing two Cartopy CRSs, return a fast-path comparison. Let the pyproj comparison handle the other cases.
Good point! I was only thinking directly within this project. I just dropped that commit. I also looked into a few other speedups as well, and there are some gains to be had in trace.pyx of ~2-3x easily (eliminating some transform calls) and probably more with some additional refactoring. I think that would be a bigger overhaul project after this gets in though since it would be a significant rework. |
I added 2db5efc for the scenario when the strings aren't equal, but the CRS are equal. |
Each call to |
I think this is in a good spot for merging, so lets get it in for people to test out in master. Thanks for the work in updating both this and pyproj, @snowman2! |
Thanks for your help with this @greglucas 👍 |
Thanks for pushing this through to the finish @greglucas! |