SourceForge has been redesigned. Learn more.

UTM to lt/lg converting problem

dou wen
  • dou wen

    dou wen - 2005-09-16

    I have tested the converting from UTM coordinate to normal longitude/latitude of qpegps,
    the converting stuff is mainly based on following two methods of Class MapUTM, and i found something wrong with it.

    for example, use following qpegps code, the UTM  coordinate (651731E,3266424N,48R) will be converted to
    (29.52510N,105.78291E), not the correct answer (29.51822N,106.56559E), i am not familiar with algorithm detail for this converting, but i think this is a little bug of qpegps.

    the test is based on qpegps pre



    MapUTM::MapUTM(QString *mapInfo, bool utmCoord):MapBase(mapInfo)
        xlong1 = 0.5*atanh(cos(latitude1) * sin(checkLg(longitude1-stdLong)));
        ylat1 = atan(tan(latitude1) / cos(checkLg(longitude1-stdLong)));
        xlong2 = 0.5*atanh(cos(latitude2) * sin(checkLg(longitude2-stdLong)));
        ylat2 = atan(tan(latitude2) / cos(checkLg(longitude2-stdLong)));

    bool MapUTM::calcltlg(double *lt, double *lg, double x, double y)
        double xt,yt;
        xt = xlong1 + ( (x - x1) * checkLg(xlong2 - xlong1) / (x2-x1) );
        yt = ylat1 + ( (y - y1) * (ylat2 - ylat1) / (y2-y1));
        printf("orig xlong1 = %f\n",xlong1);
        printf("orig ylat1 = %f\n",ylat1);
        *lt = asin(sin(yt)/cosh(xt));
        *lg = checkLg(stdLong + atan(sinh(xt) / cos(yt)));
        return TRUE;

    • Ralf Haselmeier

      Ralf Haselmeier - 2005-09-18

      The mentioned 2 methods do the conversion between longitude/latitude and the corresponding pixels on the map for a transverse mercator projection (UTM is a transverse mercator projection where the coordinates are giving in northing,easting and zone instead of longitude and latitude). The transformation from UTM coordinates to latitude/longitude is done with the method UTMtoLL. As I do not have a single UTM map, I couldn't check it myself if this works correct. Another important point of this conversion, is on which "datum" your map is based.
      Are the UTM coords and your correct answer both based on the WGS84 datum ? The current algorithm works only for this datum. Is there a common need for UTM maps with another datum than WGS84?

    • dou wen

      dou wen - 2005-09-19

      hi, Ralf, of course you are right ,the UTMtoLL method is used  when importing a new UTM map, the MapUTM constructor will call 
      the UTMtoLL to get the longitude/latitude from input 2 reference point whose  coordinates are giving in northing,easting and zone
      .  i am sure and checked the caculation in UTMtoLL is all right. so i didnt mention this method.

      _but_   the MapUTM constructor will also pre-caculate xlong1, xlat1,xlong2,xlat2, which will be used in the MapUTM::calcltlg method to caculate  the lt/lg value when i  mouse-click any point of the map.

      i.e.,  when i mouse click any point on this imported map
      , the caculating for the lt/lg coordinates (in calcltlg) is not depend on
      longitude1/latitude1 and  longitude1/latitude2 of the two reference point  directly, but it depend directly on xlong1/xlat1 and xlong2/xlat2 which were "pre-calculated " when the map opject was constructed. 
        I think the caculation for the lt/lg coordinates is not correct.

        That is the reason i list only the MapUTM constructor and calcltlg methods.
      here is my guess:
      (1) i guess the pre-calc for xlong1/xlat1 and xlong2/xlat2 is not correct.
      (2) i guess the algorithm in MapUTM::calcltlg is not correct.

      I am very sure the map i mentioned is WGS84 datum based UTM map.

      Ralf,  here is a UTM map item of my maps.txt, you could simply generate a same size png file of the map item and import it to
      your test system to  verify the problem what i prompt.

      "UTM cq.png 10000 4134 5984 48R 3279760 639498 236 72 3266352 650470 2900 3581"

      you can also use a public UTM2lat converter to verify what i said (  )  .

      i would also like to send the OZI explorer map to you if you accept.

      Best regards

      • Ralf Haselmeier

        Ralf Haselmeier - 2005-09-20

        Hi Dou,

        sorry I wasn't reading your post carefully enough.
        Thanks for the UTM string (wow, this map is really big; please send it to

        The projection algorithm works this way:
        UTMtoLL: The UTM coordinates are converted to lat/long
        calcxy: converts lat/long to pixel coordinates (=x,y)
        calcltlg: conversts pixels to lat/long
        The projection calculates coordinates in the range of -1 to +1( resp from-PI to +PI ..., depends on projection). So there is always a linear interpolation from this (let's call it "intermediate linear coord system"=ilcs) to the coordinates in pixels.
        Precalc in constructor: calculates the values of the 2 reference points in the "ilcs"(xlong1/2,ylat1/2).

        The projection equations are:
        x = 0.5 * atanh(B)
        y = atan( tan(lat) / cos(long -stdLong) -y0
        lat = asin(sin(D)/cos(x))
        long = stdLong + atan(sinh(x)/cos(D))
        B = cos(lat)*sin(long-stdLong)
        D = y +y0
        As y0 is a common offset, it shouldn't have any impact after the linear interpolation, so I set it to 0.

        The only posible problem I saw is the usage of the checkLg function. So please try this (modified) methods:
        bool MapUTM::calcxy(double *x, double *y, double lg, double lt)
            double xt,yt;
            xt = 0.5*atanh(cos(lt) * sin(checkLg(lg-stdLong)));
            yt = atan(tan(lt) / cos(checkLg(lg-stdLong)));
            *x = x1 + ( xt - xlong1 * (x2-x1) / xlong2 - xlong1);
            *y = y1 + ( (yt - ylat1) * (y2-y1) / (ylat2 - ylat1) );
            if ((*x < 0)||(*x >= mapSizeX)||(*y < 0)||(*y >= mapSizeY))
                return (FALSE);
            return (TRUE);

        bool MapUTM::calcltlg(double *lt, double *lg, double x, double y)
            double xt,yt;
            xt = xlong1 + ( (x - x1) * xlong2 - xlong1 / (x2-x1) );
            yt = ylat1 + ( (y - y1) * (ylat2 - ylat1) / (y2-y1));
            *lt = asin(sin(yt)/cosh(xt));
            *lg = checkLg(stdLong + atan(sinh(xt) / cos(yt)));
            return TRUE;


    • dou wen

      dou wen - 2005-09-22

      i have tried the two modified methods, but the test result is still
      not correct :-(

      Best regards


Log in to post a comment.