It seems like there is a reasonably high level of inaccuracy compared to geohasher

[GoogleCodeExporter]

What steps will reproduce the problem?

>>> import geohash
>>> geohash.encode_uint64(51.566141,-0.009434)
15006294212117284100L
>>> geohash.decode_uint64(15006294212117284100L)
(51.56614095903933, 0.0)

>>> geohash.encode(51.566141,-0.009434)
'u10j2524812h'
>>> geohash.decode('u10j2524812h')
(51.56614095903933, 1.6763806343078613e-07)


>>> from geohasher import hasher
>>> hasher.encode(51.566141,-0.009434)
8857379509972789038
>>> hasher.decode(8857379509972789038)
(51.56614095903933, -0.0094340834766626358)


What is the expected output? What do you see instead?
I would expect that the decoded code would be within a hundred meters or so of 
the encoded distance.  The geohasher module seems to do this.

What version of the product are you using? On what operating system?
0.83.  Reproduced on Ubuntu 10.10 and Mac OS X 10.6.7

Please provide any additional information below.

Original issue reported on code.google.com by jason.ti...@gmail.com on 4 Jun 2011 at 3:36

[GoogleCodeExporter]

Is this expected behavior?  It seems like sometimes the points are 10-15 miles 
away from the original point.

Original comment by jason.ti...@gmail.com on 12 Jun 2011 at 6:45

[GoogleCodeExporter]

Thank you for the report and I'm sorry for so delayed response.
This issue was fixed at r236 and 0.8.4 will be released soon.

Original comment by Hiroaki.Kawai@gmail.com on 1 Sep 2011 at 5:55

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by Hiroaki.Kawai@gmail.com on 1 Sep 2011 at 6:13

[GoogleCodeExporter]

Does it now produce the same geohash codes as the other libraries?

Original comment by jason.ti...@gmail.com on 1 Sep 2011 at 6:22

[GoogleCodeExporter]

I did not test against the other libraries, but C extension version now produce 
the same hash code with pure python vertion.

Original comment by Hiroaki.Kawai@gmail.com on 1 Sep 2011 at 7:25

[GoogleCodeExporter]

Still seeing the same issue with 0.8.4 - 

>>> geohash.encode_uint64(51.566141,-0.009434)
15006294212117284100L
>>> geohash.decode_uint64(15006294212117284100)
(51.56614095903933, 0.0)
>>> 
>>> hasher.encode(51.566141,-0.009434)
8857379509972789038
>>> hasher.decode(8857379509972789038)
(51.56614095903933, -0.009434083476662636)

Seems like it could be connected to the following issues I see while compiling 
on Mac OS X 10.7 -

python-geohash-0.8.4 jasontitus$ /usr/bin/python setup.py install
running install
running build
running build_py
creating build
creating build/lib.macosx-10.7-intel-2.7
copying geohash.py -> build/lib.macosx-10.7-intel-2.7
copying quadtree.py -> build/lib.macosx-10.7-intel-2.7
copying jpgrid.py -> build/lib.macosx-10.7-intel-2.7
copying jpiarea.py -> build/lib.macosx-10.7-intel-2.7
running build_ext
building '_geohash' extension
creating build/temp.macosx-10.7-intel-2.7
creating build/temp.macosx-10.7-intel-2.7/src
llvm-gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe -fno-common 
-fno-strict-aliasing -fwrapv -mno-fused-madd -DENABLE_DTRACE -DMACOSX -DNDEBUG 
-Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall 
-Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch x86_64 -pipe 
-DPYTHON_MODULE=1 
-I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c 
src/geohash.cpp -o build/temp.macosx-10.7-intel-2.7/src/geohash.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
src/geohash.cpp: In function 'int double_to_i64(double, uint64_t*)':
src/geohash.cpp:91: warning: implicit conversion shortens 64-bit value into a 
32-bit value
src/geohash.cpp:92: warning: implicit conversion shortens 64-bit value into a 
32-bit value
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
src/geohash.cpp: In function 'int double_to_i64(double, uint64_t*)':
src/geohash.cpp:91: warning: implicit conversion shortens 64-bit value into a 
32-bit value
src/geohash.cpp:92: warning: implicit conversion shortens 64-bit value into a 
32-bit value
src/geohash.cpp: In function 'int uint8s_plus_minus(uint8_t*, uint8_t*, size_t, 
int)':
src/geohash.cpp:383: warning: implicit conversion shortens 64-bit value into a 
32-bit value
src/geohash.cpp: In function 'int neighbors(uint16_t*, size_t, uint16_t*, 
size_t, size_t*)':
src/geohash.cpp:428: warning: implicit conversion shortens 64-bit value into a 
32-bit value
src/geohash.cpp:429: warning: implicit conversion shortens 64-bit value into a 
32-bit value
src/geohash.cpp: In function 'int geo_neighbors_impl(char*, char*, size_t, 
int*)':
src/geohash.cpp:528: warning: implicit conversion shortens 64-bit value into a 
32-bit value
src/geohash.cpp: In function 'PyObject* py_geohash_decode(PyObject*, 
PyObject*)':
src/geohash.cpp:571: warning: implicit conversion shortens 64-bit value into a 
32-bit value
llvm-g++-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -Wl,-F. -arch i386 -arch 
x86_64 build/temp.macosx-10.7-intel-2.7/src/geohash.o -o 
build/lib.macosx-10.7-intel-2.7/_geohash.so
running install_lib

Original comment by jason.ti...@gmail.com on 2 Sep 2011 at 10:38

[GoogleCodeExporter]

Humm, I'll prepare a Mac. Please wait for next Monday.

Original comment by Hiroaki.Kawai@gmail.com on 2 Sep 2011 at 1:21

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

On  my MacOS (10.6.8), the code runs successfully.
Darwin hostname 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 
2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

Humm... it seems strange. Is this issue MacOS 10.7 specific?

Original comment by Hiroaki.Kawai@gmail.com on 5 Sep 2011 at 12:34

[GoogleCodeExporter]

I built python with llvmgcc on MacOS 10.6 and worked successfully.
 Python-3.2.2 kawai$ CC=llvm-gcc CXX=llvm-g++ ./configure --prefix=/Users/kawai/pytest

I want a feedback again.

Original comment by Hiroaki.Kawai@gmail.com on 5 Sep 2011 at 5:26

[GoogleCodeExporter]

I was using the newest Xcode off of the Apple developer site.  I'll try
changing to gcc.

Original comment by jason.ti...@gmail.com on 5 Sep 2011 at 5:47

[GoogleCodeExporter]

I got one MacOS 10.7 and tested the code. It ran successfully. So I'd change 
the status to Fixed again.
 Darwin hostname 11.1.0 Darwin Kernel Version 11.1.0: Tue Jul 26 16:07:11 PDT 2011; root:xnu-1699.22.81~1/RELEASE_X86_64 x86_64

By the way, I will change the code for the compiler warnings.

Original comment by Hiroaki.Kawai@gmail.com on 7 Sep 2011 at 2:12

• Changed state: Fixed