PROJ 6 issues with +init=epsg:2056 (CH1903+/LV95)

[dg0yt]

Using the old API with PROJ 6 instead of 4.9.3, we noticed wrong transformation results between EPSG:4326 and EPSG:2056 (CH1903+/LV95) (OpenOrienteering/mapper#1325). Even after switching to the new API (with legacy proj4 init rules enabled), results are correct only if the no_defs parameter is not used. Despite all the legacy stuff: This is a clear regression which should not happen at least when using the old API.

I was now able to create a test executable which uses the EPSG:2056 center of projection for demonstration. Note that only the last line is matching the expected results.

expected:    	2600000.00	1200000.00
pj_transform:	2599927.44	1199852.66	(+init=epsg:2056 +no_defs)
pj_transform:	2599927.44	1199852.66	(+init=epsg:2056)
pj_trans:    	2599927.44	1199852.66	(+init=epsg:2056 +no_defs)
pj_trans:    	2599999.82	1199999.69	(+init=epsg:2056)

proj-test.zip (updated)

[rouault]

@dg0yt Potential fixes in #1600 . Note however as indicated in the PR that the commit really fixing your issue could be controversial. Basically one cannot expect PROJ6 to be perfectly backward compatible with previous PROJ versions. Hence the deprecation for the +init=epsg:XXXX syntax. Using proj_create_crs_to_crs(ctx, "EPSG:4326", "EPSG:2056", NULL) is the strongly recommended way of proceeding. Or fully expand the +init=epsg:XXXX to their "+proj= ...." content including +towgs84 clauses.
I'd note that, to make PR #1600 really work with your .cpp file you should change the setting of the 'c' argument passed to proj_trans() to initialize the z value as well, otherwise that can affect geographic <--> geocentric conversions if the z is some random value :

	c.lpz.lam = x;
	c.lpz.phi = y;
        c.lpz.z = 0;

[dg0yt]

you should change the setting of the 'c' argument passed to proj_trans() to initialize the z value as well, otherwise that can affect geographic <--> geocentric conversions if the z is some random value

Thanks for the hint. IIUC this also needs to be added to the migration documentation, because this is where the code comes from, except for not using scanf. And the example would need this in the loop body (or better do not overwrite c at all, to highlight the pure function style in the new API).

[rouault]

Thanks for the hint. IIUC this also needs to be added to the migration documentation, because this is where the code comes from

we'd welcome if you could submit a PR for that

[dg0yt]

Basically one cannot expect PROJ6 to be perfectly backward compatible with previous PROJ versions. Hence the deprecation for the +init=epsg:XXXX syntax. Using proj_create_crs_to_crs(ctx, "EPSG:4326", "EPSG:2056", NULL) is the strongly recommended way of proceeding. Or fully expand the +init=epsg:XXXX to their "+proj= ...." content including +towgs84 clauses.

I do understand that, and maybe it is best to leave it as it is. However, I see software being recompiled with the macro enabling the deprecated API, e.g. for the Debian proj transition, and this error has the potential to go unnoticed for a while. (Even the Potsdam bug in the new API seems to have gone unnoticed for a while.)

[rouault]

We've finally decided not to try to fix the pj_transform() use case, but rather document it: 73042b0