• Home
  • Forums
  • FME Form
  • Data
  • FeatureJoiner and differences between OSGB 2015 coordinate systems (ArcSDE and File GeoDatabase)
Solved

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

tim_wood
Rank
Badge +7

FME 2018.0.1.0 64-bit (18310).

I'm using FeatureJoiner to merge data coming from several ArcSDE layers (left) and 2 layers from 2 different File Geodatabases (right). ALL the source layers are British National Grid (27700), but the coordinate system parameter in the Readers was <not set>. The translation failed at the FeatureJoiner with the message "Rejecting input feature(s) with coordinate system 'OSGB-GPS-2015' that do not match the first feature coordinate system '_OSGB-GPS-2015_0'".

If I set the coordinate system to "OSGB-GPS-2015" on all the Readers, the translation works with this warning: "NOT changing coordinate system of reader identified by keyword `GEODATABASE_SDE_1' from `OSGB-GPS-2015' to `_OSGB-GPS-2015_0' -- mapping file setting of `OSGB-GPS-2015' overrides coordinate system `_OSGB-GPS-2015_0' read from file"

Is there any real difference in OSGB-GPS-2015 and _OSGB-GPS-2015_0? Or is FeatureJoiner just getting upset because the coordinate system name is not identical? Should I put a Reprojector in front of it for one set of layers? Should FeatureJoiner have some coordinate system handling parameters (e.g. ignore differences)?

icon

Best answer by davideagle 2 July 2018, 18:32

View original

5 replies

davideagle
Rank
Badge +10

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.

tim_wood
Rank
Badge +7

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.

Thanks. I'm going to go for "If you are not reprojecting the data within FME, you can use EPSG:27700 without worrying about the other coordinate systems"!

 

 

I guess it's better for the translation to fail and the user to specify coordinate systems explicitly or re-project as appropriate than for the FeatureJoiner to treat them as the same...

 

takashi
Rank
Userlevel 2
Badge +17

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.

daveatsafe
Rank
Userlevel 2
Badge +17

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.

tim_wood
Rank
Badge +7

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.

Thanks @DaveAtSafe. I'll see how things work out with the coordinate system set on the Readers and implement the workaround if we get any issues. I'm dropping the geometry from the File Geodatabase layers in the FeatureJoiner (Geometry Handling: Use Left) anyway.

 

Reply


Community Stats

28,652
Posts
109,276
Replies
36,527
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.