lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Govoni <>
Subject Re: Spatial Solr: problem with multiValued PointType
Date Tue, 01 Jun 2010 23:57:36 GMT
This seems to be a problem (from my limited understanding). I
encountered the same thing.

And the problem is that you can have results that independently match
the constraints for latitude and longitude, but the corresponding points
would not match (i.e. with separate fields there are no longer points!).

Thusly, a correct implementation of spatial search cannot have 2
separate fields (one for lat and one for long) and expect to get
accurate results.

Not sure how Solr team is accounting for this yet.

The Spatial example on the wiki does not work in the current trunk. It
always produces results, no matter what the stored point field has in
relation to the query.

On Tue, 2010-05-04 at 16:20 +0200, wrote:

> I want to link documents to multiple spatial points, and filter
> documents based on a bounding box. I was expecting that the
> solr.PointType would help me with that, but run into a problem. When I
> create a filter, it seems that Solr matches the latitude and longitude
> of the PointType separately. Could somebody please advice me if this is
> expected behavior, and if so how to handle this usecase.
> My setup is as follows:
> in schema.xml:
>    <fieldType name="location" class="solr.PointType" dimension="2"
>    subFieldSuffix="_d"/>
>    <field name="location" type="location" indexed="true" stored="true"
>    multiValued="true"/>
> I create a document with the following locations:
>    52.3672174, 4.9126891  and:
>    52.3624717, 4.9106624
> This document will match with the filter:
>    location:[52.362,4.911 TO 52.363,4.913]
> I would have expected it not to match, since both locations are outside
> this bounding box (the longitude of the second, and the latitude of the
> first point as point would be inside the bounding box).
> Thank for any help.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message