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
