Okay. Just to re-emphasize something I said but which may not have been clear, it isn’t an either-or for filter & sort. Filter with the spatial field type that makes sense for filtering, sort (or boost) with the spatial field type that makes sense for sorting. RPT sucks for distance sorting, LatLonType is good for it.
~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Wed, Feb 25, 2015 at 10:40 AM, <dirk.thalh...@bkg.bund.de> wrote: > Hello David, > > thanks for your answer. In the meantime I found the memory hint too in > http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4#Sorting_and_RelevancySo > > Maybe we switch to LatLonType for this kind of searches. But the RPT is > also needed as we want to support search by arbitrary polygons. > > I'm also able to use the sort=geodist() asc. This works well when I modify > the parameters to: > q=*:*&fq=typ:strasse&fq={!geofilt}&sfield=geometry&pt=51.370570625523,12.369290471603&d=1.0&sort=geofilt() > asc > > Kind regards, > > Dirk > > > Tue, 24 Feb 2015 19:42:03 GMT, david.w.smi...@gmail.com> wrote: > > Hi Dirk, > > The RPT field type can be used for distance sorting/boosting but it's a > memory pig when used as-such so don't do it unless you have to. You only > have to if you have a multi-valued point field. If you have single-valued, > use LatLonType specifically for distance sorting. > > Your sample query doesn't parse correctly for multiple reasons. You can't > put a query into the sort parameter as you have done it. You have to do > sort=query($sortQuery) asc&sortQuery=... or a slightly different > equivalent > variation. Lets say you do that... still, I don't recommend this syntax > when > you simply want distance sort - just use geodist(), as in: sort=geodist() > asc. > > If you want to use this syntax such as to sort by recipDistance, then it > would look like this (note the filter=false hint to the spatial query > parser, which otherwise is unaware it shouldn't bother actually > search/filter): > sort=query($sortQuery) desc&sortQuery={!geofilt score=recipDistance > filter=false sfield=geometry pt=51.3,12.3 d=1.0} > > If you are able to use geodist() and still find it slow, there are > alternatives involving using projected data and then with simply euclidean > calculations, sqedist(): > > https://wiki.apache.org/solr/FunctionQuery#sqedist_-_Squared_Euclidean_Distance > > ~ David Smiley > Freelance Apache Lucene/Solr Search Consultant/Developer > http://www.linkedin.com/in/davidwsmiley > > On Tue, Feb 24, 2015 at 6:12 AM, <dirk.thalh...@bkg.bund.de> wrote: > > > Hello, > > > > we are using solr 4.10.1. There are two cores for different use cases > with > > around 20 million documents (location descriptions) per core. Each > document > > has a geometry field which stores a point and a bbox field which stores a > > bounding box. Both fields are defined with: > > <fieldType name="t_geometry" > > class="solr.SpatialRecursivePrefixTreeFieldType" > > > > > spatialContextFactory="com.spatial4j.core.context.jts.JtsSpatialContextFactory" > > geo="true" distErrPct="0.025" maxDistErr="0.00009" > > units="degrees" /> > > > > I'm currently trying to add a location search (find all documents around > a > > point). My intention is to add this as filter query, so that the user is > > able to do an additional keyword search. These are the query parameters > so > > far: > > q=*:*&fq=typ:strasse&fq={!geofilt sfield=geometry > > pt=51.370570625523,12.369290471603 d=1.0} > > To sort the documents by their distance to the requested point, I added > > following sort parameter: > > sort={!geofilt sort=distance sfield: geometry > > pt=51.370570625523,12.369290471603 d=1.0} asc > > > > Unfortunately I'm experiencing here some major performance/memory > > problems. The first distance query on a core takes over 10 seconds. In my > > first setup the same request to the second core completely blocked the > > server and caused an OutOfMemoryError. I had to increase the memory to 16 > > GB and now it seems to work for the geometry field. Anyhow the first > > request after a server restart takes some time and when I try it with the > > bbox field after a requested on the geometry field in both cores, the > > server blocks again. > > > > Can anyone explain why the distance needs so much memory? Can this be > > optimized? > > > > Kind regards, > > > > Dirk > > > > > >
