I have raised this before, now I have one of Australia's leading aerial imagery companies confirming my suspicion. I have also logged this with Au Support.
Using FME I have test Reprojected a vector Property boundary dataset from GDA94 to GDA2020 datum. Even though the shift has correctly taken place within FME there is a message presented at the end of the re-projection process;
WARN |MapInfo does not support datum/ellipsoid `GDA2020' -- assuming default of WGS84
When overlaying both GDA94/2020 vector Property boundary datasets you can clearly see the 1.7m +/- shift has clearly taken place. We recently have had a GDA2020 datum raster aerial imagery supplied to us and have overlaid the vector and aerial however the aerial appears to be not have moved the 1.7 metres, however the supplier of this aerial has tested in both QGIS and Global Mapper and the GDA2020 shift is represented correctly.
We are trying to plan out our Council's move to the new Datum however it seems that MI Pro V17 is not reading rasters correctly in this new datum.
Has anyone truly done any real life scenarios in translating and preparing vector and raster data in readiness to moving an entire Council's spatial data warehouse from the GDA94 to GDA2020 datum?
Please note below the findings directly from the 3rd party company who supplied aerial imagery;
“After a careful analysis I do acknowledge that there is an issue with displaying GDA2020 data in MapInfo with an on the fly projection. After analysis of the imagery in other software packages (QGIS and Global Mapper) it does seem likely that MapInfo have not properly integrated GDA2020. I do not believe that there is anything that ###### can do about this without compromising the GDA2020 definition in the ECW images, and I suggest that the client raise a support case with MapInfo directly to review the implementation of GDA2020.“
Regards,
Tony Jordan