BUG: to_crs returns inf on first call. second call correct

[diegoperezalvarez]

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of geopandas.

• (optional) I have confirmed this bug exists on the main branch of geopandas.

---

Code Sample

import geopandas as gpd
import shapely

print(
    gpd.GeoDataFrame(
        geometry=[shapely.geometry.Point(-100,40)], crs='EPSG:4326')
    .to_crs('ESRI:102008')
)
# Exactly the same command
print(
    gpd.GeoDataFrame(
        geometry=[shapely.geometry.Point(-100,40)], crs='EPSG:4326')
    .to_crs('ESRI:102008')
)

Output:

          geometry
0  POINT (inf inf)
                       geometry
0  POINT (-321422.376 6782.160)

Problem description

Sorry if this is a duplicate, I've just experienced the same issue and thought I'd raise it here. Hope I've done this correctly.

See:

• https://stackoverflow.com/questions/78050786/why-does-geopandas-to-crs-give-inf-inf-the-first-time-and-correct-resul
• https://gis.stackexchange.com/questions/373550/first-call-to-transform-fails-with-inf-all-subsequent-calls-are-ok-what-cou

I run to_crs() once, and it returns inf geometry. I run it a second time, and it works. (?)

Original question: when I run geopandas' .to_crs() function twice in a row on the same inputs, I get two different results.

I also explicitly set:

import os
os.environ['PROJ_NETWORK'] = 'OFF'

Following the recommendations of the second source, but this didn't fix the issue.

Expected Output

Should be the same with each run.

SYSTEM INFO

python : 3.12.6 | packaged by conda-forge | (main, Sep 30 2024, 17:48:58) [MSC v.1941 64 bit (AMD64)]
executable : c:\Users\User\AppData\Local\miniforge3\envs\otp\python.exe
machine : Windows-11-10.0.22631-SP0

GEOS, GDAL, PROJ INFO

GEOS : 3.13.0
GEOS lib : None
GDAL : 3.9.2
GDAL data dir: C:\Users\User\AppData\Local\miniforge3\envs\otp\Library\share\gdal
PROJ : 9.5.0
PROJ data dir: C:\Users\User\AppData\Local\miniforge3\envs\otp\Library\share\proj

PYTHON DEPENDENCIES

geopandas : 1.0.1
numpy : 2.1.1
pandas : 2.2.3
pyproj : 3.6.1
shapely : 2.0.6
pyogrio : 0.10.0
geoalchemy2: None
geopy : None
matplotlib : 3.9.2
mapclassify: 2.8.1
fiona : None
psycopg : None
psycopg2 : None
pyarrow : None

[martinfleis]

This is certainly related to some behaviour of pyproj, so it should be likely reported there. We're just calling the same code twice from within geopandas.

Maybe @snowman2 has a clue what is happening?

[diegoperezalvarez]

Ah, my bad. Is there a way I could move the issue over or should I leave it open here?

[martinfleis]

Keep it open, we can link from here to the issue in pyproj and close it once resolved there.

[snowman2]

Related:

• First call failiure using transform but then it works? - unsure if it's a bug or something else pyproj4/pyproj#1421
• PROJ_NETWORK: First transform fails, succeeds afterwards pyproj4/pyproj#705

[hamzaberradadev]

Based on pull request #2259 in the azavea/raster-vision repository, the code attempts to download transformation grids from the internet. If the download fails, it returns infinity (inf, inf) for the coordinates and avoids further attempts to download the same transformation grids. This suggests there might be an issue with the server hosting the grids, making them temporarily unavailable, or the specific transformation grids may not exist.

To resolve the issue upgrade the pyproj >= 3.7.0

[snowman2]

OSGeo/PROJ#4302

[m-richards]

I'm going to re-open this for now, we can close when it trickles down into a pyproj release