search

DeaconDesperado / python-geohash

Automatically exported from code.google.com/p/python-geohash
0 stars 0 forks source link

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

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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