Like Tim, just thinking out loud - could you reverse the geohash and
store that? I guess it depends how you're using the hashes, if it's
just a key to lookup that shouldn't cause you too much trouble. If
you're trying to scan based on hashes it probably won't work well at
all.
Andrew
On 12 Apr 2010, at 23:18, Wade Arnold wrote:
We have been working on using Hbase for some geospatial queries for
agronomic data. Via mapreduce we have created a secondary index to
point at
the raw records. Our issue is that the density of geohash/UTM/Zip/
(lat,long)
data sets is that they are naturally dense. For our use case the
Midwest is
very dense and New York and San Francisco don’t exist. I am sure for
4sqr
and localized advertising engines this is the opposite. Do to the
density of
they key we keep on having region server density issues. I was
wondering if
anyone on the list has added any additional dimension on top of a
geohash in
order to create better partitioning?
Wade Arnold