lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Smiley, David W." <>
Subject Re: custom ValueSource for decoding geohash into lat & lon
Date Fri, 11 Mar 2011 16:00:31 GMT

On Mar 10, 2011, at 6:21 PM, William Bell wrote:

> OK. But I am concerned that you are trying to bite off more than can
> be done easily. The sample call is:
> http://localhost:8983/solr/select?q=*:*&fq={!geofilt}&sfieldmulti=storemv&pt=43.17614,-90.57341&d=100&sfield=store&sort=geomultidist%28%29%20asc&sfieldmultidir=asc
> Notice that geomultidist() needs another field called storemv right
> now that is bar delimited. I tried to pull out the lat,long from
> geohash, but Dave stores the geohash values in Ngram for the purpose
> of filtering (I believe).

yep.  The field cache loader would have to filter out the "grams" not at full length.  Pretty

> Here are the issues as I see them:
> 1. ValueSources does not support MultiValue fields.
Technically it does.  A ValueSource's job seems to simply be to give access to abstract,
which has methods like double doubleVal(int doc) but also void doubleVal(int doc, double[]
vals), vals being an output-parameter.. Current use-cases assume a fixed number of values
per document, not a variable number which is what I want. But I suppose there's nothing stopping
me from using it for variable length values.  Of course the caller would have to know that.
 It's a bit unfortunate that the signature of these methods don't return the array either
since the caller doesn't know how big to make the array if it's variable length.  And again,
I suppose there's nothing stopping me from adding a different method that works the way I
want to. The only consumer of this Values/DocValues would be a special function query of my
design so it's safe.

> 2. Using ValueSource with one value is fast, and splitting it this way
> might be a lot slower to calculate distances. It is convenient, but
> could be slow. It might be better to just have solr.GeoHashField
> append to the interanal field so that it can use ValueSource directly.
> Use an internal field that uses bars internally:
> store_lat_long_bar =  39.90923,-86.19389|42.37577,-72.50858
> For each lat,long value
>    - Calculate geohash and Ngram store
>    - Append to the internal field "store_lat_long_bar" based on the field name
> Option 2 is easier and makes it supportable now without waiting for
> redesign of ValueSource.

As I suggest above, I'm not sure I really need to wait for some redesign. I could just add
the methods I want in my DocValues subclass for use by my spatial function query.

~ David Smiley

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message