PROPOSAL: proj_create_crs_to_crs best only mode

[snowman2]

Note: Not a high priority, just wanted to share the idea and see what others think about it.

Have a mode when creating a conversion between CRS which raises an error when the best transformation is not available. The default behavior for PROJ would remain unchanged.

The error could redirect users to relevant documentation so the issue could be addressed.

Currently pyproj has a warning for this scenario when user use TransformerGroup ref.

[jjimenezshaw]

Hi @snowman2 , how would you define the "best" transformation? What happens if that changes in time?
I have seen authorities that release new transformations for same source-destination, or even update an existing one (and users say "hey, this changed, which one is wrong?"). Maybe they have a grid, but the associated transformation is not in epsg. (This is very common for vertical systems). Or that grid is not open source. I see a lot of corner cases.

Also I think that such a method would give a false sensation of "security", without understanding what is really happening.

You can add the confusion added by the wgs84 ensemble.

[rouault]

Candidate implementation in #3535

[oleg-alexandrov]

I think a clear-cut case is the following. If a certain CRS transform needs a grid (either a local one or from the net), and it can't find that grid, PROJ should fail, plain and simple. As of now it seems to be happy to silently continue producing different results.

Here is an example. I have a DEM with projection '+proj=utm +zone=10 +datum=NAD27 +units=m +no_defs'.

Using gdalwarp (GDAL 3.5.3, released 2022/10/27) with network off:

export PROJ_NETWORK=OFF; gdalwarp -t_srs '+proj=utm +zone=10 +datum=WGS84 +units=m +no_defs' dem.tif dem_OFF.tif

Then with network on:

export PROJ_NETWORK=ON; gdalwarp -t_srs '+proj=utm +zone=10 +datum=WGS84 +units=m +no_defs' dem.tif dem_ON.tif

The tool is happy either way. In the first case, gdalinfo says:

Origin = (666462.102166696102358,4110627.121492974460125)

In the second case:

Origin = (666459.040349920513108,4110630.317898528184742)

If I call libproj from my own tool with proj debugging on, when the network is enabled it says:

Using https://cdn.proj.org/us_noaa_conus.tif

With the network off, that doesn't happen and results again differ.

[pramsey]

I lived long enough in the world where Bursa Wolf transforms were frequent to not think that NAD27/83 transformations have to fail in the absence of a shift grid. There's no right answer and there are lots of estimates of differing quality. We got used to, in the pre-network era, having a minimal complement of grids installed by default, which gave the false impression that a certain level of accuracy was always going to be there by right. Now things are much better but not necessarily by default. That probably leaves a larger gap to fall into than we had before. Depends, actually, a lot on packagers, but they probably don't feel safe slipping "PROJ_NETWORK=ON" into the system environment on install. So the default behaviour of the library is a little worse than it was in the pre-network days. I'm not sure this is a complaint, just more of an observation.

[hobu]

Packagers should utilize projsync as part of their packaging strategy. They can break things up however they want to try to limit the size and geography.

PROJ_NETWORK=ON is for people running Jupyter notebooks and lambda functions. People can also point at their own custom CDN if that's something they want to do, but it isn't worth the trouble except for extreme cases (air-gapped networks or something)