lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Male (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-4186) Lucene spatial's "distErrPct" is treated as a fraction, not a percent.
Date Wed, 05 Sep 2012 14:06:07 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message