Hi! Sorry for the belated response; my google alerts didn't kick in for some weird reason until you posted to the lucene dev list.
solr-user wrote > > hopefully someone is using the lucene spatial toolkit aka LSP aka > spatial4j, and can answer this question > > we are using this spatial tool for doing searches. overall, it seems to > work very well. however, finding documentation is difficult. > > I'm using it ;-) The current in-progress documentation is here: http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4 solr-user wrote > > > I have a couple of questions: > > 1. I have a geohash field in my solr schema that contains indexed > geographic polygon data. I want to find all docs where that polygon > intersects a given lat/long. I was experimenting with returning distance > in the resultset and with sorting by distance and found that the following > query works. However, I dont know what distance means in the query. i.e. > is it distance from point to the polygon centroid, to the closest outer > edge of the polygon, its a useless random value, etc. Does anyone know?? > > http://solrserver:solrport/solr/core0/select?q=*:*&fq={!v=$geoq%20cache=false}&geoq=wkt_search:%22Intersects(Circle(-97.057%2047.924%20d=0.000001))%22&sort=query($geoq)+asc&fl=catchment_wkt1_trimmed,school_name,latitude,longitude,dist:query($geoq,-1),loc_city,loc_state > It's from the center of the indexed shape to the center of the query shape. At some point soonish, the score of a geo query is going to be similar to the inverted distance so that it's a better relevancy metric which is what scores should be. I expect some alternative means to show up to actually get the distance in search results -- perhaps a special Solr function query. solr-user wrote > > 2. some of the polygons, being geographic representations, are very big > (ie state/province polygons). when solr starts processing a spatial query > (like the one above), I can see ("INFO: Building Cache [xxxxxx]") it fills > in some sort of memory cache > (org.apache.lucene.spatial.strategy.util.ShapeFieldCache) of the indexed > polygon data. We are encountering Java OOM issues when this occurs (even > when we booested the mem to 7GB). I know that some of the polygons can > have more than 2300 points, but heavy trimming isn't really an option due > to level of detail issues. Can we control this caching, or the indexing of > the polygons, in any way to reduce the memory requirements?? > All center points get cached into memory upon first use in a score. I'm unsatisfied with the current details of this which is not real-time-search friendly and is a memory pig since it's a ArrayList of ArrayList of PointImpl objects. If you have a single shape value per field, then I suggest indexing the center point into a solr.LatLonType field for sorting, which uses the lucene FieldCache and it'll use much less memory. Consider making it float based to halve your memory requirements further. p.s. I suggest "watching" this JIRA issue: https://issues.apache.org/jira/browse/SOLR-3304 ~ David Smiley ----- Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/question-s-re-lucene-spatial-toolkit-aka-LSP-aka-spatial4j-tp3997757p4000024.html Sent from the Solr - User mailing list archive at Nabble.com.
