One of the values of people reading docs for
the first time is that they uncover less-than-clear
issues. It's even more valuable if they update
the docs, so please feel free to!
Best
Erick
On Fri, Oct 28, 2011 at 9:43 AM, Christopher Gross wrote:
> Ah! That all makes sense. The example on the
Ah! That all makes sense. The example on the SpacialSearchDev page
should have that bit added in!
I'm back in business now, thanks Yonik!
-- Chris
On Fri, Oct 28, 2011 at 9:40 AM, Yonik Seeley
wrote:
> Oops, didn't mean for this conversation to leave the mailing lists.
>
> OK, so your lat a
Oops, didn't mean for this conversation to leave the mailing lists.
OK, so your lat and lon types were being stored as text but not
indexed (hence no search matches).
A dynamic field of "*" does tend to hide bugs/problems ;-)
> So should I have another for _latLon? Would it look like:
>
Yep.
On Thu, Oct 27, 2011 at 3:22 PM, Christopher Gross wrote:
> I can roll back and use the LatLon type -- but then I'm still
> concerned about the bounding box giving results outside the specified
> range.
The implementation of things like bbox are intimately tied to the
field type (i.e. normally co
True -- I found the geohash on a separate page. I was using it
because it can allow for multiple points, and I was hoping to be ahead
of the curve for allowing that feature for the data I'm managing.
I can roll back and use the LatLon type -- but then I'm still
concerned about the bounding box gi
On Thu, Oct 27, 2011 at 2:34 PM, Christopher Gross wrote:
> I'm using the geohash field to store points for my data. When I do a
> bounding box like:
>
> localhost:8080/solr/select?q=point:[-45,-80%20TO%20-24,-39]
>
> I get a data point that falls outside the box: (-73.03358
> -50.468155
