You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by "Parks, Harley" <Ha...@apan-info.net> on 2013/03/07 02:32:39 UTC
Migrate Solr 3.4 w/ solr-1255 GeoHash to Solr 4
I'm having trouble migrating the geohash fields from my Solr 3.4 schema
to the Solr 4 schema.
this is the 3.4 type and class:
<fieldType name="geohash" class="solr2155.solr.schema.GeoHashField"
length="12"/>
is the below Solr 4 spatial type the right configuration to implement
data being stored in fields once using the "geohash" type and class in
the above solr 3.4 field type?
<fieldType name="geohash"
class="solr.SpatialRecursivePrefixTreeFieldType"
geo="true" distErrPct="0.025" maxDistErr="0.000009" units="degrees"
prefixTree="geohash" />
is the units="degrees" degree decimal? example: 21.0345
Harley Powers Parks, GISP
RE: Migrate Solr 3.4 w/ solr-1255 GeoHash to Solr 4
Posted by "David Smiley (@MITRE.org)" <DS...@mitre.org>.
The underling index format is unchanged between SOLR-2155 and Solr 4 provided
that this is only about indexing points, and SOLR-2155 could only index
points any way. To really ensure it's drop-in compatible, specify
maxLevels=12 *instead of* setting maxDistErr (which indirectly derives a
maxLevels) so you can be sure the levels are the same.
Also, SOLR-2155 always did full query shape precision (to as much as the
maxLevels indexed length allows of course). By default,
SpatialRecursivePrefixTreeFieldType uses 2.5% of the query shape radius as
its accuracy, which buys a little more performance at the expense of
accuracy. You can set distErrPct="0" if you require full precision. For
example you might need a meter of indexed precision for the case when
someone zooms in really low to some small region, but if the search is a
huge area of an entire country or state, then do you truly need a meter
precision along the edge for that case too? I think not. distErrPct is
relative to the overall size of the query shape. The default I think is
probably fine but people have observed its inaccuracy, particularly when a
point is plotted outside a drawn query box and thought it was a problem with
the spatial code when it's actually a configuration default. 0 is actually
quite scalable provided there isn't a ton of indexed data coinciding with
the query shape edge along the query shape's entire edge.
I'd be interested to hear if the Solr 4 version is faster/slower if you have
any benchmarks -- especially v4.2 due out soon, but earlier 4.x should be
nearly the same.
It's weird that you're seeing the stored value coming back in search results
as a geohash. In Solr 4 you get precisely what you added.
~ David
Harley wrote
> Hi David Smiley:
> We use a 3rd party software to load Solr 3.4 so the behavior needs to be
> transparent with the migration to 4.1, but I was expecting that I would
> need to rebuild the solr database.
>
> I moved/added the old solr 3.4 core to solr 4.1, with only minor
> modification (commented out the old spatial type and add the new) and I
> was surprised I was able to query the data.
>
> The geohash is displaying as a hash, and not coordinate, so I am checking
> my configuration on the geospatial class.
>
>
>
>
>
> Harley Powers Parks, GISP
> Booz | Allen | Hamilton
> Geospatial Visualization Web Developer
>
> WEB: https://www.apan.org
>
> USPACOM J73/APAN
> Pacific Warfighting Center Ford Island
>
> p: 808.472.7752
> c: 808.377.0632
> apan:
> harley.parks@
> nipr:
> harley.parks.ctr@
>
> CONTRACTOR:
> Booz | Allen | Hamilton
> e:
> parks_harley@
>
>
>
> -----Original Message-----
> From: David Smiley (@MITRE.org) [mailto:
> DSMILEY@
> ]
> Sent: Wednesday, March 06, 2013 9:34 PM
> To:
> solr-user@.apache
> Subject: Re: Migrate Solr 3.4 w/ solr-1255 GeoHash to Solr 4
>
> Hi Harley,
>
> See: http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4
> In SOLR-2155 you had to explicitly specify the prefix encoding length,
> whereas in Solr 4 you specify how much precision you need and it figures
> out what the length is that satisfies that. When you first use the field,
> it'll log what the derived levels figure is (if you care). The units are
> decimal degrees (0-180 from no distance to reverse side of the globe --
> aka latitudinal degrees).
>
> You can name the field type whatever you want, but I don't recommend
> "geohash" because this conflates it with an actual GeoHashField, and also
> it's more of an internal detail.
>
> You said you're having trouble with the migration... but what is the
> trouble?
>
> ~ David
>
>
> Harley wrote
>> I'm having trouble migrating the geohash fields from my Solr 3.4
>> schema to the Solr 4 schema.
>>
>> this is the 3.4 type and class:
>>
> <fieldType name="geohash" class="solr2155.solr.schema.GeoHashField"
>>
> length="12"/>
>> is the below Solr 4 spatial type the right configuration to implement
>> data being stored in fields once using the "geohash" type and class in
>> the above solr 3.4 field type?
>>
> <fieldType name="geohash"
>>
> class="solr.SpatialRecursivePrefixTreeFieldType"
>> geo="true" distErrPct="0.025" maxDistErr="0.000009" units="degrees"
>> prefixTree="geohash" />
>> is the units="degrees" degree decimal? example: 21.0345
>>
>>
>>
>> Harley Powers Parks, GISP
>
>
>
>
>
> -----
> Author:
> http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Migrate-Solr-3-4-w-solr-1255-GeoHash-to-Solr-4-tp4045416p4045470.html
> Sent from the Solr - User mailing list archive at Nabble.com.
-----
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: http://lucene.472066.n3.nabble.com/Migrate-Solr-3-4-w-solr-1255-GeoHash-to-Solr-4-tp4045416p4045835.html
Sent from the Solr - User mailing list archive at Nabble.com.
RE: Migrate Solr 3.4 w/ solr-1255 GeoHash to Solr 4
Posted by "Parks, Harley" <Ha...@apan-info.net>.
Yes. Success.
I was able to successfully migrate solr 3.4 w/ solr-2155 solrconfig.xml
and schema.xml; but I had to rebuild the database (solr index data
folder).
<fieldType name="geohash_rpt"
class="solr.SpatialRecursivePrefixTreeFieldType"
geo="true" distErrPct="0" maxLevels="12" units="degrees"
prefixTree="geohash"/>
Everything seems to be working.
I need to try and see if I can convert the old 3.4 database... but when
we upgrade, we always rebuild our solr index.
-----Original Message-----
From: David Smiley (@MITRE.org) [mailto:DSMILEY@mitre.org]
Sent: Friday, March 08, 2013 6:56 AM
To: solr-user@lucene.apache.org
Subject: RE: Migrate Solr 3.4 w/ solr-1255 GeoHash to Solr 4
You're supposed to add geo point data in "latitude, longitude" format,
although some other variations work. Is your updating process supplying
a geohash instead? If so you could write a simple Solr
UpdateRequestProcessor to convert it to the expected format. But that
doesn't help the fact that apparently you're index already has a geohash
for the stored field value.
Are all your fields either stored fields or aren't but are copied from a
stored field? It would then be an option to dump all data via CSV (take
care for multi-value fields) then load it into an empty instance.
You could "optimize" your index, which upgrades as a side-effect.
FYI there's a Lucene "IndexUpgrader" you can use at the command line:
http://lucene.apache.org/core/4_1_0/core/org/apache/lucene/index/IndexUp
grader.html
But again, if your stored field values are geohashes when you want a
lat,lon then this isn't going to fix that.
~ David
Harley wrote
> David Smiley:
> Because we use a 3rd party software.. I checked to see if this would
> still worked... search query still works. But adding data seems to be
> broken, likely because of the geohash type.
>
> So, below is the log file, which tells me to upgrade
>
> If possible, it would be great to simply get the old 3.4 index
working.
> What should my workflow be to get this working as is, then to upgrade?
>
> I'm expecting to delete the data folder, then rebuild the index via
> 3rd party software adding data to Solr 4... is it' possible to reindex
> the existing data folder?
-----
Author:
http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Migrate-Solr-3-4-w-solr-1255-GeoHash-
to-Solr-4-tp4045416p4045836.html
Sent from the Solr - User mailing list archive at Nabble.com.
RE: Migrate Solr 3.4 w/ solr-1255 GeoHash to Solr 4
Posted by "David Smiley (@MITRE.org)" <DS...@mitre.org>.
You're supposed to add geo point data in "latitude, longitude" format,
although some other variations work. Is your updating process supplying a
geohash instead? If so you could write a simple Solr UpdateRequestProcessor
to convert it to the expected format. But that doesn't help the fact that
apparently you're index already has a geohash for the stored field value.
Are all your fields either stored fields or aren't but are copied from a
stored field? It would then be an option to dump all data via CSV (take
care for multi-value fields) then load it into an empty instance.
You could "optimize" your index, which upgrades as a side-effect.
FYI there's a Lucene "IndexUpgrader" you can use at the command line:
http://lucene.apache.org/core/4_1_0/core/org/apache/lucene/index/IndexUpgrader.html
But again, if your stored field values are geohashes when you want a lat,lon
then this isn't going to fix that.
~ David
Harley wrote
> David Smiley:
> Because we use a 3rd party software.. I checked to see if this would still
> worked... search query still works. But adding data seems to be broken,
> likely because of the geohash type.
>
> So, below is the log file, which tells me to upgrade
>
> If possible, it would be great to simply get the old 3.4 index working.
> What should my workflow be to get this working as is, then to upgrade?
>
> I'm expecting to delete the data folder, then rebuild the index via 3rd
> party software adding data to Solr 4... is it' possible to reindex the
> existing data folder?
-----
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: http://lucene.472066.n3.nabble.com/Migrate-Solr-3-4-w-solr-1255-GeoHash-to-Solr-4-tp4045416p4045836.html
Sent from the Solr - User mailing list archive at Nabble.com.
RE: Migrate Solr 3.4 w/ solr-1255 GeoHash to Solr 4
Posted by "Parks, Harley" <Ha...@apan-info.net>.
David Smiley:
Because we use a 3rd party software.. I checked to see if this would still worked... search query still works. But adding data seems to be broken, likely because of the geohash type.
So, below is the log file, which tells me to upgrade
If possible, it would be great to simply get the old 3.4 index working.
What should my workflow be to get this working as is, then to upgrade?
I'm expecting to delete the data folder, then rebuild the index via 3rd party software adding data to Solr 4... is it' possible to reindex the existing data folder?
--- Harley ---
16:11:35 WARNING FieldTypePluginLoader StopFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader LowerCaseFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader EnglishPossessiveFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader KeywordMarkerFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader PorterStemFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader WhitespaceTokenizerFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader SynonymFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader StopFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader WordDelimiterFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader LowerCaseFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader KeywordMarkerFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader PorterStemFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader WhitespaceTokenizerFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader StopFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader WordDelimiterFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader LowerCaseFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader KeywordMarkerFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader PorterStemFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader WhitespaceTokenizerFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader SynonymFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader StopFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader WordDelimiterFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader LowerCaseFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader KeywordMarkerFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader EnglishMinimalStemFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader RemoveDuplicatesTokenFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader StandardTokenizerFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader SynonymFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader StopFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader LowerCaseFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader StandardTokenizerFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader StopFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader LowerCaseFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader ReversedWildcardFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader KeywordTokenizerFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader LowerCaseFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader TrimFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader PatternReplaceFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader StandardTokenizerFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader DoubleMetaphoneFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader WhitespaceTokenizerFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader DelimitedPayloadTokenFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader KeywordTokenizerFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader LowerCaseFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader PathHierarchyTokenizerFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader WhitespaceTokenizerFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader StopFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:35 WARNING FieldTypePluginLoader LowerCaseFilterFactory is using deprecated LUCENE_34 emulation. You should at some point declare and reindex to at least 4.0, because 3.x emulation is deprecated and will be removed in 5.0
16:11:36 WARNING UpdateRequestHandler Using deprecated class: XmlUpdateRequestHandler -- replace with UpdateRequestHandler
16:11:36 WARNING UpdateRequestHandler Using deprecated class: BinaryUpdateRequestHandler -- replace with UpdateRequestHandler
RE: Migrate Solr 3.4 w/ solr-1255 GeoHash to Solr 4
Posted by "Parks, Harley" <Ha...@apan-info.net>.
Hi David Smiley:
We use a 3rd party software to load Solr 3.4 so the behavior needs to be transparent with the migration to 4.1, but I was expecting that I would need to rebuild the solr database.
I moved/added the old solr 3.4 core to solr 4.1, with only minor modification (commented out the old spatial type and add the new) and I was surprised I was able to query the data.
The geohash is displaying as a hash, and not coordinate, so I am checking my configuration on the geospatial class.
Harley Powers Parks, GISP
Booz | Allen | Hamilton
Geospatial Visualization Web Developer
WEB: https://www.apan.org
USPACOM J73/APAN
Pacific Warfighting Center Ford Island
p: 808.472.7752
c: 808.377.0632
apan: harley.parks@apan-info.net
nipr: harley.parks.ctr@pacom.mil
CONTRACTOR:
Booz | Allen | Hamilton
e: parks_harley@bah.com
-----Original Message-----
From: David Smiley (@MITRE.org) [mailto:DSMILEY@mitre.org]
Sent: Wednesday, March 06, 2013 9:34 PM
To: solr-user@lucene.apache.org
Subject: Re: Migrate Solr 3.4 w/ solr-1255 GeoHash to Solr 4
Hi Harley,
See: http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4
In SOLR-2155 you had to explicitly specify the prefix encoding length, whereas in Solr 4 you specify how much precision you need and it figures out what the length is that satisfies that. When you first use the field, it'll log what the derived levels figure is (if you care). The units are decimal degrees (0-180 from no distance to reverse side of the globe -- aka latitudinal degrees).
You can name the field type whatever you want, but I don't recommend "geohash" because this conflates it with an actual GeoHashField, and also it's more of an internal detail.
You said you're having trouble with the migration... but what is the trouble?
~ David
Harley wrote
> I'm having trouble migrating the geohash fields from my Solr 3.4
> schema to the Solr 4 schema.
>
> this is the 3.4 type and class:
> <fieldType name="geohash" class="solr2155.solr.schema.GeoHashField"
> length="12"/>
> is the below Solr 4 spatial type the right configuration to implement
> data being stored in fields once using the "geohash" type and class in
> the above solr 3.4 field type?
> <fieldType name="geohash"
> class="solr.SpatialRecursivePrefixTreeFieldType"
> geo="true" distErrPct="0.025" maxDistErr="0.000009" units="degrees"
> prefixTree="geohash" />
> is the units="degrees" degree decimal? example: 21.0345
>
>
>
> Harley Powers Parks, GISP
-----
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: http://lucene.472066.n3.nabble.com/Migrate-Solr-3-4-w-solr-1255-GeoHash-to-Solr-4-tp4045416p4045470.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Migrate Solr 3.4 w/ solr-1255 GeoHash to Solr 4
Posted by "David Smiley (@MITRE.org)" <DS...@mitre.org>.
Hi Harley,
See: http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4
In SOLR-2155 you had to explicitly specify the prefix encoding length,
whereas in Solr 4 you specify how much precision you need and it figures out
what the length is that satisfies that. When you first use the field, it'll
log what the derived levels figure is (if you care). The units are decimal
degrees (0-180 from no distance to reverse side of the globe -- aka
latitudinal degrees).
You can name the field type whatever you want, but I don't recommend
"geohash" because this conflates it with an actual GeoHashField, and also
it's more of an internal detail.
You said you're having trouble with the migration... but what is the
trouble?
~ David
Harley wrote
> I'm having trouble migrating the geohash fields from my Solr 3.4 schema
> to the Solr 4 schema.
>
> this is the 3.4 type and class:
> <fieldType name="geohash" class="solr2155.solr.schema.GeoHashField"
> length="12"/>
> is the below Solr 4 spatial type the right configuration to implement
> data being stored in fields once using the "geohash" type and class in
> the above solr 3.4 field type?
> <fieldType name="geohash"
> class="solr.SpatialRecursivePrefixTreeFieldType"
> geo="true" distErrPct="0.025" maxDistErr="0.000009" units="degrees"
> prefixTree="geohash" />
> is the units="degrees" degree decimal? example: 21.0345
>
>
>
> Harley Powers Parks, GISP
-----
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: http://lucene.472066.n3.nabble.com/Migrate-Solr-3-4-w-solr-1255-GeoHash-to-Solr-4-tp4045416p4045470.html
Sent from the Solr - User mailing list archive at Nabble.com.