Determine the UTM zone/hemisphere in a particular datum

Question

I'm using GDAL to convert coordinates from one system (geographic or projected) to another.

Assume I want to convert geographic coordinates (latitude and longitude) in the WGS84 datum, to UTM coordinates in the Amersfoort datum (EPSG:4289).

In order for GDAL to determine the UTM coordinates (easting and northing), it needs:

• the input spatial reference system: geographic, based on the WGS84 datum
• the input coordinates: latitude and longitude
• the target spatial reference system: projected - UTM -, based on the local Amersfoort datum

To instantiate the target SRS, besides the datum, I need to specify the zone and the hemisphere.

The question is: How to I determine the UTM zone and hemisphere where the input geographic coordinates fall in? I could use the Wikipedia article for that. As far as I understood, the mechanism described there works for determining the zone and hemisphere for geographic coordinates in the WGS84 datum. What is not clear to me is whether the resulting zone and hemisphere make sense only for the WGS84 datum, or if they can be used in any, local or global, datum.

If the zone and hemisphere determined from geographic coordinates in the WGS84 datum only make sense for determining the UTM coordinates in that same WGS84 datum, how can I determine the UTM zone and hemisphere in another datum - WGS72, NAD27, NAD83 etc.?

Also, does it even make sense to speak of UTM coordinates in a local datum?

I hope I haven't messed up the concepts too much. Anyway, any pointers will be greatly appreciated.

Answer 1

The choice of datum doesn't matter for map making (provided you change datums appropriately, of course). It does matter for transmitting coordinates and sharing data.

To address your last question ("does it even make sense?"), note that UTM is really a coordinate system and as such--in addition to its grid-based zone naming system--it includes a definite datum and unit of measurement as well as a set of projections. What we're talking about here is using its projections (Transverse Mercator (TM) for the low to moderate latitude zones) and its zoning system but possibly changing the datum (and, perhaps, units of measurement). Changing either the datum or the units (or both) is fine, but after that is done the result is not "UTM," strictly speaking. In some applications (e.g., military targeting) it could be dangerously misleading to refer to the resulting (x,y) values as "UTM coordinates," because they will look remarkably like UTM coordinates but might be up to a few hundred meters off. (That can lead to embarrassing things like lost embassies.) Nevertheless, because your principal questions refer to "UTM" in this looser sense, I will also use the term in this way.

UTM is a choice: you can pick any zone to use. It is designed to work within certain accuracy constraints to within 3.5 degrees (longitude) of its meridian at any latitude within the 120 non-polar zones. Because the zones are nominally 6 degrees wide, this allows a 0.5+0.5 = 1 degree longitude overlap with each neighboring zone. Moreover (if you are concerned with map quality foremost and following the UTM system exactly is of lesser importance), the overlap can get larger in the more extreme latitudes (e.g., at 45 degrees the overlap is more than 4 degrees of longitude). Because two (reasonable) datums differ in longitude by at most by 100 meters or so (0.001 degrees), the difference in datum is inconsequential: if you choose a UTM zone based on one datum it will work fine with another.

Once you have allowed yourself the flexibility of changing the datum, you might as well go all the way and create a "custom UTM zone." This is tantamount to dropping UTM altogether (which includes forgetting about the 0.9996 scale factor and origin offsets) and selecting a TM projection suited for the area you are mapping. Within a small area you can do well by placing the meridian of the TM projection through the center of your map and using a scale factor of 1.0000. Choose any convenient origin.