gdal – Comprehensive Guide to Datum Conversion with GDAL

coordinate systemdatumgdal

I run gdaltransform like so:

 gdaltransform -s_srs nad27 -t_srs wgs84
 -104.5 39.5
 -104.5 39.5 0

 gdaltransform -s_srs wgs84 -t_srs nad83
 -104.5 39.5
 -104.5 39.5 0

 gdaltransform -s_srs nad27 -t_srs nad83
 -104.5 39.5
 -104.5 39.5000000009262 4.23276796936989e-005

In other words, if gdaltransform nad27 -> wgs84 -> nad83, the lat/lon do not change.

If, however, I transform nad27 -> nad83, my latitude is ever-so-slightly different.

Why, please? What is the correct process for transforming coordinates?

I have a legacy application that only saves the datum name (e.g. NAD27, WGS84, etc) and the lat/lon. In its processing, when trying to find the lat/lon in NAD83, which is the projection defined in a 1 sec FLT .HDR file, it calls (an old DLL implementation of) CS-Map cs_cnvrt, passing in nothing more than these datum strings, and it gets an output lat/lon that are different than the input lat/lon.

When updating this code, I have this crazy idea that I'll keep all coordinate internally in WGS84, and transform them as needed by the output plane. So my code reads the NAD27 coordinates, converts to WGS84 using GDAL. It later asks GDAL to transform WGS84 to the spatial reference system (SRS) in the FLT file (i.e. NAD83). The transform results are exactly the same as the input.

This makes sense to me, but I can't understand why the two methods above are so different.

Thanks.

-reilly.

Best Answer

I would suggest to use the correct EPSG codes, that is:

EPSG:4267 NAD27
EPSG:4269 NAD83
EPSG:4326 WGS84

You will get the better values -104.500522187483 39.4999860425 between the first ones.

The last two are identical for GDAL.

Related Solutions

[GIS] How to use GDAL to convert from an arbitrary projection/datum into Equirectangular/WGS84

I've solved my problem.

RT90 is not a defined datum in Proj4. As such, GDAL just up and ignores the datum entry and applies the ellipsoid and projection correction.

It'd be nice if a warning was thrown at some point ("WARNING: datum 'RT90' not recognized" would be enough, but I digress).

The sinusoidal projection in WGS84 datum was transforming incorrectly because the Sinusoidal projection wasn't being set properly when export from Global Mapper. When I hand-rolled my own SRS to be "+proj=sinu +datum=WGS84" everything worked out fine.

To get proj4 to list various types of datums/projections/ellipsoids that it supports:

proj -ld    //lists known datums
proj -le    //lists known ellipsoids
proj -l     //lists known projections (use -lP for an expanded view)

If you want GDAL to work with unknown datum types, you must specify "+towgs84=" in your source SRS, and you must also specify "+towgs84=" in your target SRS if your target datum is not WGS84. These tags must be followed by 3 or 7 parameter transformation values, which can be found with some google-fu. More info on this tag can be found here:

http://trac.osgeo.org/proj/wiki/GenParms#towgs84-DatumtransformationtoWGS84

Hopefully anyone that runs into a similar problem will now be able to do so.

How to Determine UTM Zone and Hemisphere in a Given Datum

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.

Best Answer

Related Solutions

[GIS] How to use GDAL to convert from an arbitrary projection/datum into Equirectangular/WGS84

How to Determine UTM Zone and Hemisphere in a Given Datum

Related Question