[
https://issues.apache.org/jira/browse/SOLR-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997264#comment-12997264
]
Bill Bell edited comment on SOLR-2155 at 2/21/11 3:12 AM:
----------------------------------------------------------
Lance,
Thanks. But in order to use PointType I need the ability to append another
parameter to the suffix for the lat,long pair.
{code}
71 suffixes = new String[dimension];
72 for (int i=0; i<dimension; i++) {
73 suffixes[i] = "_" + i + suffix;
74 }
{code}
This would add "geohash_1_<suffix>" and "geohash_2_<suffix>" for a 2
dimensional field (Lat,Long). If I add 2 values in the same name, it will just
overwrite the field (as is the case now)...
I personally don't like the way this was done. It focuses on the dimension,
where I need to focus on the number of multiValue pairs. I guess we could do
something like the following as we build the array:
dimension=2... That is static for lat,long and can be in the schema.xml. I need
to add another number to pair these.
suffixes[] = multivalue_index + "_" + i + suffix
geohash_0_0_suffix = 43.17614
geohash_0_1_suffix = -90.57341
geohash_1_0_suffix = next point
geohash_1_1_suffix = next point
Does it also make sense to have:
geohash_num_suffix = 2 (the number of multivalue pairs in this document).
I toyed with having a maxmultivalue=10, but thought that would be pretty
inefficient. This should not be static, since the number of pairs of lat,long -
could go from 1 to 25 on each document.
I could easily take PointType.java and create a new MultiPointType.java and add
these to the createFields() for the document.
I might be missing things that also need to be done to support something like
this. I might make sense to just extend PointType.java to work with mutliValued
types. I don't want to break anything else.
Bill
was (Author: billnbell):
Lance,
Thanks. But in order to use PointType I need the ability to append another
parameter to the suffix for the lat,long pair.
71 suffixes = new String[dimension];
72 for (int i=0; i<dimension; i++) {
73 suffixes[i] = "_" + i + suffix;
74 }
This would add "geohash_1_<suffix>" and "geohash_2_<suffix>" for a 2
dimensional field (Lat,Long). If I add 2 values in the same name, it will just
overwrite the field (as is the case now)...
I personally don't like the way this was done. It focuses on the dimension,
where I need to focus on the number of multiValue pairs. I guess we could do
something like the following as we build the array:
dimension=2... That is static for lat,long and can be in the schema.xml. I need
to add another number to pair these.
suffixes[] = multivalue_index + "_" + i + suffix
geohash_0_0_suffix = 43.17614
geohash_0_1_suffix = -90.57341
geohash_1_0_suffix = next point
geohash_1_1_suffix = next point
Does it also make sense to have:
geohash_num_suffix = 2 (the number of multivalue pairs in this document).
I toyed with having a maxmultivalue=10, but thought that would be pretty
inefficient. This should not be static, since the number of pairs of lat,long -
could go from 1 to 25 on each document.
I could easily take PointType.java and create a new MultiPointType.java and add
these to the createFields() for the document.
I might be missing things that also need to be done to support something like
this. I might make sense to just extend PointType.java to work with mutliValued
types. I don't want to break anything else.
Bill
> Geospatial search using geohash prefixes
> ----------------------------------------
>
> Key: SOLR-2155
> URL: https://issues.apache.org/jira/browse/SOLR-2155
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Attachments: GeoHashPrefixFilter.patch, GeoHashPrefixFilter.patch,
> GeoHashPrefixFilter.patch, SOLR.2155.p3.patch, SOLR.2155.p3tests.patch
>
>
> There currently isn't a solution in Solr for doing geospatial filtering on
> documents that have a variable number of points. This scenario occurs when
> there is location extraction (i.e. via a "gazateer") occurring on free text.
> None, one, or many geospatial locations might be extracted from any given
> document and users want to limit their search results to those occurring in a
> user-specified area.
> I've implemented this by furthering the GeoHash based work in Lucene/Solr
> with a geohash prefix based filter. A geohash refers to a lat-lon box on the
> earth. Each successive character added further subdivides the box into a 4x8
> (or 8x4 depending on the even/odd length of the geohash) grid. The first
> step in this scheme is figuring out which geohash grid squares cover the
> user's search query. I've added various extra methods to GeoHashUtils (and
> added tests) to assist in this purpose. The next step is an actual Lucene
> Filter, GeoHashPrefixFilter, that uses these geohash prefixes in
> TermsEnum.seek() to skip to relevant grid squares in the index. Once a
> matching geohash grid is found, the points therein are compared against the
> user's query to see if it matches. I created an abstraction GeoShape
> extended by subclasses named PointDistance... and CartesianBox.... to support
> different queried shapes so that the filter need not care about these details.
> This work was presented at LuceneRevolution in Boston on October 8th.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
