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 easy. > 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 DocValues.java, 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 Author: http://www.packtpub.com/solr-1-4-enterprise-search-server/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
