Specify a unique representation for North and South poles

[fulldecent]

Our project introduction states:

Open Location Code is a technology that gives a way of encoding location into a form...

https://github.com/google/open-location-code#open-location-code

"Encoding" here implies that the encoder is a function.

However, the location at the North and South poles, does not correspond to a specific plus code. (i.e. this is not a function or an encoding.) The normative references here have conflicting advice on whether the North Pole is encodable. And also whether it is a unique code.

With more reading between the lines, the South Pole also has similar problems.

---

Open Location Codes cannot exactly represent coordinates at latitude 90.

https://github.com/google/open-location-code/blob/master/docs/olc_definition.adoc

^^ This implies North Pole is not encodable.

---

This implies that the north-west [THIS SHOULD SAY NORTH-EAST, SEE #445, AND EVEN STILL THIS IS UNDERSPECIFIED] coordinates are not included in the area of the code, with the exception of codes whose northern latitude is 90 degrees.

https://github.com/google/open-location-code/blob/master/docs/specification.md

^^ This implies that every code touching 90 degrees on the North will include the North Pole.

---

Recommendations

• Consolidate into just one normative specification for plus codes
• Delete anything else in this repository that purports to describe or specify the plus codes format
• In that specification, specify how the North Pole and South Pole SHALL be encoded // SHALL having the meaning defined RFC 2119.

Potential language I am drafting which is relevant to this point:

A full code encodes an area bounded between two latitudes and two longitudes. This area is inclusive of the south and west edges and exclusive of the north and east edges, with two exceptions: The South Pole (i.e. latitude -90) SHALL be included as the southern bound of the southernmost area including the Prime Meridian (i.e. longitude 0); and the North Pole SHALL be included as the northern bound of the northernmost area including the Prime Meridian.

This is a breaking change (maybe; since the definition was wrong/inconsistent already). This impacts the encoding function because it specifies the correct encoding for +90 and -90 latitude. It does NOT impact the decoding function because decoding is an area, and the areas will have +90 and -90 latitude, although the meaning of what that includes (which edges are included) changes. (i.e. not a code change.)

[bocops]

I feel that your suggested change would conflict with the fact that, as you pointed out elsewhere, plus codes never refer to any exact point but always some area. The poles are exact points, so they are, by definition, not encodable on their own without losing some of that precision anyway.

This means that there is no real problem to solve for the south pole. We either we want to refer to the theoretical concept of a pole, in which case we can't do that via OLC exactly, and in practice will end up with a plus code starting with "2F" automatically if the input is (-90.0, 0.0) - or we want to refer to some real-world entity that has dimension and as such never occupies just the pole, but always some area beyond that. Depending on whether that hypothetical entity (say, a research station) is located "on the pole extending towards the prime meridian" or "on the pole extending towards the anti-meridian", mandating that its plus code needs to start with "2F" can lead to the resulting code being worse than it has to be.

Most of this also applies to the north pole, with the exception of the in-/exclusive shenanigans that are going on for latitude +90.0. So, let's just add wording that legalizes what's going on anyway to the specification, but let's not change anything else.

Example:

open-location-code/java/src/main/java/com/google/openlocationcode/OpenLocationCode.java

Lines 194 to 201 in a323e80

	// Ensure that latitude and longitude are valid.
	latitude = clipLatitude(latitude);
	longitude = normalizeLongitude(longitude);
	// Latitude 90 needs to be adjusted to be just less, so the returned code can also be decoded.
	if (latitude == LATITUDE_MAX) {
	latitude = latitude - 0.9 * computeLatitudePrecision(codeLength);
	}

[fulldecent]

This issue is fixed at #463

Plus Codes are redefined as a locus of coordinates. Just like how I learned geometry in school.

North and south poles are giving unique representations and all coordinations are assigned to Plus Code areas.

[RokeJulianLockhart]

#450 (comment)

@bocops, I don't understand

I feel that your suggested change would conflict with the fact that, as you pointed out elsewhere, plus codes never refer to any exact point but always some area. The poles are exact points, so they are, by definition, not encodable on their own without losing some of that precision anyway.

every point is ultimately an area of a defined precision. Considering that per https://www.quora.com/How-accurate-are-the-Google-Maps-Plus-codes-Within-how-many-meters-are-they-accurate/answer/Jelle-Draijer?comment_id=371656719&comment_type=2, the precision segment can be theoretically infinitely precise, I don't see how any loss should be necessary.

[bocops]

First, this is really a purely theoretical discussion in the context of a years old PR that will likely never get accepted, both because its changes were somewhat controversial at the time and more importantly because this repository seems to be no longer maintained by Google people. I'm not sure if we gain anything from reopening this after more than two years.

That said, both of your statements are incorrect. A point is not the same as an area - and OLC does not allow its areas to become "infinitely precise". The current version of specification.md states that a valid plus code is at most 15 digits long.

[drinckes]

As designed, a representation for the exact points of the north and south poles was not deemed necessary and we're not going to retro fit it.