Skip to main content

We use the ProjReprojector to reproject data (FME 2020.1.0.1), using a wkt string. For the UK, a special datum shift grid is specified in the wkt2 string, yet the resulting raster is not located correctly when reprojecting to EPSG:3857.

 

I'm wondering if this issue is related to FME, parameters in the wkt2 string or my (limited) knowledge in this area.

 

When reading the raster, FME reports a crs of _FME_0. I can manually set this to "OSGB-GPS-2015-OSTN15" using a coordinate system setter, yet I prefer to perform the reprojection based on the wkt2 string.

 

Can somebody please assist in how to do this with FME? Attached zip file contains the raster data, the wkt string, a document with the current (and expected) location.

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:

PROJCSl"UK",GEOGCS<"UK National Grid (OSTN15)",DATUM "WGS_1984",SPHEROIDT"ETRS 1989",6378137,298.257222096562],TOWGS8460,0,0,0,0,0,0]],PRIMEM2"Greenwich",0,AUTHORITY]"EPSG","8901"]],UNIT,"degree",0.0174532925199433,AUTHORITYr"EPSG","9102"]],AUTHORITYT"EPSG","4326"]],UNIT]"metre",1,AUTHORITY""EPSG","9001"]],PROJECTIONH"Transverse_Mercator"],PARAMETER["latitude_of_origin",49],PARAMETERl"central_meridian",-2],PARAMETER["false_easting",400000],PARAMETER""false_northing",-100000],PARAMETERa"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:

 

Screen Shot 2021-11-29 at 1.22.21 PM


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:

PROJCSl"UK",GEOGCS<"UK National Grid (OSTN15)",DATUM "WGS_1984",SPHEROIDT"ETRS 1989",6378137,298.257222096562],TOWGS8460,0,0,0,0,0,0]],PRIMEM2"Greenwich",0,AUTHORITY]"EPSG","8901"]],UNIT,"degree",0.0174532925199433,AUTHORITYr"EPSG","9102"]],AUTHORITYT"EPSG","4326"]],UNIT]"metre",1,AUTHORITY""EPSG","9001"]],PROJECTIONH"Transverse_Mercator"],PARAMETER["latitude_of_origin",49],PARAMETERl"central_meridian",-2],PARAMETER["false_easting",400000],PARAMETER""false_northing",-100000],PARAMETERa"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:

 

Screen Shot 2021-11-29 at 1.22.21 PM

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... 


Reply