Global Mapper Pro Coming Soon

ETRS89 WGS84

HowardHoward Global Mapper UserPosts: 13

To make sure I understood how GM is handling datums, I loaded a csv file of lat/lon points and set WGS84 as datum.

Then I loaded the same set but as OSBG36. There is then the expected separation owing to the different datums.

But then I loaded the same set a third time but as ETRS89. I was surprised to see the points are identical to WGS84.

As I understand it, WGS84 is moving apart from ETRS89 at about 2.5cm/year so I expected about 60cm separation or more.

Have I missed something here?

Howard


Comments

  • JohnoJohno Posts: 9
    The transformations parameters used can change each version, the current V22.1 parameters are here: Supported Datums (bluemarblegeo.com)

    However don't get hung up on the details, the list looks sophisticated but Global Mapper doesn't do a very good job here and actually over simplifies many relationships hanging on to expired baggage and as a result can actually introduce more serious errors in other newer datums. 

    You can see in the table your ETRS89 is simply locked by GM to GRS80 (WGS84) with a "0" transformation which reflects the original release date. E.g. where your plate happened to be floating on the planet back then, not where you have moved to now. Unless you are in Italy where it uses NTv2 conversion tables but also be careful reading too much into that without checking.

    For example GM also uses NTv2 conversion tables for the new Australian GDA2020 datum which was released to realign us to coincident with WGS84 again. However you can also see our earlier GDA94 has been left locked to WGS84 with a "0"  transformation and they can't both be there. Our NTv2 tables were developed only to transform legacy data sets from GDA94 to GDA2020 (with no relationship to WGS84) and unfortunately GM incorrectly applies them for GDA2020 against it's internal reference datum WGS84 and as a result this has a reverse effect and introduces an error pushing the new GDA2020 a whole 1.5m away from WGS84.

    I've gotten around these issues by using custom datums to reflect specific dates (epochs) but locating and calculating the transformation parameters and implementing them in GM is not for the feint hearted.

    Otherwise Geographic Calculator apparently handles dynamic time dependent transformations if you want to spend the dollars, I don't know if the new GM Pro version will have better functionality.

    Otherwise QGIS does a much better job with this and it's free so you could cycle your transformations through that.





  • HowardHoward Global Mapper User Posts: 13
    Many thanks for that, it clears up a real puzzle.

Sign In or Register to comment.