Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of michael_segel@hotmail.com
 designates 65.55.111.112 as permitted sender)
Message-ID: <BLU0-SMTP45193B7AF30EFE771DC31CC8F180@phx.gbl>
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Spatial data posting in HBase
From: Michael Segel <michael_segel@hotmail.com>
In-Reply-To: 
 <CADt=Q7nPN2eDB9Yt4v05+NiMGQ-pM0oOeqJs=_vhqgjM7AO6+g@mail.gmail.com>
Date: Sat, 12 Oct 2013 13:33:03 -0500
Content-Transfer-Encoding: quoted-printable
References: <1380021342486-4051123.post@n3.nabble.com>
 <CANNBgPLHobsthUvxPgeoLiD+GwMTwi21tchf_Som7CBs9ng0gg@mail.gmail.com>
 <BLU0-SMTP4441D74C5F9A6B874DB6791981D0@phx.gbl>
 <CANNBgPJ3nwnUoeMMDD2b6bnqOMAh7fnKE57Njdda5drtuPCKVw@mail.gmail.com>
 <BLU0-SMTP2003EC00303D0B652741DB5981E0@phx.gbl>
 <CADt=Q7nPN2eDB9Yt4v05+NiMGQ-pM0oOeqJs=_vhqgjM7AO6+g@mail.gmail.com>
To: user@hbase.apache.org

Adrien,=20

In terms of efficiency...=20

A general solution that can be applied to all problems in all areas is =
going to be best.=20
Geohash gets ugly when you're around the equator.  You can have two =
points literally a couple of km away that would have two very different =
geo hashes.=20

So if you tile the globe, depending on the size of the tile, you =
calculate the tile, its surrounding tiles (if necessary) and then sweep =
through the data to find your object.=20

I'm not suggesting you not to use geohash, just that its not going to be =
the most efficient.=20

Note that the the downside to tiling is that if you're doing a =
geospatial index... your data volume explodes because you are storing =
references to the data at different tile levels.

Its a trade off.=20


On Oct 12, 2013, at 2:34 AM, Adrien Mogenet <adrien.mogenet@gmail.com> =
wrote:

> Michael, don't you think Geohashes can be satisfying and well-suited =
for
> many cases anyway? Searching in a bounding box or arbitrary polygon is =
not
> that heavy with Geohash, even on edge conditions. The biggest risk =
IMHO is
> to have to deal with tons of invalid extra points if the geohash query =
is
> not accurate enough and your points distribution is very sparse so =
that
> many points will be found in a geohash despite they don't respond to =
your
> query criteria.
>=20
> However, if your query embeds enough bits of precision, Geohashes =
offer
> some nice guarantees for distributed databases and your queries should
> remain efficient enough.
>=20
> Another worst case of course is to look for K-NN since Geohash is not =
a
> real longest-common-prefix algorithm but once again, if your points
> distribution is approximately well balanced, this works not that bad
> without doing lots of recursive queries or fetching tons of useless =
data
> (but I do agree looking into your tiles would probably be more =
appropriate
> in that case).
>=20
> I'm planning to write an article on that points, so further technical
> arguments are welcome :-}
>=20
> On Thu, Oct 10, 2013 at 7:51 PM, Michael Segel =
<msegel_hadoop@hotmail.com>wrote:
>=20
>> HBase in Action goes through great depth of showing you how you could
>> implement GIS information in HBase.
>>=20
>> Unfortunately there are issues with Geohash and edge conditions which =
make
>> it difficult to use when you're dealing with data on an edge of a =
quadrant.
>>=20
>> A better way would be to create a point (geospatial point object) and
>> store it in a single column.
>> (This goes beyond the example of what's in the book. ) And then index =
the
>> data by tiles.
>>=20
>>=20
>> The downside is that you end up creating a lot more data=85
>>=20
>> Take a look at some of the stuff Boris Lublinsky published on InfoQ. =
There
>> are also other articles on the net=85.
>>=20
>> On Oct 9, 2013, at 1:35 PM, Otis Gospodnetic =
<otis.gospodnetic@gmail.com>
>> wrote:
>>=20
>>> The point is that there are options (multiple different hammers) if
>>> HBase support for geospatial is not there or doesn't meet OP's =
needs.
>>>=20
>>> Otis
>>> --
>>> Solr & ElasticSearch Support -- http://sematext.com/
>>> Performance Monitoring -- http://sematext.com/spm
>>>=20
>>>=20
>>>=20
>>> On Wed, Oct 9, 2013 at 11:14 AM, Michael Segel
>>> <msegel_hadoop@hotmail.com> wrote:
>>>> And Solr has what to do with storing data in HBase?
>>>>=20
>>>> I guess its true=85 if all you have is a hammer=85
>>>>=20
>>>> The point I was raising was that geohash isn't the most efficient =
way
>> to go when you look at the problem at a global level=85
>>>>=20
>>>> On Oct 9, 2013, at 9:34 AM, Otis Gospodnetic <
>> otis.gospodnetic@gmail.com> wrote:
>>>>=20
>>>>> Consider using Solr, which provides a lot of geospatial search =
support.
>>>>>=20
>>>>> Otis
>>>>> Solr & ElasticSearch Support
>>>>> http://sematext.com/
>>>>> On Sep 24, 2013 8:29 AM, "cto" <ankur5.c@tcs.com> wrote:
>>>>>=20
>>>>>> Hi ,
>>>>>>=20
>>>>>> I am very new in HBase. Could you please let me know , how to =
insert
>>>>>> spatial
>>>>>> data (Latitude / Longitude) in HBase using Java .
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> View this message in context:
>>>>>>=20
>> =
http://apache-hbase.679495.n3.nabble.com/Spatial-data-posting-in-HBase-tp4=
051123.html
>>>>>> Sent from the HBase User mailing list archive at Nabble.com.
>>>>>>=20
>>>>=20
>>>=20
>>=20
>>=20
>=20
>=20
> --=20
> Adrien Mogenet
> http://www.borntosegfault.com

The opinions expressed here are mine, while they may reflect a cognitive =
thought, that is purely accidental.=20
Use at your own risk.=20
Michael Segel
michael_segel (AT) hotmail.com