[
https://issues.apache.org/jira/browse/LUCENE-6532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583420#comment-14583420
]
Nicholas Knize commented on LUCENE-6532:
----------------------------------------
bq. I wonder if we should provide a Haversine impl (default?) that's faster but
a bit off (22 meters from your comment)?
This is an improvement area probably worth iterating over time. There are quite
a few distance formulae we can add (and optimize) that provide different
speed/accuracy trade-offs. At the moment I've only added vincenty (without the
faster helmert expansion parameter) intended for small search areas. The simple
Haversine/law of cosine implementation was already available in SloppyMath and
for the most common distance search use case is quite fast and gives reasonable
results (usually about 0.3% error). On the other hand, for highly accurate
distance calculations, Vincenty (when it converges to E-12) accuracy is
excellent at ~0.06mm - about 10mm more accurate than the morton encoding being
used to index the points. For small search areas (county level) the
convergence performance is comparable to haversine, but for large areas can
take an unreasonably long time, or even fail on nearly antipodal points. This
is why the patch is currently using Haversine. As a future improvement it might
be worthwhile adding the Lambert distance formula for large search areas. As a
comparison point, Lambert gives ~10m accuracy at 20,000 km distances where
haversine error can be as much as 2km.
bq. Do you have a simple benchmark somewhere (you mentioned a 60% speedup)?
Not presently in the patch. I used System time calculations in a few contrived
tests. I actually didn't need to go that far as the performance gain was
seconds better using ant test in verbose mode.
bq. In the 2nd patch, do you skip the polygon approximation entirely?
Yes. I skipped the process of converting the point-radius to an approximated
polygon and simplified everything by adding rectCrossesCircle and
rectWithinCircle. This made everything faster because instead of computing
rectCrossesPolygon (which requires 4*nEdges iterations) the rectCrossesCircle
method, worst case, requires 4 quadratic computations to determine whether a
cell crosses the circle. (I'm really glad you asked this because I just
realized I have some unnecessary haversine computations in that method.
Removing those and will add a new patch).
> Add GeoPointDistanceQuery for GeoPointField type
> ------------------------------------------------
>
> Key: LUCENE-6532
> URL: https://issues.apache.org/jira/browse/LUCENE-6532
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/search
> Reporter: Nicholas Knize
> Attachments: LUCENE-6532.patch, LUCENE-6532.patch
>
>
> [LUCENE-6481 | https://issues.apache.org/jira/browse/LUCENE-6481] adds
> GeoPointField w/ GeoPointInBBox and GeoPointInPolygon queries. This feature
> adds GeoPointDistanceQuery to support point radius queries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
