ST_Transform return empty geometry when PROJ coords are Inf

[latot]

Describe the bug
Hi, by accident someone wrote a weird point, using a real number very big, the issue is that the output with ST_Transform was a empty geometry...

An empty geometry is a valid geometry, with a clear geometry interpretation, so we are moving from a weird point to a completely different object.

I tested this example on PROJ and GEOS using python.

PROJ: returned coords (inf, inf)
GEOS: panic! stop and reports an error, also shows PROJ returned inf

Other one tested on GDAL, and it returns NULL.

Stop the app, NA, NULL any of this values would be fine, but a empty geometry really breaks the logic and introduces bugs on the workflows.

Thx!

To Reproduce

p <- sf::st_sfc(sf::st_point(c(1e+300, 1e+300)), crs = 4326)
sf::st_transform(p, 32719)
Geometry set for 1 feature  (with 1 geometry empty)
Geometry type: POINT
Dimension:     XY
Bounding box:  xmin: NA ymin: NA xmax: NA ymax: NA
Projected CRS: WGS 84 / UTM zone 19S
POINT EMPTY

Additional context
Add any other context about the problem here.

> sessionInfo() R version 4.4.3 (2025-02-28) Platform: x86_64-pc-linux-gnu Running under: Gentoo Linux

Matrix products: default
BLAS: /usr/lib64/libblas.so.3.12.0
LAPACK: /usr/lib64/liblapack.so.3.12.0

locale:
[1] LC_CTYPE=es_CL.utf8 LC_NUMERIC=C
[3] LC_TIME=es_CL.utf8 LC_COLLATE=es_CL.utf8
[5] LC_MONETARY=es_CL.utf8 LC_MESSAGES=es_CL.utf8
[7] LC_PAPER=es_CL.utf8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=es_CL.utf8 LC_IDENTIFICATION=C

time zone: Chile/Continental
tzcode source: system (glibc)

attached base packages:
[1] stats graphics grDevices utils datasets methods base

loaded via a namespace (and not attached):
[1] compiler_4.4.3 magrittr_2.0.3 class_7.3-23 tools_4.4.3
[5] DBI_1.2.3 units_0.8-7 proxy_0.4-27 Rcpp_1.0.14
[9] KernSmooth_2.23-26 grid_4.4.3 e1071_1.7-16 classInt_0.4-11
[13] sf_1.0-21

sf::sf_extSoftVersion()
GEOS GDAL proj.4 GDAL_with_GEOS USE_PROJ_H
"3.13.0" "3.9.3" "9.4.1" "true" "true"
PROJ
"9.4.1"

[edzer]

The documentation of st_transform() says: Features that cannot be transformed are returned as empty geometries. . So what exactly is the bug?

If anything

p <- sf::st_sfc(sf::st_point(c(1e+300, 1e+300)), crs = 4326)

could have caused an error, but that would come at some performance cost too. You'd hope that normal workflows start with sound data.

[latot]

That depends a lot on the context, some of them yes, all the point would be fill, but in others empty data is also right.

I did not read that part of the docs! sounds a very controversial feature, there is no other way to handle things that can not be transformed?

[edzer]

Many transformation work only for a part of the world, think orthographic. Raising errors when using them on every geometry for which they do not work would be more disruptive, and hard work to get things work only for those geometries that can be transformed. (Getting orthographic to work is hard anyway, see here for an example)

[latot]

right, is not like all projections works flawlessly, about the disruptive behavior, in my perspective not throw the error is more disruptive.

If something do not works, one of the worst scenarios is the code to continue. Stop the program and know the actual operation is not fine, let us know it to be able to do something about it.

Well, I think the hardest part is not if stop or not, is return a empty geom, which is at interpretation level valid, we can't know from the output if something failed or not...

Is possible instead a empty geom NA, NULL or something like that? when a op fails, we need to know what worked and what failed to know what to do next with the data.

[edzer]

NA or NULL are not valid entries in an sfc object; st_is_empty() helps you identify empty geometries.

[latot]

so, a safe st_transform would be something like

pre_trans <- sf::st_transform(data, crs)
errors <- sf::st_is_empty(pre_trans) & !sf::st_is_empty(data)

Rn, I think is better avoid this type of behavior, just because in general, is too hard remember know all possible exceptions to all functions in all libs and languages we know, and more in cases like this one where this could possible hide bugs in workflows than raise them.

A non-breaking option would be something like a st_transform_safe which can panic, but the naming is hard.. because the actual st_transform do not follow the usual behavior, but replace the actual one seems more disruptive then open a safe one

I think have a new safe function like that could also be an option, helps to use know "the actual st_transform" can return invalid things (then we can look to know how they are returned and know they are empty geoms), and the safe one to when we want just safe transformations.

could have caused an error, but that would come at some performance cost too

Right, but I don't know how much ppl would like performance when the output can be invalid and unsafe to use.
From the ppl I know that knows R, I don't know anyone who knows a empty geom is an error, yes is in the docs, but is hard to get and remember :(