Pires, Guilherme wrote
> Hello David,
>
> Thanks for your response.
> I'm working deeply in this and it's fully decided that solr 4.1 + JTS is
> going to be supporting the map navigation for a 'public facing' GIS
> solution, i.e. will deliver the objects return by a bounding box
> intersection. Initially decided to index EVERYTHING and it worked fine.
> But this is in dev because I'm thinking, for production environment, I'll
> index only points and the (polygons and/or lines) pre-calculated bounds. I
> can live with the error of intersecting the bounds of an object that is
> not going to be showing in the map.
Feel free to email me privately if you don't want to disclose publicly which
it is (you didn't say on purpose I figure).
If you're indexing rectangle bounds, I suggest you take a look at
BBoxStrategy. It's in trunk but should port to 4x trivially. Ryan ported
code from ESRI GeoServer. It is probably pretty fast/scalable and it's
boundaries are precise -- not the grid approximation. It's main feature is
clever overlap percentage relevancy -- e.g. rank search results by how well
the query bbox and indexed bbox overlap. It has more memory requirements
than RPTS though.
Pires, Guilherme wrote
> Besides the navigation, I'm also querying back solr with points in polygon
> intersection for thematic mapping, heatmaps, clustering, etc. but for that
> I don't need the polygon index. On the other hand, If I later want to do
> some polygon on polygon intersection it might be handy to have a different
> field for indexing the polygon ...
Can you tell me how you're doing heatmaps and clustering?
I agree with putting the polygons into a separate field. After I finish
working on "Contains" and "Within" predicates, I may have the strategy
enforce the separation because some of the predicates have different
algorithms depending on points vs anything else. For example, people
colloquially refer to their point intersections as "I want the point
*within* this box" but the algorithm best used is the code for intersects
which is semantically equivalent if you have indexed points. If the
strategy "knew" that only points go in this field vs some other field, then
it could let you say Within and it'd do the best thing under the hood.
Presently the strategy has no idea what you're putting into it or if it's
multi-valued or not.
Pires, Guilherme wrote
> Can you give me a bit more detail on your idea of (...) writing such a
> Qparser should be pretty easy for your own needs (...)
Look at Solr QParser and some of the existing impls that are short. Writing
these things for your own needs are generally pretty easy if you can supply
the inputs all in local-params. For example you could do {!mygeo
op=Intersects shape="Polygon(....)" field="mypointfield"} That really would
be pretty easy to implement.
FYI: https://issues.apache.org/jira/browse/SOLR-4242
~ David
-----
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/solr-4-1-spatial-with-JTS-spatial-query-withitin-a-WKT-polygon-contained-within-another-query-tp4040419p4043411.html
Sent from the Solr - User mailing list archive at Nabble.com.
