Hello FME Folks,
This is related to MapInfo Tab files. Since we upgraded from FME 2018 to FME 2024.2.1. The MapInfo coordinate System (Non Earth Meters) are not detected which used to happen in FME 2018. Instead it is taking wkt_auto_1 and is misaligned. Please let me know what changed.
Solved
MapInfo transformation not reading right Coordinate System
+4- Contributor
Best answer by daveatsafe
Hi
Thank you for the files.
FME is not recognizing the coordinate system read from Oracle, either by the SRID or the WKT definition, due to the unknown Datum name. FME 2018 just gives up and assigns a Non Earth coordinate system, while FME 2024 works a little harder and creates an appropriate coordinate system with an unknown datum. However, there is no way to set the unknown datum when writing a Mapinfo coordinate system, so the default WGS 84 datum is used.
The original datum is NAD 83 with a slightly different name, so there is some difference in the resulting Mapinfo coordinate system that may cause some offset.
The best solution would be to add a coordinate system exception to map the Oracle SRID to the correct coordinate system, which is 3TM114-83. I have created the necessary exception for you in the attached zip file. Please unzip the attachment, then use the FME Flow web interface to upload the resulting .db to Resources/Engine/CoordinateSystemExceptions. You may need to restart FME Flow for this change to take effect.
Once this exception is added, the Oracle data will automatically have the correct coordinate system when read, and this will propagate to the output Mapinfo file.
1 person upvoted this
+36- Influencer
FME understands “real-world projections” using CS-Map libraries, using https://docs.safe.com/fme/html/FME-Form-Documentation/FME-Form/Workbench/How_FME_Identifies_Coordinate_Systems.htm so for the majority of MapInfo and EPSG number or LL-MAPINFO for LL WGS84
Ypu can convert a non-earth projection (metres) to a real-wold projection referring to this knowledge article https://customer.precisely.com/s/article/Converting-a-map-in-non-earth-projection-to-a-real-world-projection-using-MapInfo-Professional?language=en_US
Why FME has dropped this, I’m unsure but hopefully some at Safe software can say
1 person upvoted this
+19- Safer
Hi
Would you be able to share a simple dataset to illustrate this problem?
1 person upvoted this
+4- Contributor
Hi
Sure, I can but I am unable to add here. Is there a another to just transfer to you.
I will add both FME 2018 and FME 2024 files along with logs.
Thanks,
+19- Safer
- Best Answer
Hi
Thank you for the files.
FME is not recognizing the coordinate system read from Oracle, either by the SRID or the WKT definition, due to the unknown Datum name. FME 2018 just gives up and assigns a Non Earth coordinate system, while FME 2024 works a little harder and creates an appropriate coordinate system with an unknown datum. However, there is no way to set the unknown datum when writing a Mapinfo coordinate system, so the default WGS 84 datum is used.
The original datum is NAD 83 with a slightly different name, so there is some difference in the resulting Mapinfo coordinate system that may cause some offset.
The best solution would be to add a coordinate system exception to map the Oracle SRID to the correct coordinate system, which is 3TM114-83. I have created the necessary exception for you in the attached zip file. Please unzip the attachment, then use the FME Flow web interface to upload the resulting .db to Resources/Engine/CoordinateSystemExceptions. You may need to restart FME Flow for this change to take effect.
Once this exception is added, the Oracle data will automatically have the correct coordinate system when read, and this will propagate to the output Mapinfo file.
1 person upvoted this
Reply
Rich Text Editor, editor1
Editor toolbars
Press ALT 0 for help
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.