-
Notifications
You must be signed in to change notification settings - Fork 479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify a unique representation for North and South poles #450
Comments
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
|
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. |
This comment has been minimized.
This comment has been minimized.
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. |
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. |
If anybody was curious why we were so curious about how to encode the poles, it is because we were using plus codes to divy up the Earth and sell each section as an NFT. And each one of them could be broken up and resold into the next greater level of precision. Of course when it's property, people need to know very clearly what is theirs and the poles are prime real estate! Feel free to use this tidbit against me and never take anything I say seriously; or get a laugh out of it; whatever suits your mood! 😆 |
Wow. This is about the most colonialist thing I've heard this year.
Jesus. I can't even. |
This comment has been minimized.
This comment has been minimized.
Sorry for the off topic. I don't take any offence here, just having a good time. P.P.S. That NFT project is dead. But I still care about this project here, and this nice global addressing standard |
Our project introduction states:
"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.
^^ This implies North Pole is not encodable.
^^ This implies that every code touching 90 degrees on the North will include the North Pole.
Recommendations
Potential language I am drafting which is relevant to this point:
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.)
The text was updated successfully, but these errors were encountered: