6

I'm working on a project for a client which is migrating data from an Oracle database to an ESRI Geodatabase. When data for this project was initially captured over 15 years ago, the coordinate system used was either UTM Zone 56 South or GDA94 MGA Zone 56 because much of the data was for South East Queensland, Australia. However, as the company grew, they continued to add data further west and maintained the same coordinate system. The data now extends as far west as Darwin, Australia which is in Zone 52.

My instinct is to reproject the data to GDA94 Lat/Long. However, I'm not sure if this will make things worse or better.

I have two questions:

  1. How much error is in the data which is 4 zones out (i.e. in metres/kilometres)?
  2. Will I introduce more error by reprojecting the data to GDA94 Lat/Long? Or is this the right approach?
Improve this question
4
  • 5
    In (1), are you asking about scale distortion in the UTM coordinates are about positional error? We can respond to the first sense--the scale distortion is 7.5% in all directions at Darwin--but it doesn't seem like you have provided any information to respond in the second sense. BTW, there's nothing more "incorrect" in what this client did that there is in Google using a Mercator projection to map parts of the earth further than 20 degrees away from the Equator! Commented Mar 12, 2013 at 23:54
  • @whuber, how did you calculate the 7.5% for scale distortion? What information is required to determine positional error? Commented Mar 13, 2013 at 0:31
  • 3
    This is part of calculations of the Tissot Indicatrix. As far as positional error goes, you just compare the distance and bearing as computed in the projection to the distance and bearing as computed in geographic coordinates. But in a very real sense that's not "error" at all--it's metric distortion in the map and will automatically be corrected upon reprojection. To assess actual error in the positions, you need ground truthing for comparison. Commented Mar 13, 2013 at 3:21
  • What version of ArcGIS do you have access to? It will affect my answer. Commented Mar 13, 2013 at 6:41

1 Answer 1

Reset to default
2

It's going to depend on the transverse Mercator algorithms implemented by Oracle and ArcGIS. The usual transverse Mercator algorithms use series-based equations which limit the useful longitude width. The inverse equations (from projected to lat/lon) are usually worse, so it's often possible to convert to transverse Mercator for a wider region than you can convert from transverse Mercator.

Esri uses a modified version of the US military one--it supports slightly wider zones than Snyder's version in Map Projections: A Working Manual. Esri also has a second version that uses complex mathematics and supports a wider area, but it's slower. In Esri's standard version, beyond around 10-12 degrees from the central meridian, you can't precisely round-trip (lat/lon - projected - lat/lon). It's possible to go a bit farther out on the inverse depending on the data's accuracy. For ArcGIS 10.0, we changed the inverse algorithm to a much more precise version. You can reliably round-trip out to 45 degrees from the central meridian - except in the arctic regions which doesn't affect your data.

So, a question is whether Oracle's (or whatever software was used to put this data into MGA) algorithm is close enough to Esri's that unprojecting with ArcGIS would work. I would suggest trying a few points out on the edge that you can reliably identify and see how well the results match. If you know what software was used originally, you might also try some round-trip points in the zone 52 area to see what kind of shifts are produced.

Improve this answer
3
  • +1 In retrospect it makes a lot of sense that the calculations for UTM have been optimized for the narrow (3.5 degree width) zones used by that system. If I have understood, though, the main issue is that ArcGIS is likely to make systematic errors in unprojecting the coordinates at Darwin, but that the original projected (UTM) coordinates were likely accurately computed. Is this correct? If so, wouldn't one solution be to use any accurate unprojection algorithm (regardless of the platform on which it has been implemented)? Commented Mar 13, 2013 at 19:09
  • The coordinates are precisely computed based on the algorithm used. Snyder and the US military algorithms don't match once the data's beyond a zone or two algorithms published the Danish and Finnish governments that do handle wide zones for both forward/inverse cases. Are the ArcGIS ones wrong? I'm not so sure, but no, I don't know that those UTM coordinates have been accurately computed. I think the goal is that the inverse algorithm needs to match the forward algorithm that was used. We don't yet know what that was. Commented Mar 13, 2013 at 19:21
  • 1
    I agree. To avoid confusion, we need to take some care in our language here. I doubt there's any concern about precision in how numbers are manipulated in the calculations. The formulas themselves use truncated power series (or Fourier series) and so they have some inherent error of approximation (which is inaccuracy rather than imprecision) determined by how many terms are used. That error can grow exponentially with the distance from the origin. So the key questions are (1) how accurately were the UTM coordinates originally computed and (2) how accurately can they be unprojected? Commented Mar 13, 2013 at 19:36

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.