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.

If you just want to prevent the rejection caused by the difference in coordinate system between Left features and Right features, try removing coordinate system definition from both Left and Right with the CoordinateSystemRemover before joining. You can also extract and save the coordinate system as an attribute with the CoordinateSystemExtractor before removing, and then restore it with the CoordinateSystemSetter after joining, if necessary.

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.