Conversion from DMS to Decimal Degrees fails between 1 Degree and -1 Degree

[jmmain69]

This issue occurs in gov.nasa.worldwind.geom.Angle fromDMS() and fromDMdS()

The formula for converting from Degrees Minutes Seconds to Decimal Degrees uses Math.signum(degrees) to provide a positive or negative number. This causes any value less than 1 degree to become 0.0, for example 00 degrees 59 minutes 59 seconds North would become 0.0 degrees in decimal degrees as signum(0) will return 0.

Math.signum(degrees) * (Math.abs(degrees) + minutes / 60d + seconds / 3600d)

[zglueck]

@jmmain69 thanks for spotting this! I'll look into it.

[zglueck]

@jmmain69 you were right, the signum function used was blanking values between -1 and 1.

As the team reviewed the issue, we noticed the documentation for fromDMS stated the degrees parameter should be positive. Despite noting this in method documentation, the original code was attempting to account for negative degree values. Bounds for the minutes and seconds were checked, but not the degrees, and as you pointed out, the signum function worked for all cases between, except between -1 and 1.

The intent and actual execution of the method were confusing, and while this works for a large chunk of values, the case you identified is a major issue.

We decided the best coarse of action is to enforce the documented intent of all values being positive for this function (and for fromDMdS), thereby requiring the application to compensate for negative angles. The signum functionality has been removed from the fromDMS and fromDMdS functions and an IllegalArgumentException will now be thrown for degree values less than zero. The function now is valid for the entire positive domain.

We did not take this step lightly, and understand, some applications may now experience an IllegalArgumentException on what had been previously working inputs (e.g. -45 degrees 5 minutes 10 seconds). This change removes ambiguity for negative inputs by requiring the application to determine the domain. We felt this was the best path forward in order to ensure the right values are provided from the function.

The Angle class does offer a fromDMS(String dmsString) function which will account for DMS angle values with a sign or compass direction. I encourage you and others to review its documentation and functionality as additional option.

Please feel free to continue the discussion here or at the forum, and thanks again for bring this to our attention.

[wcmatthysen]

A simple fix for this, without breaking existing code is to have a special clause for 0-degrees, as in:

float sign = (degrees == 0) ? 1.0f : Math.signum(degrees);
return Angle.fromDegrees(sign * (Math.abs(degrees) + minutes / 60d + seconds / 3600d));

I think it would be still useful to allow negative degrees for this method, especially when constructing a LatLon from an Angle-pair. Reverting to the string-based parsing method is inefficient.

[zglueck]

I think that would satisfy the 0 to 1 degree domain, but what about -1 to 0? Maybe I'm missing something in your approach, but if I wanted to represent 0 degrees 15 minutes 34 seconds west, it would now be 0 degrees 15 minutes 34 seconds east. Basically, -1 to 0 is complicated by the fact we can't have a -0 degree.

[wcmatthysen]

Damn, I see. Couldn't we use a float for the degrees? We could detect the difference between positive and negative zero (see: this link). It just seems a bit harsh to suddenly change the behaviour of this method to disallow negative degree parameters, especially if there are code out there that depends on this behaviour.

[zglueck]

Yeah the team really didn't want to break the existing functionality and the double negative zero idea did get discussed, but it really came down to this: As it was, there was a silent calculation failure that just returned bad results for a certain domain and the documentation did say positive (despite the efforts of the underlying code).

By leaving the sign determination up to the application, we remove any ambiguity presented by the API, and now, with the bounds being checked and exception being thrown, at least alert users. While looking into the issue I actually found a number of online javascript calculators with the same issue between -1 and 0. It really didn't feel good to limit the function, but it feels better than having a silent erroneous result being returned.

[wcmatthysen]

Ok, I understand. However, wouldn't it then be feasible to introduce an additional fromDMS() method with a sign for the degrees as parameter? Then, at the very least we can fall back to a new method if we relied on the fromDMS() method to create LatLon objects.

[wcmatthysen]

I'm talking about something along the lines of:

public static Angle fromDMS(int sign, int degrees, int minutes, int seconds) { ... }

with sign being -1 or 1 (or maybe some other approach where sign is a boolean toggle or something).

[zglueck]

We did discuss adding a function or modifying the existing signature. In the end, we decided incorporating the sign handle into a function signature wouldn't be clear. Leaving it up to the application is the safest and clearest approach.

[wcmatthysen]

I suppose the workaround could be Angle.fromDMS(deg, min, sec).multiply(-1) then.

[pdavidc]

That's exactly what we had in mind. Our thinking was: why complicate the method signature when the application-based solution is simple.