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, so we have no issues keeping it at the Solr server. But can't
put it on main web project for licensing issues. I know JTS is a great
set of needed functions for spatial projects. Shame I can't use it
directly, like I had to develop some convex hull by myself.
Guido.
On 16/04/13 16:14, Smiley, David W. wrote:
On 4/16/13 10:57 AM, "Guido Medina" <guido.med...@temetra.com> 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 problem, calculation of polygon area on a
sphere), finally I got to the point of testing, also due to what you are
saying, is not a good idea to overload more than just the bare use of
points (Intersects) inside polygon to get the the list that matches
specific criteria.
Glad you've been following what I've been up to and hopefully haven't
gotten too confused :-). I welcome all feedback. BTW I'll be doing a 75
minute spatial "deep dive" session at the Lucene/Solr Revolution
conference in San Diego May 1st & 2nd. Eventually the slides will be
posted and hopefully the audio track.
To resume, calculate the "area of the polygon", again, for curved
polygons is not so obvious, do the standard solr search and sort by that
extra field, I guess solr overhead will be minimal in that case.
FYI Spatial4j will do a decent job estimating it by calculating the
geospatial area of the bounding box of a polygon and using the filled %
ratio of the polygons 2D area to its Bbox. This logic is in Spatial4j's
JtsGeometry.getArea().
So are you storing the area and sorting by it then? (overhead is
extremely minimal, this would just be an integer sort)
The real use case is for utility industry, let's say users have areas
where they get meter reads, readings are scheduled and assigned to the
users that contains such meter GPS location, some users might cover big
areas and possible to have smaller areas for other users inside such big
areas, so we changed the distance to center for area covered by, seemed
simpler and easier.
You might want to consider doing both -- sort by a function query that
combines both factors in some clever way.
~ David
