FeatureJoiner and differences between OSGB 2015 coordinate systems (ArcSDE and File GeoDatabase)

I believe it's a matter of precision, here's an except from some content we've issued to a couple of our customers:

British National Grid

In the default FME reprojection engine datum transformations to WGS84/ETRS89 are tied to the coordinate systems. The old BritishNationalGrid coordinate system was tied to a transformation that is no longer current and has been replaced with:

OSGB-GPS-1997 --> uses OSTN97 parameters to/from ETRS89 or WGS84

OSGB-GPS-2002 --> uses OSTN02 parameters to/from ETRS89 or WGS84

OSGB-GPS-2015 --> uses OSTN15 parameters to/from ETRS89 or WGS84 (the default choice new in FME 2017.0)

Which you use is dependent on when the data was captured and if you will be reprojecting in the workspace. Safe highlight that the only difference between the OSGB-GPS coordinate systems is the inherent datum transformation from OSGB36 to WGS84.

The reasons for the multiple transformations:

• Plate Tectonics - The OSGB36 datum is tied to the British Isles, while WGS84 is a worldwide datum, with tectonic plate movements the transformation between OSGB and WGS84 will change slightly.
• Quest for Greater Accuracy - When the best GPS resolution was in the meter range, the older less accurate conversion (used by BritishNationalGrid) between its WGS84 coordinates and OSGB was sufficient. Now that GPS resolution is much higher, a more accurate transformation is needed.

The advice is…

• If you are not reprojecting the data within FME, you can use EPSG:27700 without worrying about the other coordinate systems.
• If you are reprojecting the data to WGS84 or ETRS89, Safe would recommend using the GridInquestIIReprojector since it has the highest accuracy transformation (new in FME 2017.0). (OSGB-GPS-2015 --> uses OSTN15 parameters to/from ETRS89 or WGS84 uses the NTv2 approximation very close (<1mm) to the full OSTN15 transformation. The full OSTN15 transformation is available in the new GridInQuestIIReprojector transformer).

There was a slight issue…

In addition to these coordinate systems, FME 2017.0 introduced one other approximation which was inadvertently applied to any conversion between WGS84 and OSTN15. This was fixed in FME 2017.0 hotfix build 17275. The issue was that approximation in the seven-parameter transform described here - https://www.ordnancesurvey.co.uk/docs/support/guide-coordinate-systems-great-britain.pdf - is only good to a 3.5m accuracy. The intent was to use this instead of the BritishNatGrid approximation (which is slightly worse) in one narrow edge case: Workspaces authored prior to FME 2013, which reference British National Grid via "EPSG:27700" or some other exception mapping, and which have not been updated to set "Workspace Parameters -> Translation -> Implicit CS-MAP Reprojection Mode" to "Auto".

I hope that helps.

Hi @tim_wood,

The reason for the differing coordinate system names is that when reading an Esri dataset, FME attempts to match the WKT in the data with WKT mappings stored in FME. If the WKT does not match FME's default mapping, but is still recognized, we create a custom coordinate system with name based on the matched coordinate system (ie. '_OSGB-GPS-2015_0').

This custom coordinate system contains the original WKT, so that if we write back to an Esri dataset, we will use that WKT, ensuring that an Esri -> Esri conversion does not change the coordinate system.

However, this does appear to be causing problems in the FeatureJoiner. I have created a problem report for the development team, and will notify you as soon as it is fixed.

In the meantime, you can use the suggestions from @takashi to avoid the problem.