I think I've missed something. From what I'm seeing it appears that a
bounding box is being built from my polygon and any points in that
bounding box are returned. This makes sense from the debug which says
the query is
+(+point__x:[-75.267333984375 TO -74.569702148438]
+point__y:[39.512329101563 TO 40.523071289063])
+DistanceValueSource(org.apache.lucene.spatial.base.distance.EuclidianDistanceCalculator@c7d9406)
Given that does point support doing what I am trying to do or should I
be using another field type?
I understand that you're busy so no rush on this.
On Thu, Jul 21, 2011 at 11:48 AM, Jamie Johnson <jej2...@gmail.com> wrote:
> Thanks for the reply.
>
> My setup has a point in the field and a shape as the query. Given
> this it sounds as if I can get more precise results by changing the
> distErrPct on a query parameter. I'll give this a whirl. Again thank
> you.
>
>
> On Thu, Jul 21, 2011 at 11:13 AM, Smiley, David W. <dsmi...@mitre.org> wrote:
>> If you are talking about indexed shapes, then there is an attribute on the
>> field type definition in your schema called "distErrPct". Reasonable values
>> are between .01 and .20, in my opinion. The default is .025, but try
>> setting it to .01. For points, use the "maxDetailKm" parameter, which is
>> the kilometer detail level. By default, that parameter is .001 -- 1 meter.
>>
>> If you are talking about your query shape, then this same parameter can be
>> supplied as a request parameter. Again, the default is .025. The
>> RecursiveGridFieldType can handle infinite query side precision, so you can
>> supply 0 and still get reasonable performance. However if your indexing side
>> is a certain precision, then there's little point in using more precision on
>> the query side since in-effect it's as accurate as your index side.
>>
>> If you're wondering more about the meaning of distErrPct, see this snippet
>> from SpatialArgs.java:
>> /**
>> * The fraction of the distance from the center of the query shape to its
>> nearest edge that is considered acceptable
>> * error. The algorithm for computing the distance to the nearest edge is
>> actually a little different. It normalizes
>> * the shape to a square given it's bounding box area:
>> * <pre>sqrt(shape.bbox.area)/2</pre>
>> * And the error distance is beyond the shape such that the shape is a
>> minimum shape.
>> */
>> public Double getDistPrecision() {
>>
>> ~ David
>>
>> On Jul 20, 2011, at 5:44 PM, Jamie Johnson wrote:
>>
>>> Thanks David. When trying to execute queries on a complex irregular
>>> polygon (say the shape of NJ) I'm getting results which are actually
>>> outside of that polygon. Is there a setting which controls this
>>> resolution?
>>>
>>> On Wed, Jul 20, 2011 at 2:53 PM, Smiley, David W. <dsmi...@mitre.org> wrote:
>>>> The notion of a "system property" is a java concept; google it and you'll
>>>> learn more.
>>>>
>>>> BTW, despite my responsiveness in helping right now; I'm pretty busy this
>>>> week so this won't necessarily last long.
>>>> ~ David
>>>>
>>>> On Jul 20, 2011, at 2:43 PM, Jamie Johnson wrote:
>>>>
>>>>> Where do you set that?
>>>>>
>>>>> On Wed, Jul 20, 2011 at 2:37 PM, Smiley, David W. <dsmi...@mitre.org>
>>>>> wrote:
>>>>>> You can set the system property SpatialContextProvider to
>>>>>> com.googlecode.lucene.spatial.base.context.JtsSpatialContext
>>>>>>
>>>>>> ~ David
>>>>>>
>>>>>> On Jul 20, 2011, at 2:02 PM, Jamie Johnson wrote:
>>>>>>
>>>>>>> So I've pulled the latest and can run the example, I've tried to move
>>>>>>> my config over and am having a bit of an issue when executing queries,
>>>>>>> specifically I get this:
>>>>>>>
>>>>>>> Unable to read: POLYGON((...
>>>>>>>
>>>>>>> looking at the code it's usign the simple spatial context, how do I
>>>>>>> specify JtsSpatialContext?
>>>>>>>
>>>>>>> On Wed, Jul 20, 2011 at 12:13 PM, Jamie Johnson <jej2...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Thanks for the update David, I'll give that a try now.
>>>>>>>>
>>>>>>>> On Wed, Jul 20, 2011 at 10:58 AM, Smiley, David W. <dsmi...@mitre.org>
>>>>>>>> wrote:
>>>>>>>>> Ryan just updated LSP for Lucene/Solr trunk compatibility so you
>>>>>>>>> should do a "mvn clean install" and you'll be back in business.
>>>>>>>>>
>>>>>>>>> On Jul 20, 2011, at 10:37 AM, Jamie Johnson wrote:
>>>>>>>>>
>>>>>>>>>> Thanks for responding so quickly, I don't mind waiting a bit. I'll
>>>>>>>>>> hang out until the updates have been made. Thanks again.
>>>>>>>>>>
>>>>>>>>>> On Tue, Jul 19, 2011 at 3:51 PM, Smiley, David W.
>>>>>>>>>> <dsmi...@mitre.org> wrote:
>>>>>>>>>>> Hi Jamie.
>>>>>>>>>>> I work on LSP; it can index polygons and query for them. Although
>>>>>>>>>>> the capability is there, we have more testing & benchmarking to do,
>>>>>>>>>>> and then we need to put together a tutorial to explain how to use
>>>>>>>>>>> it at the Solr layer. I recently cleaned up the READMEs a bit.
>>>>>>>>>>> Try downloading the trunk codebase, and follow the README. It
>>>>>>>>>>> points to another README which shows off a demo webapp. At the
>>>>>>>>>>> conclusion of this, you'll need to examine the tests and webapp a
>>>>>>>>>>> bit to figure out how to apply it in your app. We don't yet have a
>>>>>>>>>>> tutorial as the framework has been in flux although it has
>>>>>>>>>>> stabilized a good deal.
>>>>>>>>>>>
>>>>>>>>>>> Oh... by the way, this works off of Lucene/Solr trunk. Within the
>>>>>>>>>>> past week there was a major change to trunk and LSP won't compile
>>>>>>>>>>> until we make updates. Either Ryan McKinley or I will get to that
>>>>>>>>>>> by the end of the week. So unless you have access to 2-week old
>>>>>>>>>>> maven artifacts of Lucene/Solr, you're stuck right now.
>>>>>>>>>>>
>>>>>>>>>>> ~ David Smiley
>>>>>>>>>>> Author: http://www.packtpub.com/solr-1-4-enterprise-search-server/
>>>>>>>>>>>
>>>>>>>>>>> On Jul 19, 2011, at 3:03 PM, Jamie Johnson wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I have looked at the code being shared on the
>>>>>>>>>>>> lucene-spatial-playground and was wondering if anyone could provide
>>>>>>>>>>>> some details as to its state. Specifically I'm looking to add
>>>>>>>>>>>> geospatial support to my application based on a user provided
>>>>>>>>>>>> polygon,
>>>>>>>>>>>> is this currently possible using this extension?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
