Guido,
I encourage you to try to open-source the shape-related code you have to
Spatial4j. I realize that for some organizations, that can be really
difficult.
~ David
On 4/16/13 11:55 AM, "Guido Medina" wrote:
>David,
>
> I just peak it at github, the method will estimate well for our
>p
David,
I just peak it at github, the method will estimate well for our
purpose, but depends on JTS which we included in our Solr server "only",
but we don't want LGPL libraries (v3) in our main project, kind of a
show stopper, I understand is needed for spatial4j, Lucene and Solr in
general
On 4/16/13 10:57 AM, "Guido Medina" wrote:
>David,
>
>I have been following your stackoverflow posts, I understand what you
>say, we decided to change the criteria and index an extra field (close
>to your suggestion), so the sorting will happen now by polygon area desc
>(Which induced another p
David,
I have been following your stackoverflow posts, I understand what you
say, we decided to change the criteria and index an extra field (close
to your suggestion), so the sorting will happen now by polygon area desc
(Which induced another problem, calculation of polygon area on a
sphere)
Guido,
The field type solr.SpatialRecursivePrefixTreeFieldType can only
participate in distance reporting for indexed points, not other shapes.
In fact, I recommend not attempting to get the distance if the field isn't
purely indexed points, as it may get confused if it seems some small
shapes. F
Hi,
I got everything in place, my polygons are indexing properly, I played a
bit with LSP which helped me a lot, now, I have JTS 1.13 inside
solr.war; here is my challenge:
I have big polygon (A) which contains smaller polygons (B and C), B and
C have some intersection, so if I search for a
