GM_DecodeMGRSCoordinates() output used as input for GM_GetMGRSCoordinates()

Toni HeimalaToni Heimala Global Mapper UserPosts: 15
edited March 2012 in SDK
Using the output coordinates of GM_DecodeMGRSCoordinates() as input for GM_GetMGRSCoordinates() results in different MGRS grid than was given for GM_DecodeMGRSCoordinates(). I understand that the grids can overlap a bit but I would hope that at least the bottom left corner could be retrieved.

Example code:
double x(0.0);
double y(0.0);
GM_DecodeMGRSCoordinates("35 V LG", &x, &y, false);
char mgrs[30] = {'\0'};
GM_GetMGRSCoordinates(x, y, false, mgrs);

This results mgrs being "34 V FL 39714 97277", even though you would expect it to be "35 V LG 00000 00000" since it is the most significant point in the whole grid (i.e. the bottom left corner).

Comments

  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited March 2012
    The problem is indeed the overlap. The "35 V LG" coordinate results in a longitude of 23.46E, which is well inside UTM zone 34. When you reverse from a lat/lon coordinate to a MGRS string, the first thing that is done it to determine which UTM zone that point is in to determine the most appropriate MGRS zone, which puts you in zone 34, so the first number is 34. Then the MGRS designation within that zone is found. Unfortunately there can be multiple MGRS strings that result in the same location because they overlap. The conversion from a MGRS string to a coordinate will handle those conversions, but the reverse from a coordinate to a string will always give you the one appropriate for the zone those points are in rather than any of the alternates from the wrong zones.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • Toni HeimalaToni Heimala Global Mapper User Posts: 15
    edited March 2012
    There seems to be an additional problem, if my current projection is UTM with zone 35 for example. I'm assuming that when I give GM_DecodeMGRSCoordinates() an MGRS string, GlobalMapper SDK will internally first convert it to geographic coordinates and then convert those geographic coordinates back to my current projection. Which actually causes the coordinates from zone 35 to be presented so that they assume to be in zone 34 but there is no indication about this change.

    Following code:
    GM_Projection_t theUtmProj;
    ::memset( &theUtmProj, 0, sizeof theUtmProj );
    theUtmProj.mProjSys = GM_PRJ_UTM;
    theUtmProj.mDatum = GM_DATUM_WGS_84;
    theUtmProj.mUnit = GM_PRJ_UNIT_METERS;
    theUtmProj.mAttrList[0].mAttr = ZONE;
    theUtmProj.mAttrList[0].mValue = 35;
    theUtmProj.mNumAttrs = 1;
    GM_SetProjection( &theUtmProj );
    double x(0.0);
    double y(0.0);
    GM_DecodeMGRSCoordinates("35 V LG", &x, &y, false);
    

    Results in x=3014898.439277171200, y=3943753.244613731300
    But they should be x=300000.0, y=6600000.0
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited March 2012
    Turns out there was a bug in the GM_DecodeMGRSCoordinates function when returning non-lat/lon coordinates (it was switching the coordinate order when reprojecting them). I have fixed them and now you get back the expected results. I have placed a new SDK build with the fix at http://www.globalmapper.com/GlobalMapperSDK_latest_beta.zip for you to try.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • Toni HeimalaToni Heimala Global Mapper User Posts: 15
    edited March 2012
    Thanks Mike!

    Now the coordinates are mapped correctly for the projection.
Sign In or Register to comment.