geopandas icon indicating copy to clipboard operation
geopandas copied to clipboard

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

Open diegoperezalvarez opened this issue 1 year ago • 7 comments

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

  • [x] 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

diegoperezalvarez avatar Oct 02 '24 09:10 diegoperezalvarez

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?

martinfleis avatar Oct 02 '24 09:10 martinfleis

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

diegoperezalvarez avatar Oct 02 '24 10:10 diegoperezalvarez

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

martinfleis avatar Oct 02 '24 11:10 martinfleis

Related:

  • https://github.com/pyproj4/pyproj/discussions/1421
  • https://github.com/pyproj4/pyproj/issues/705

snowman2 avatar Oct 02 '24 12:10 snowman2

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

hamzaberradadev avatar Oct 19 '24 04:10 hamzaberradadev

https://github.com/OSGeo/PROJ/pull/4302

snowman2 avatar Nov 01 '24 17:11 snowman2

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

m-richards avatar Nov 14 '24 10:11 m-richards