PROJ_NETWORK: First transform fails, succeeds afterwards #705
Comments
|
Unable to re-produce in the latest version. Removed the local cache and still not able to re-produce. |
|
@snowman2 this is happening for me on MacOS. I have reached here from geopandas Seeing your suggestion on the linked GIS question, I am able to consistently make get it to fail for the first call to I have installed from conda-forge on MacOS 10.15.7 (please see linked issue for environment file). I believe the problem may be caused by some incorrect CA on my machine -- this is an enterprise laptop and they have overriden some of the certificates. I am not sure how to use If this is the case, may I suggest a harder error / warning, rather than just returning Thanks, |
There is a |
|
Also, you can pre-download the grids: https://pyproj4.github.io/pyproj/stable/transformation_grids.html |
|
Thanks for the fast reply !
Which method has the Sorry, I am a second-hand user, haven't interacted with pyproj directly, only through geopandas. They've suggested to try this code to check if the problem comes from here: from pyproj import CRS, Transformer
from shapely.ops import transform
origin = CRS.from_user_input(df.crs)
target = CRS.from_user_input('+proj=lcc +lat_1=33 +lat_2=45 +lat_0=39 +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs')
transformer = Transformer.from_crs(origin, target, always_xy=True)
geom = df.geometry.iloc[2] # shapely.geometry causing a problem
transform(transformer.transform, geom).wkt
Thanks ! It seems to work with disabling the network, as well. Since I've never downloaded the grids, am I losing in accuracy if I disable network ? |
The
That is a possibility. It depends on the transformation. |
For some transformations, pyproj attempts to download transformation grids from the internet for improved accuracy when Transformer.transform() is called. If it fails to connect to the internet, it silently returns (inf, inf) and silently modifies its behavior to not access the internet on subsequent calls, causing them to succeed (though possibly with a loss of accuracy). See pyproj4/pyproj#705 for details. This workaround forces an error to be raised by setting errcheck=True and ignoring the first error.
For some transformations, pyproj attempts to download transformation grids from the internet for improved accuracy when Transformer.transform() is called. If it fails to connect to the internet, it silently returns (inf, inf) and silently modifies its behavior to not access the internet on subsequent calls, causing them to succeed (though possibly with a loss of accuracy). See pyproj4/pyproj#705 for details. This workaround forces an error to be raised by setting errcheck=True and ignoring the first error.
|
@rouault, I am adding you to this issue so you are aware. I haven't had time to dig into it yet, but thought that the frequency of reports was worth bringing it to your attention. |
Currently when when need to use a remote grid that can't be opened, we return HUGE_VAL coordinates values and a proj_errno = PROJ_ERR_OTHER_NETWORK_ERROR, (I guess) as expected... But if we do following proj_trans() calls on the same transformation object, the grid transformation is ignored and we fallback to other methods (Helmert, ballpark, etc.). Fix that by consistently returning the same error values as the initial failed call. Fixes pyproj4/pyproj#705
Currently when when need to use a remote grid that can't be opened, we return HUGE_VAL coordinates values and a proj_errno = PROJ_ERR_OTHER_NETWORK_ERROR, (I guess) as expected... But if we do following proj_trans() calls on the same transformation object, the grid transformation is ignored and we fallback to other methods (Helmert, ballpark, etc.). Fix that by consistently returning the same error values as the initial failed call. Fixes pyproj4/pyproj#705
Currently when we need to use a remote grid that can't be opened, we return HUGE_VAL coordinates values and a proj_errno = PROJ_ERR_OTHER_NETWORK_ERROR, (I guess) as expected... But if we do following proj_trans() calls on the same transformation object, the grid transformation is ignored and we fallback to other methods (Helmert, ballpark, etc.). Fix that by consistently returning the same error values as the initial failed call. Fixes pyproj4/pyproj#705
Currently when we need to use a remote grid that can't be opened, we return HUGE_VAL coordinates values and a proj_errno = PROJ_ERR_OTHER_NETWORK_ERROR, (I guess) as expected... But if we do following proj_trans() calls on the same transformation object, the grid transformation is ignored and we fallback to other methods (Helmert, ballpark, etc.). Fix that by consistently returning the same error values as the initial failed call. Fixes pyproj4/pyproj#705
Currently when we need to use a remote grid that can't be opened, we return HUGE_VAL coordinates values and a proj_errno = PROJ_ERR_OTHER_NETWORK_ERROR, (I guess) as expected... But if we do following proj_trans() calls on the same transformation object, the grid transformation is ignored and we fallback to other methods (Helmert, ballpark, etc.). Fix that by consistently returning the same error values as the initial failed call. Fixes pyproj4/pyproj#705
https://gis.stackexchange.com/questions/373550/first-call-to-transform-fails-with-inf-all-subsequent-calls-are-ok-what-cou
Worth looking into later.
The text was updated successfully, but these errors were encountered: