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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
I've fixed one problem. Please apply this patch and try again. If you
still find problems, please provide me with details. Thanks!
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?
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.
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.
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.
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.