1.9.6 and 2.1.0 behave differently in case of impossible transformation

[drnextgis]

I'm not sure that this is a right place for this issue but anyway the following code works fine with pyproj 1.9.6:

>>> import pyproj
>>> from functools import partial
>>> from shapely.geometry import Polygon
>>> from shapely.ops import transform
>>> 
>>> project = partial(
...     pyproj.transform,
...     pyproj.Proj(init='epsg:4326'),
...     pyproj.Proj(init='epsg:3857'))
>>> 
>>> g1 = Polygon([(-180, -90), (-180, 90), (180, 90), (180, -90), (-180, -90)])
>>> g2 = transform(project, g1)
>>> print(g2)
POLYGON ((inf inf, inf inf, inf inf, inf inf, inf inf))
>>> pyproj.__version__
'1.9.6'

but fails with the recent 2.1.0:

>>> g2 = transform(project, g1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/denis/satellogic/env/lib/python3.6/site-packages/shapely/ops.py", line 234, in transform
    zip(*func(*izip(*geom.exterior.coords))))
  File "/home/denis/satellogic/env/lib/python3.6/site-packages/pyproj/transformer.py", line 307, in transform
    return Transformer.from_proj(p1, p2).transform(x, y, z, radians)
  File "/home/denis/satellogic/env/lib/python3.6/site-packages/pyproj/transformer.py", line 151, in transform
    self._transformer._transform(inx, iny, inz, radians)
  File "pyproj/_transformer.pyx", line 149, in pyproj._transformer._Transformer._transform
pyproj.exceptions.ProjError: proj_trans_generic error: tolerance condition error

Maybe @sgillies has some thoughts how to deal with it.

[snowman2]

That is a PROJ error being raised. It is likely due to changes in version 6.0.0. @kbevers @rouault. I think the solution is to use 89.99999 instead of 90 etc. for the points.

[rouault]

For webmercator, when latitudes tend to 90 deg, northing tend to infinity, so using 89.9999 is not the solution. The recommended area of use of EPSG:3857 is for latitudes between -85 and 85 degrees

[snowman2]

Thanks for the clarification!

[jswhit]

I can imagine some cases where a return value of inf or NaN would be preferred over an exception. Should we add a flag that enables this?

[snowman2]

Future reference, the area of use can be determined from the CRS class https://pyproj4.github.io/pyproj/html/api/crs.html#pyproj-crs.

[snowman2]

I can imagine some cases where a return value of inf or NaN would be preferred over an exception. Should we add a flag that enables this?

I agree this would be nice for the case where arrays have a subset of values inside the valid range. With the current version of PROJ I am not sure if this flag exists. If not, would it be something that y'all would be willing to add?

[snowman2]

Maybe we could allow the user to override the area of use in proj_create_crs_to_crs: https://proj4.org/development/reference/functions.html#area-of-interest?

[drnextgis]

The problem is there is no universal way to check possibility of transformation that can be used across different pyproj versions.

[snowman2]

The exception being raised inherits from RuntimeError link, so you could wrap that in a try/except block and will be backwards compatible I think.

[drnextgis]

The thing is in pyproj 1.9.6 according to my example exception is not raised.

[jswhit]

#203 restores the 1.9.6 behavior. Optional kwarg errcheck can be set to raise the exception instead.