[
https://issues.apache.org/jira/browse/LUCENE-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448758#comment-13448758
]
Chris Male commented on LUCENE-4186:
------------------------------------
bq. SpatialArgs.toString()'s logic was moved to SpatialArgsParser as
writeSpatialArgs(args) since it looks so close to the parsed format and I'd
like to see it parsed and written in the same class.
+1 Makes sense
bq. SpatialArgs.toString() fixes the bug in displaying the error percent that
Itamar noticed.
+1
bq. Standardizes "distErrPct" terminology in variables and method names.
Despite the "pct" it's actually a fraction [0 to 0.5].
+1 Do we validate somewhere that the values are between 0 and 0.5?
bq. Instead of SpatialArgs.distErrPct defaulting to 0.025 it defaults to null.
Now the Strategy's own distErrPct (which defaults to 0.025) is supplied to
args.resolveDistErr(...) so it can see if the args overrides the one in
strategy or not.
If I understand correctly, your motivation for doing this is so in the default
scenario (when no pct is defined) you have the same value at both index time
and query time, correct? I'm starting to wonder whether it makes sense to allow
the value to be set per request. Having the same value at both index and query
time seems ideal so perhaps we should force the value, whether it be the pct or
absolute value, be provided at construction of the Strategy.
bq. SpatialArgs gains a "distErr" field, parsed from SpatialArgsParser. This is
an alternative means that a search request can specify the distance in a more
direct way.
So can the user now provide either the the distErr or distErrPct and if they
provide the later, it is converted to the former seamlessly? Or must the user
do the conversion themselves? I'm +1 for the first option.
bq. One thing I didn't do, is move the distErrPct getter & setter up from
PrefixTreeStrategy to the base SpatialStrategy.
Why would we want to move it to SpatialStrategy? It seems unrelated to the
other Strategies.
> Lucene spatial's "distErrPct" is treated as a fraction, not a percent.
> ----------------------------------------------------------------------
>
> Key: LUCENE-4186
> URL: https://issues.apache.org/jira/browse/LUCENE-4186
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Critical
> Fix For: 4.0
>
> Attachments: LUCENE-4186_distErrPct_upgrade.patch
>
>
> The distance-error-percent of a query shape in Lucene spatial is, in a
> nutshell, the percent of the shape's area that is an error epsilon when
> considering search detail at its edges. The default is 2.5%, for reference.
> However, as configured, it is read in as a fraction:
> {code:xml}
> <fieldType name="location_2d_trie"
> class="solr.SpatialRecursivePrefixTreeFieldType"
> distErrPct="0.025" maxDetailDist="0.001" />
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
