I have translated the Karney provided equations from the javascript at https://github.com/chrisveness/geodesy/blob/master/utm.js to translate UTM to Lat/Lon into a different scripting language for a project to translate shapefiles to map files for a satellite visualization tool. When I run what purports to be a WGS-84 UTM shapefile it translates the lat/lon points into maps that are 0.05 degrees too far north. I have tried using other datums (Clarke, GRS80) and they all seem to give virtually identical results using the semimajor values. If I substitute the semiminor values the offset is greater.

I am checking the conversion results against a file of the same data that my source provided after running the data through ArcGIS to convert it to geographic directly. I don't have access to ArcGIS, so I can't just do that. I need an in-house more direct tool to integrate with our system.

I am not a math major, just an old line programmer, so I can't easily understand why this is happening.

Anybody got an idea about how I might fix this?

Here is the metadata from the UTM file I am converting followed by some points and conversions. I have determined that for the initial points they are pretty much 6000 meters too far north. I can get them within ~100 meters if I subtract 5500 meters before converting, so that suggests, since it doesn't get precisely there if I subtract 'exactly' 6000 meters, that the calculations are still off somewhere in the math.

20120510 17021000 Website\2012\Packages\ELEVATION\PackagedData_Statewide\Contours500Ft\Contours500Ft.shp Projected geogcsn Sync="TRUE" GCS_North_American_1983 projcsn Sync= "TRUE" NAD_1983_UTM_Zone_12N PROJCS ”NAD_1983_UTM_Zone_12N”, GEOGCS ”GCS_North_American_1983” DATUM ”D_North_American_1983” SPHEROID ”GRS_1980”,6378137.0,298.257222101 PRIMEM ”Greenwich”,0.0 UNIT ”Degree” 0.0174532925199433 PROJECTION ”Transverse_Mercator” PARAMETER ”False_Easting”,500000.0
PARAMETER ”False_Northing”,0.0 PARAMETER ”Central_Meridian”,-111.0 PARAMETER ”Scale_Factor”,0.9996 PARAMETER ”Latitude_Of_Origin”,0.0 UNIT ”Meter”,1.0 XOrigin -5120900 YOrigin -9998100 XYScale 450445547.3910538 ZOrigin 100000 ZScale 10000 MOrigin -100000 MScale 10000 XYTolerance 0.001 ZTolerance 0.001& MTolerance 0.001&lt HighPrecision true bounds minlat="4094776.60000000" minlon="228582.50000000" maxlat="4653399.00000000" maxlon="673947.300000007"

UTM CNV lat = 4650693.00000000 lon = 389280.60000000 lat = 42.04826024690 lon = -112.33814680302 lat = 4650348.50000000 lon = 389380.40000000 lat = 42.04517176050 lon = -112.33687612607 lat = 4650360.00000000 lon = 389520.70000000 lat = 42.04529498908 lon = -112.33518315671 lat = 4650690.50000000 lon = 389650.40000000 lat = 42.04828955593 lon = -112.33367812578 lat = 4650673.00000000 lon = 390428.00000000 lat = 42.04824036112 lon = -112.32427926799 lat = 4650328.50000000 lon = 390489.50000000 lat = 42.04514639600 lon = -112.32347200664

I did look at the Guidance 7-2 document that was suggested and I 'might' be able to convert the formulas to the scripting language, but it will probably cost me what little hair I have left on my head... the conversion from one language to another was relatively easy, but translating the formula direct may be above my rusted-out math skills. I will check with our forecaster, he may be able to help me.

  • 2
    It's hard to tell what might be happening. Can you at least post a sample point, plus what you're getting and what it should be? Otherwise, you might try implementing the EPSG version of transverse Mercator from guidance note 7-2 (it will have a worked example. Or the one from John Snyder. – mkennedy Mar 16 '17 at 7:04

Your Answer

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

Browse other questions tagged or ask your own question.