Adjust longitude behavior in Location

[Peter Powers]

Currently, Location longitudes are required to be between ±180. This is generally ok as there is very little continent, and hence hazard of concern, crossing the int'l date line. However the Aleutians do cross it and the NSHMP Alaska grid extends to 200 (or -160). This needs to be addressed because geometric operations on regions are essential (e.g. contains()). Possible solutions:

• Conversion of values in individual applications based on some user preference
• Split regions that cross ±180 in two
• Adopt a garbage in garbage out policy. Allow longitude values between -180 and 360 and assume user/programmer knows what they're doing.

The 3rd is the simplest to implement and would come with the caveats that a user use the correct distance calculation algorithms if they are going to mix and match.

Comments?

[Peter Powers]

See related: #25

[Peter Powers]

I favor the third option [users should know what they're doing]. I believe such a modification will have little impact, but junit tests of the various Location algorithms should be implemented comparing results of Locations in the 180:360 range to similarly arrayed Locations in the -180:0 range.

[Kevin Milner]

Still needs to be addressed, but not during UCERF3 dev. Punt to 1.4

[Peter Powers]

Increased maximum longitude to 360 so Locations may now be defined on interval -180 to +360; buyer beware; Locations Utils docs updated as well as unit tests to confirm calcs with negative lons produce same result as those in positive reference frame. Looking at the distance calculations and doing some rudimentary tests, I don't foresee any problems.

[Peter Powers]

fixed in #10690