3

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.

Improve this question

1 Answer 1

Reset to default
3

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.

Improve this answer
3
  • I don't get the same results as you post. I'm using GDAL 1.10, 64-bit on Win 7. I tried the EPSG codes and get the exact same results. I tried both the command-line gdaltransform and wrote a little C++ program. All my results agree, but the NAD27 -> NAD83 conversion is different from your posted results.
    – Reilly
    Commented Mar 3, 2014 at 20:59
  • I'm using the same GDAL on Win 7 too, built by gisinternals. Maybe your GDAL can't find the NAD27 ntv2 grid. Missing that, no datum shift will be applied.
    – AndreJ
    Commented Mar 4, 2014 at 5:51
  • Andre, thanks for your help. I'm embarrassed to admit that the problem was configuration. I found out that PROJ_LIB was not defined. Once I defined that, everything worked out as expected. I'm a little surprised that GDAL didn't throw some kind of exception to let me know that the projection files were not found. Thanks.
    – Reilly
    Commented Mar 5, 2014 at 0:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.