Repository navigation
Latitude -90 is treated as invalid value #20
Description
What steps will reproduce the problem?
1. Pass for example -90 to encode
2. Watch the exception being raised.
def encode(latitude, longitude, precision=12):
if latitude >= 90.0 or latitude < -90.0:
raise Exception("invalid latitude.")
What is the expected output? What do you see instead?
If I'm not wrong -90 is still correct value. it's south pole.
Original issue reported on code.google.com by fi...@fizyk.net.pl on 3 Mar 2015 at 11:24
Activity
Fixed indentation
Added more elegant solution as per @kerrick-lyft
hkwi commentedon Jul 19, 2016
Geohash encodes an area, not point. Some tiles do have latitude 90 at nouth edge. As encode() takes south-west coordinates, latitude 90 will be invalid.
kerrick-lyft commentedon Jul 20, 2016
The official geohash site does work with latitude == 90. For example, it encodes
(90, -122)ascrcp: http://geohash.org/crcpIn the spirit of "be liberal in what you accept", I think
encode()should work with latitude == 90, and the most reasonable thing is to return the northern-most geohash for that longitude and precision. We're seeing errors in production when latitude == 90 (probably invalid data anyway, but we'd like to avoid throwing an exception).Could you please re-consider merging #22?
hkwi commentedon Jul 21, 2016
One big problem of accepting latitude=90 is that breaks encode/decode pair. python-geohash library will do the best for precision, but loss will be introduced when converting the coordinates into angled value.
As you might already see, geohash.org does behaves very tricky on latitude=90. You see 90.000000 string representation on geohash.org, but it is not the real floating point number. IMHO, latitude=90 should be handled by application, not codec. You can use "zzzzzzzzzzzz" for "very near to northern polar".
I'm sorry I can't merge #22 .
Merge pull request hkwi#20 from MichaelChirico/ascii_only