MapInfo Pro

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

Hi Tony,

This problem may be specific to the ECW format only. I haven't spent much time investigating yet, but it seems that whilst MapInfo might struggle to read the georeferencing information that is embedded within the ECW itself, it is able to read the .eww world file that usually accompanies the ECW. Have you been able to try that approach?

Thanks James for the feedback..

MI doesn't seem to read/open .eww files, unless i'm doing something wrong. So I tried opening the ers, and it doesn't make any difference to the alignment.

I am happy to supply any readers here the .ecw raster/aerial (6.3Gb) and accompanying .ers. eww .prj .ghx and .tab files along with the Property vector layer for others to test and experience...

Tony

A breakthrough! I have made a finding, below are the steps..

Using FME I re-projected a MI tab file (cadastral property layer) from GDA94 Zone54 (EPSG:28354) using the 'csmapReprojector' directly into an ESRI shp file into the new Australian datum GDA2020 Zone54 (EPSG:7854).

Using the latest version of ArcGIS Pro opened the ecw raster aerial imagery (directly reading from the ecw) in which a leading Australian aerial mapping specialist has created with the GDA2020 datum, then proceeded to open the cadastral property layer in which was re-projected in FME, and the finding is a perfect match, the property boundaries align with the same on the aerial imagery, there is no 1.7m +/- discrepancy...

An interesting fact is I have just tested while writing this post, the fact that if you use MI Pro to open that same ESRI shape file it also aligns perfect with the aerial raster! I note that the FME reprojection was done exactly the same for creating the reprojected tab file as well as shape file.

Thoughts??

Hi Tony,

Thank you for logging issue with PB Support.

We are investigating on the issue you reported and share the update.

Regards,

Ruchi