No transformation found from EPSG:31256 to EPSG:4326

[ebocher]

This issue has been reported on H2 database group.
See : https://groups.google.com/g/h2-database/c/kR10UNaGs00

CTS unit for EPSGTransformTest

  @Test
    void testFrenchEPSGCodeFrom31256To4326() throws Exception {
        String csNameSrc = "EPSG:31256"; //Input EPSG
        double[] pointSource = new double[]{-38048.66 , 389405.66};
        String csNameDest = "EPSG:4326";  //Target EPSG
        double[] pointDest = new double[]{15.815805676616735 ,48.64153355841612};
        double tolerance = 10E-9;
        CoordinateReferenceSystem inputCRS = cRSFactory.getCRS(csNameSrc);
        CoordinateReferenceSystem outputCRS = cRSFactory.getCRS(csNameDest);
        verbose = false;
        double[] result = transform((GeodeticCRS) inputCRS, (GeodeticCRS) outputCRS, pointSource);
        assertTrue(checkEquals2D("EPSG:31256 to EPSG:4326 ", result, pointDest, tolerance));
    }

[ebocher]

Another issue is reported in H2GIS when a transform is created from 2249 to 4326

orbisgis/h2gis#1266

@mukoki
Can you take a look inside CTS ?
You will be much more efficient than me
Cheers

[youseeus]

the same for "from EPSG:4326 to EPSG:31467"
is there any update? i would like to use this Lib but EPSG:31467 is critical for my project

[bacek]

Same for 26911 and 3857 web merkator.

[tilovillwock]

I ran into the same problem trying to transform coordinates from 31466 to 25832. I studied the code and as far as I can tell this error occurrs when either the source or target EPSG definition have no valid towgs84 parameter. See:

• https://github.com/orbisgis/cts/blob/master/src/main/java/org/cts/datum/GeodeticDatum.java#L597
• https://github.com/orbisgis/cts/blob/master/src/main/java/org/cts/datum/GeodeticDatum.java#L598
• https://github.com/orbisgis/cts/blob/master/src/main/java/org/cts/op/CoordinateOperationFactory.java#L220

So maybe adding an updated epsg defintion file to src/main/resources/org/cts/registry fixes the problem. I haven't tested this yet though.

[MarkusProgramer]

I wanted to transform the coordinates from 4326 (WGS 84) to 31255 (Austria GK Central) and ran into the same problem.
The error is definitely caused by the missing towgs84 parameter. I also tried to add the correct towgs84 parameter in the epsg definition file but this didn't solve the problem.

The epsg:31255 has another column datum=hermannskogel. The value from this "key" is stored in the GeodeticDatum.java file.

public final static GeodeticDatum HERMANNSKOGEL = new GeodeticDatum( new Identifier("EPSG", "4312", "Militar-Geographische Institut", "MGI"), PrimeMeridian.GREENWICH, Ellipsoid.BESSEL1841, null, new GeographicExtent("Austria", 46.4, 49.02, 9.53, 17.17), "", "");

The null value is the towgs84 value. If I edit the code like

public final static GeodeticDatum HERMANNSKOGEL = new GeodeticDatum( new Identifier("EPSG", "4312", "Militar-Geographische Institut", "MGI"), PrimeMeridian.GREENWICH, Ellipsoid.BESSEL1841, SevenParameterTransformation.createBursaWolfTransformation(577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232), new GeographicExtent("Austria", 46.4, 49.02, 9.53, 17.17), "", "");

the transformation doesn't throw an error but returns completely wrong values.
Hope someone finds a solution.

[ebocher]

Thanks a lot for feedbak.
Currently we have no time and no ressources to fix this issue, so any PR are welcome !
Sorry for that.

[MarkusProgramer]

I finally found the problem.
You have to edit the code like I mentioned before in the GeodeticDatum.java file. I only forgot to delete some test code.

public final static GeodeticDatum HERMANNSKOGEL = new GeodeticDatum( new Identifier("EPSG", "4312", "Militar-Geographische Institut", "MGI"), PrimeMeridian.GREENWICH, Ellipsoid.BESSEL1841, SevenParameterTransformation.createBursaWolfTransformation(577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232), new GeographicExtent("Austria", 46.4, 49.02, 9.53, 17.17), "", "");

Instead of null you have to call the method SevenParameterTransformation.createBursaWolfTransformation(). The parameters for the specific transformations can be found in the internet. This should be done for all frames of reference.

[ebocher]

Fix done in CTS see #147
Note that NAD83 is not yet supported yet.

[ebocher]

See #127