There are two coordinate systems in question:

"CRS 1" = EPSG:4326 (good ol WGS84)

"CRS 2" = EPSG:26710 (UTM NAD27 Zone 10 (specifically, zone 10S but they don't seem to differentiate)

For the coordinate in question, in "CRS 1" = EPSG:4326:

39.3662N, -120.35175E (i.e. 120.35175W) = NW summit of Castle Peak in Nevada County CA USA

Converting to CRS 2 using various programs (rounding to nearest meter):

All three of these have very good agreement (within 10m, and that's mostly rounding error):

QGIS 2.6:                07 28 241 E   43 60 566 N
caltopo.com:             07 28 239 E   43 60 561 N
Terrain Navigator Pro:   07 28 241 E   43 60 565 N

These two are very far away from the others and from each other:

Locus Pro (android app): 07 28 153 E   43 60 552 N
http://twcc.free.fr:     07 28 145 E   43 60 785 N

Note for Locus Pro I added EPSG 26710 into its config file, which is a documented and supported thing to do. After emailing with the developer he confirms it is (or should be) using the correct proj4 code:

EPSG:26710 : +proj=utm +zone=10 +ellps=clrk66 +datum=NAD27 +units=m +no_defs

Which is also what shows up when you view the EPSG info in twcc.

Any idea what I'm missing? Hopefully just something obvious? Bottom line is that I'd like to get accurate conversion from WGS84 to and from UTM NAD27 CONUS zone 10S on the Android.

  • I think you mean UTM Zone 10N instead of 10S, because NAD27 is not valid in the southern hemisphere.
    – Mintx
    Dec 31, 2014 at 18:30
  • S does not mean southern hemisphere. I was pulled in by that too initially. these are both correct: en.wikipedia.org/wiki/… dmap.co.uk/utmworld.htm
    – Tom Grundy
    Dec 31, 2014 at 18:41
  • I believe the common nomenclature for UTM Zones is to put the hemisphere after the zone number. If you are talking about grid zones then it's best to say Grid Zone instead of just zone. You can even look up the EPSG code 26710 here: link
    – Mintx
    Dec 31, 2014 at 19:30
  • 1
    Good catch, I had never heard of the 'grid zone' before. The Wikipedia article pretry much says what you say, I just hadn't read it completely. To use Wikipedia terminology, this is in grid zone 10s: utm zone 10, latitude band s.
    – Tom Grundy
    Dec 31, 2014 at 21:33

2 Answers 2


You have to consider that QGIS uses the NADCON datum shift grid, while other software might use a 3- or 7-parameter Molodensky transformation, or no transformation at all.

The shift grid is internally used in +datum=NAD27, but when the grid file is not included in the software, it might just do nothing. You will get a small shift anyway because the ellipsoid clrk66 is different from WGS84.

If you use twcc.free.fr with NAD83 or WGS84 UTM, you get exactly the same coordinates. So you better do not trust them.


With GDAL cs2cs which uses the same proj.4 libraries as QGIS, i did these calculations on an iput file castlePeak.txt with -120.35175 39.3662 inside:

echo noshift >nad.txt
cs2cs  +init=epsg:4326 +to +proj=utm +zone=10 +ellps=clrk66 +towgs84=0,0,0,0,0,0,0 +no_defs -f %%.0f CastlePeak.txt >>nad.txt
echo nad27 conus >>nad.txt
cs2cs  +init=epsg:4326 +to +proj=utm +zone=10 +datum=NAD27 +no_defs -f %%.0f CastlePeak.txt >>nad.txt
echo nad27 tfm1173 >>nad.txt
cs2cs  +init=epsg:4326 +to +proj=utm +zone=10 +ellps=clrk66 +towgs84=-8,160,176,0,0,0,0 +no_defs -f %%.0f CastlePeak.txt >>nad.txt

giving this result:

728145  4360785 26
nad27 conus 
728241  4360566 0
nad27 tfm1173 
728239  4360567 18

So twcc.free.fr simply sets towgs84 to all 0 (no shift grid file found), but LocusPro still does something different:

enter image description here

  • so, do you think it's possible that locus pro may just be missing the grid shift file?
    – Tom Grundy
    Jan 1, 2015 at 0:18
  • No, that's what twcc.free.fr doing wrong. See my extended answer. Are you sure you have hit the same spot?
    – AndreJ
    Jan 1, 2015 at 6:46
  • Sorry for delayed response. I'm sure they are hitting the same spot to withing 10 meters, based on using those coordinates on a topo map, so I guess everything is relative? Is there a better benchmark to use to compare results from various sources?
    – Tom Grundy
    Jan 5, 2015 at 15:40
  • You can take USGS Topo pdfs as reference. They offer the 7.5x7.5 sheet of Norden from 1955 with NAD27 coords and from 2012 in NAD83.
    – AndreJ
    Jan 5, 2015 at 20:46
  • will do, thanks. My question at this point is - as an end-user of Locus Map Pro, what's the next step in getting the "correct" WGS84 -> NAD27 zone 10 lat band S UTM conversion to work in Locus? Should I advise the Locus developer that he's missing a grid shift file, or, should I download a grid shift file for use on the client and put it in a certain location, or something like that?
    – Tom Grundy
    Jan 6, 2015 at 0:14

The different software applications are either

  1. Not applying any datum transformation
  2. Applying different transformations

One trick when comparing different software applications and there's a datum transformation involved is to run each step separately if possible. In this case, convert from WGS 1984 to NAD 1927 first. If the values are not changed, or only slightly changed in the latitude values, either no or a very inaccurate transformation is being applied.

I ran some sample conversions through the Esri projection engine. I'm showing more precision than the input values. Deal with it.

Test Case 1: Use the conus grid file from the NADCON software, EPSG:1241

   NAD 1927:
   39.3662954 -120.35071365

   NAD 1927 UTM Zone 10 North ("Northern hemisphere" versus latitude band "S")
   728240.7989 4360565.5688

Test Case 2: Perform no transformation

   NAD 1927 UTM Zone 10 North 
   728151.8139 4360552.3590

Test Case 3: Use the EPSG:1173 transformation, NAD 1927 to WGS 1984 (4) which was designed for CONUS.

   NAD 1927
   39.36630895 -120.350731756

   NAD 1927 UTM Zone 10 North
   728239.1950 4360567.0268 

EPSG:1241 uses files on-disk as @AndreJ mentioned and have to be installed separately with PROJ4. EPSG:1173 uses an equation-based transformation--no separate files are needed.

Disclosure: I work for Esri and I'm on the subcommittee that maintains the EPSG Geodetic Parameter Dataset.

  • For general mapping purposes, I'm glad EPSG:15851 exists, so cheers to whomever came up with that code. :)
    – Mintx
    Dec 31, 2014 at 19:42
  • Ah, yes, test case 1 should be using 15851 instead! Hmm, should I bother to edit my answer... 1241 converts between NAD27 and NAD83. 15851 is an "equivalent" transformation that converts between NAD27 and WGS84. That is, NAD83 and WGS84 are treated as equivalent.
    – mkennedy
    Dec 31, 2014 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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