[postgis-devel] geohash is a strange beast
nicklas.aven at jordogskog.no
Wed Feb 24 13:07:26 PST 2016
Sorry for the noise.
I realize everything of course is as it should.
Geohash only have 5 bit steps.
One box can only be divided in 32 smaller boxes, not just 2 as I
I found my brain at home.
On Wed, 2016-02-24 at 14:54 +0100, Nicklas Avén wrote:
> First I thought that this was a bug in PostGIS.
> But now I am not sure. It is likely just a smelling brain fart.
> First what made me start thinking:
> The query:
> SELECT ST_Box2dFromGeoHash('0');
> I expect to get the western half of the world back like :
> "BOX(-180 -90,0 90)"
> from my understanding after reading for instance this post:
> But it doesn't. It returns:
> "BOX(-180 -90,-135 -45)"
> The reason is that geohash is coded with base32
> So the function have no way to understand if we on bit level mean 0 or
> 00 or 000 or 0000 or 00000
> The way the function is written it iterates all 5 bit-positions and if
> there is a 0 it divides the eastern and southern part.
> lon goes through those divisions
> starts with -180 to 180
> -180 to 0
> -180 to -90
> -180 to -135
> and lat through
> -90 to 90
> -90 to 0
> -90 to -45
> 3 rounds for lon and 2 for lat.
> That is what the 5 bits in the base32 representation of 0 does.
> Worst is that I guess this happens on all geohashes that ends with 0.
> How to know how many bits to use?
> And in the PostGIS case I have a question about if we are doing this
> We are assuming the maximum precision from the inputed 0
> Is it not more right to assume the worst precision?
> I hope I am totally wrong in all this or geohash is far from that usable
> that I thought.
> Did I forget my brain at home today?
> Best Regards
> Nicklas Avén
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
More information about the postgis-devel