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


Reply via email to