lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1815) Geohash encode/decode floating point problems
Date Mon, 24 Aug 2009 12:09:59 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746836#action_12746836
] 

Simon Willnauer commented on LUCENE-1815:
-----------------------------------------

bq. Wouter, or anyone, do you have an idea on where the problem is, or how to fix it? 
I'm not sure if there is something to fix. Spatial uses error correction if you use GeoHashUtils#decode.
It calculates a precision values and rounds the result accordingly. If you use  GeoHashUtils#decode_exactly
 the result looks much better though if you expect the result to be very very precise.

don't know if this is a huge issue. I could change the implementation to ignore decode and
encode precision maybe that makes our impl closer to the one on google code. Again don't know
if that is really an issue. 
The lat values 52.3738007 and 52.373799999999996 are very very close so I guess you won't
even realize it on a map.

simon

> Geohash encode/decode floating point problems
> ---------------------------------------------
>
>                 Key: LUCENE-1815
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1815
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: contrib/spatial
>    Affects Versions: 2.9
>            Reporter: Wouter Heijke
>
> i'm finding the Geohash support in the spatial package to be rather unreliable.
> Here is the outcome of a test that encodes/decodes the same lat/lon and geohash a few
times.
> the format:
> action geohash=(latitude, longitude)
> the result:
> encode u173zq37x014=(52.3738007,4.8909347)
> decode u173zq37x014=(52.373799999999996,4.890934)
> encode u173zq37rpbw=(52.373799999999996,4.890934)
> decode u173zq37rpbw=(52.373799999999996,4.8909329999999995)
> encode u173zq37qzzy=(52.373799999999996,4.8909329999999995)
> if I now change to the google code implementation:
> encode u173zq37x014=(52.3738007,4.8909347)
> decode u173zq37x014=(52.37380061298609,4.890934377908707)
> encode u173zq37x014=(52.37380061298609,4.890934377908707)
> decode u173zq37x014=(52.37380061298609,4.890934377908707)
> encode u173zq37x014=(52.37380061298609,4.890934377908707)
> Note the differences between the geohashes in both situations and the lat/lon's!
> Now things get worse if you work on low-precision geohashes:
> decode u173=(52.0,4.0)
> encode u14zg429yy84=(52.0,4.0)
> decode u14zg429yy84=(52.0,3.999999)
> encode u14zg429ywx6=(52.0,3.999999)
> and google:
> decode u173=(52.20703125,4.5703125)
> encode u17300000000=(52.20703125,4.5703125)
> decode u17300000000=(52.20703125,4.5703125)
> encode u17300000000=(52.20703125,4.5703125)
> We are using geohashes extensively and will now use the google code version unfortunately.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message