Global Mapper v25.0

Apparent Projection Conversion Error - UTM to British Grid

Adrian Charters
Adrian Charters Global Mapper User
edited March 2012 in Technical Support
Hi, I am working on a large offshore windfarm project proposed for the south coast of England. The developer has given the project area in UTM Zone30N WGS84 coordinates. I have used GM to convert these to British Grid, Ordnance Survey 1936 datum (OSGB36) to use with OS mapping products. Checking with other colleagues on the project it appears I have errors of 81-86m on the eastings and northings conversion. They undertook the conversion using other conversion software including MSP Geotrans 3.2 and have independantly got the the same answers. Some sample points I have converted with GM are as follows:

(UTM) 582529 5583019 TO (OSGB36) 411449.5 54931.5 MSP Geotrans 411547 54849

I dont see any other settings in GM that I can change, does anyone have an idea where the apparent error is coming from ? Looking at the projection file (.prj) for the British Grid, Ordnance Survey 1936 datum the ellipsoid is Airy 1830. I have attached the .prj file

Many thanks, Adrian

MSP Geotrans.jpg
















Comments

  • global_mapper
    global_mapper Administrator
    edited March 2012
    Adrian,

    Global Mapper uses a NTv2 grid shift file for OSGB36 datum conversions. While this is more accurate than the NTv2 grid shift for most locations, it appears that this grid shift file is very inaccurate for off-shore locations. I have fixed this by doing both the grid shift and 7-parameter transform and only using the grid shift if it is reasonably close to the 7-parameter transform. With this I get within about a meter of what GeoTrans reports. I have placed a new build at http://www.globalmapper.com/global_mapper13.zip with the latest changes for you to try. Simply download that file and extract the contents into your existing v13.xx installation folder to give it a try. If you are using the 64-bit v13 version there is a new build at http://www.globalmapper.com/global_mapper13_64bit.zip .

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • tjhb
    tjhb Global Mapper User Trusted User
    edited March 2012
    Mike is this wise? What is the officially-supported transformation method? If it is NTv2, but for offshore work NTv2 gives a worse result than a 7-parameter transform, then wouldn't it be better to give users the option (which I think is already there?) to use the 7-parameter transform in preference to an NTv2 shift?

    Introducing a new, compromise projection strategy might create more problems than it's worth, I think, mostly because there is no hope of exactly replicating the result (or reversing it) in any other software, which will make it very hard to play nicely with others.

    Where topology is concerned, an exactly reproducible, reversible and verifiable result, by a known process, is much more important than a "more accurate" one. Especially when it is within the user's control to select a different (known) method as suits the particular purpose.

    Tim
  • global_mapper
    global_mapper Administrator
    edited March 2012
    Tim,

    What I'm trying to do is just make it work as good as possible by default as the vast majority of users don't have the knowledge necessary to really know what a datum is, let alone choose which of a set of transformations for a single datum is the one that will match other software. It seems that some software uses the NTv2 transformation and other the 7-parameter transform (probably even some using the really bad 3-parameter one too).

    I could add another datum that specifically uses the 7-parameter transformation all the time, but I'm afraid this would confuse users that are just told to choose OSGB36 for their datum as most will have no idea what NTv2 or 7-parameter mean or which they should use. Those users that actually know that they need a 7-parameter transformation can always add a custom datum using those parameters.

    My main goal is just to use the best available transformation for any given location by default, especially when the difference is 10s of meters like it was in this case, so the error is very significant for a large number of applications. It is not acceptable to use a datum transformation with that size of real-world error. Your results should be reproducible exactly and reversible if you are working in Global Mapper, so all topology should be maintained so long as all transformations are done in the same software. If different software is used even if they use the exact same transformation method the results could be slightly different based on order of operations, round-off, etc., although the results will of course be much closer.

    Thanks,

    Mike
  • tjhb
    tjhb Global Mapper User Trusted User
    edited March 2012
    It seems that some software uses the NTv2 transformation and other the 7-parameter transform (probably even some using the really bad 3-parameter one too).

    Too right! In ArcGIS Desktop there is a drop-down box to choose the shift/transformation method to be used in reprojection/datum change. The box has one item visible (as drop-down boxes do) and guess what comes first? It's sorted alphanumerically! (As they tend to be.) Occasional users will typically just leave the box alone (reasonably enough), in effect picking the first method, the only method they can initially see, which is a 3-parameter transform. A truly nasty bit of UI design, with very messy consequences. (A combo box would be much better since then at least more than one option would be visible and people would be more likely to look at the manual or ask for help. But ideally NTv2 should be listed first, to datums for which it applies.)
    Your results should be reproducible exactly and reversible if you are working in Global Mapper, so all topology should be maintained so long as all transformations are done in the same software.

    This isn't an acceptable thing to aim for Mike. Sorry to be so frank, but it's not. Not even bad old ESRI would think that it was. Nor is it in accord with reality: data typically flows through several pieces of software in any given workflow—and then the client is quite likely to use something else again.
    If different software is used even if they use the exact same transformation method the results could be slightly different based on order of operations, round-off, etc., although the results will of course be much closer.

    True, but that doesn't change the principle, the proper aim, one bit.

    One reason for the existence of the NTv2 grids is so that datum conversion can be standardised, and results can be made predictable, even after round-tripping, and even if projections are carried out by different pieces of software (and for that matter on different processor architectures). I think I'd be right in saying that NTv2 grid shifts will be much less susceptible to implementation differences than parameter-based transforms.

    What I really don't think is helpful is for a user to believe (with good reason) that a standard NTv2 shift is being used—which generally means complying with an official standard—when in fact a heuristic is being implemented to check that the result makes sense, and if it doesn't seem "reasonable", to switch to something better. There's a good intention behind that, but I really think it's going to cause more trouble than it's worth.

    A grid is either in use, or it's not. If the result of a grid shift compares badly with some other method, well, that could be grounds for revising the grid (in an extreme case), or it could be grounds for a user-controlled switch to a different method, for the particular application and area of interest.

    I think offshore work is a case just like that, and it's no surprise if an NTv2 grid performs relatively poorly in the sea. NTv2 grids are designed to minimise error over a large number of control points. I have only read the documentation for New Zealand, but as far as I remember, all ther control points were on land.

    Please don't try make Global Mapper produce satisfactory results for users who don't know what a datum is, at the cost of leaving users who know what they are doing in essential doubt about the accuracy their work. Give us the best tools for the job (as you always have), and leave it up to us to know how to avoid poking ourselves in the eye with them.

    I don't think this change would be a good thing for users anywhere. But at any rate, please don't implemented a silent heuristic for NTv2 grid shifts for us in New Zealand. We would have to hesitate before using Global Mapper for reprojection, because we would not be following official policy, and our data would not be reliably positioned. (At any rate, we would not be able to say whether it was or wasn't.)

    What I would suggest instead, without knowing the details of how it works, is that you keep the "reality check" code in place—it sounds like something with the potential to be really useful—but that instead of switching from NTv2 to 7-parameter in the case of a significant divergence, just let the user know that the default method may be unsuitable for the location, and give the option to use the grid anyway, or to change to method, or to go away and think about it some more (cancel). If this seems likely to confuse a lot of users, reducing the impression of usability, then I'd suggest just going back to the status quo.

    Thanks as always for your attention Mike.

    Tim
  • global_mapper
    global_mapper Administrator
    edited March 2012
    Tim,

    I appreciate your input, but am very torn on to the best solution, if there even is one. The original purpose of the change is because users using the NTv2-based solution for their slightly offshore work were getting very large differences from what their other software using the 7-parameter transformation was getting, and the 7-parameter was the better one. For me the main goal of the datum transformations is that the actual location on the earth does not change just because you change datums. This means using the best available transformation at any given given location. In a perfect world the user should never have to know about this at all, the best available transformation should just be used and the user's data wouldn't shift on the earth just because of what datum they are using, but I know this is not possible in all cases just because the datum transformations aren't that good.

    I guess the real problem is that the NTv2 grid is so bad offshore. The agency that generated the NTv2 grid should have used a good known transformation method outside of its data points rather than putting garbage data in there that makes the transformation in those areas terrible compared to the excellent accuracy elsewhere and makes their grid shift file not universally useful for that datum. What I really want is single best transformation for each datum for every location on the earth, rather than users having to choose different transformations for the same datum depending on where exactly they are. They should not have to know that, the software should do that for them and not make them have to think about such things as it just needlessly complicates their work without adding any value. The datum transformation should just keep their data fixed at the same location on the earth period, any movement should be considered an error, so the further it moves on the earth the less desirable the transformation is.

    I think perhaps the best solution is to create an "automatic" version of the datum that uses the best transformation automatically based on your location (there are already datums like this in Global Mapper, like the base NAD27 and ED50), that average users can use, then also include the individual specialized transformations so that advanced users that know what those even mean can choose those specifically. I just hate adding a bunch of options to complicate things as it makes the whole mapping thing less accessible to non-geodesists, but if there are going to be grid shift files with these kinds of unacceptably large errors in them I suppose I have no choice.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • global_mapper
    global_mapper Administrator
    edited March 2012
    Tim,

    I went ahead and added 2 new OSGB36 datums, one that explicitly uses only the NTv2 grid and the other than explicitly only uses the 7-parameter transformation. The existing Ordnance Survey 1936 datum has been renamed OSGB36 (Best Transform) and it will automatically use the "best" transformation for your location to minimize the actual movement on the earth due to the datum transformation. This is usually the NTv2 grid, but in offshore locations this will fall back to the 7-parameter transformation.

    This change only affects the OSGB36 datum, it won't affect any other datums.

    I have placed a new build at http://www.globalmapper.com/global_mapper13.zip with the latest changes for you to try. Simply download that file and extract the contents into your existing v13.xx installation folder to give it a try. If you are using the 64-bit v13 version there is a new build at http://www.globalmapper.com/global_mapper13_64bit.zip .

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com