Bug in OSGB::GridReference

[Kal]

OSGB::GridReference is broken for negative easting/northing values. The output gridref string contains garbage characters. Maybe this should be checked for and an exception thrown?

[Charles Karney]

I've fixed one problem. Please apply this patch and try again. If you
still find problems, please provide me with details. Thanks!

diff --git a/src/OSGB.cpp b/src/OSGB.cpp
index 1b83f45..d3962c7 100644
--- a/src/OSGB.cpp
+++ b/src/OSGB.cpp
@@ -44,8 +44,8 @@ namespace GeographicLib {
                           + Utility::str(int(maxprec_)) + "]");
     char grid[2 + 2 * maxprec_];
     int
-      xh = int(floor(x)) / tile_,
-      yh = int(floor(y)) / tile_;
+      xh = int(floor(x / tile_)),
+      yh = int(floor(y / tile_));
     real
       xf = x - tile_ * xh,
       yf = y - tile_ * yh;

[Kal]

Hi Charles,
This change appears to fix the garbage output, Thanks!

Another question: Why are negative values even allowed? Are they even useful when converted to a gridref? I thought only gridrefs in the range 0,0 to 700000,1300000 are ever used. Currently GeographicLib will generate OSGB gridrefs as far as Sweden. Do these exist on any map?

[Charles Karney]

The first letter of the grid refence is part of a 5x5 grid of (500km)^2
blocks -- see top left subfigure in 2nd figure of

https://en.wikipedia.org/wiki/Ordnance_Survey_National_Grid

GeographicLib allows conversions anywhere in the resulting (2500km)^2
area on the theory that allowing the conversions is more useful than
forbidding them. Obviously a developer (you!) can insert other limits.

One other thing: I'll probably make OSGB behave like UTMUPS/MGRS with
respect to NaNs. I.e., NaN as an easting or northing will produce a
nan-like grid reference (MGRS uses "INVALID"). Similarly a grid
reference starting with "INV" will produce NaNs for the easting and
northing. Such behavior is useful in interacting with Matlab which uses
NaNs as a signal to break a line in the plot function. Currently NaNs
throw an error with a bogus error message.

[Kal]

Thanks for the explanation. I think you are right that it is better not to forbid coords outside of that range. The NaN change also seems reasonable. At least it will be more consistent.

[Kal]

On the other hand, I would actually vote that we just remove the "INV" parsing from MGRS/UTMUPS. This seems like something the application should handle. I wasn't aware of this parsing before. I just realized this is causing a bug in my application.

[Charles Karney]

Sorry, I need to keep the interpretation of INV as an "unknown" MGRS
reference. (For example, the Planimeter tool can use this MGRS
reference to break a sequence of points into separate polygons.)
There's probably no way to keep everyone happy here. However the notion
that certain values can indicate unknown coordinates and sail through
the system sensibly is very useful.