Incorrect reprojection with wkt2 string and projreprojector

Hi @r_huesken​,

I think the offset you are seeing is present in the source data. 

I extracted the source coordinate system WKT from the GeoPackage and got the following:

PROJCS["UK",GEOGCS["UK National Grid (OSTN15)",DATUM["WGS_1984",SPHEROID["ETRS 1989",6378137,298.257222096562],TOWGS84[0,0,0,0,0,0,0]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9102"]],AUTHORITY["EPSG","4326"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],PARAMETER["false_easting",400000],PARAMETER["false_northing",-100000],PARAMETER["scale_factor",0.99960127]]

This is the same coordinate system as FME is creating for _FME_0.

The datum is equivalent to WGS84, so I reprojected to WGS84 lat/long with no datum transformation, and wrote the result to Google Earth KML. When looking at the resulting file in Google Earth, it appears to show the same offset you are getting in your conversion:

PROJCS["UK",GEOGCS["UK National Grid (OSTN15)",DATUM["WGS_1984",SPHEROID["ETRS 1989",6378137,298.257222096562],TOWGS84[0,0,0,0,0,0,0]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9102"]],AUTHORITY["EPSG","4326"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],PARAMETER["false_easting",400000],PARAMETER["false_northing",-100000],PARAMETER["scale_factor",0.99960127]]

Thanks Dave,

I'm not an expert in this area, yet I expect the ProjReprojector to accept the wkt2 string provided in a separate file as the source, and use that to reproject to EPSG:3857. Apparently the Geopackage still prevails if FME does not understand the definition in the wkt2 string. Is that correct? 

This week we worked around this issue, by using the OGC WKT string for EPSG:27700 (https://spatialreference.org/ref/epsg/osgb-1936-british-national-grid/ogcwkt/). This is based on another geoid (airy), and consequently FME applies a grid shift. In this way, data is located correctly in EPSG:3857. 

I'm still wondering how this may be encoded in the wkt2 string, but luckily this is our clients responsibility (even though we try to assist them as good as possible, hence this post). Our client uses very specific geodetic parameters in some areas, so I'm afraid  it will be try and error to find a similar trick for these areas...