MOOSGeodesy incorrectly converts global points when they are in a different UTM zone than the origin. For example, after setting the initial origin near the boarder of a UTM zone (E.G. near -71.98 degrees longitude), converting a point just on the other side of the UTM zone (E.G. -72.02 degrees longitude) will result is a huge error. However, if you convert point at the same distance within the same zone (E.G. -71.94), the converted point is within reason.
CMOOSGeodesy geodesy;
geodesy.Initialise(40.5, -71.98);
double x = 0.0;
double y = 0.0;
// Sanity check - Convert the origin
if (geodesy.LatLong2LocalUTM(40.5, -71.98, y, x))
{
std::cout << x << "," << y << std::endl;
// prints: 0,0
}
// Short distance to the right
if (geodesy.LatLong2LocalUTM(40.5, -71.94, y, x))
{
std::cout << x << "," << y << std::endl;
// prints: 3390.07,-113.844
}
// Short distance to the left
if (geodesy.LatLong2LocalUTM(40.5, -72.02, y, x))
{
std::cout << x << "," << y << std::endl;
// prints: 505050,0
}
The problem hinted by a comment in the code:
https://github.com/themoos/geodesy-moos/blob/master/libMOOSGeodesy/MOOSGeodesy.cpp#L338
//could check for the UTMZone differing, and if so, return false
However, the method does not actually check the UTM zone. Further, returning false here is probably not the best thing to do since this scenario is not only valid, but common.
MOOSGeodesy incorrectly converts global points when they are in a different UTM zone than the origin. For example, after setting the initial origin near the boarder of a UTM zone (E.G. near -71.98 degrees longitude), converting a point just on the other side of the UTM zone (E.G. -72.02 degrees longitude) will result is a huge error. However, if you convert point at the same distance within the same zone (E.G. -71.94), the converted point is within reason.
The problem hinted by a comment in the code:
https://github.com/themoos/geodesy-moos/blob/master/libMOOSGeodesy/MOOSGeodesy.cpp#L338
//could check for the UTMZone differing, and if so, return falseHowever, the method does not actually check the UTM zone. Further, returning
falsehere is probably not the best thing to do since this scenario is not only valid, but common.