View source for Geohash

{{Short description|Public domain geocoding invented in 2008}}
{{about|the system for encoding geographic coordinates|the game|Geohashing}}
[[File:Geohash-grid.png|thumb|320px|The 6g<ref>{{Cite web |title=6g |url=https://geohash.softeng.co/6g |website=GeoHash Explorer}}</ref> cell and its sub-grid.]]
'''Geohash''' is a [[public domain]] [[geocode#System|geocode system]] invented in 2008 by Gustavo Niemeyer<ref name="first2008">
* {{cite web |archive-url=https://web.archive.org/web/20080305223755/http://blog.labix.org/#post-85 |archive-date=Mar 5, 2008 |url=http://blog.labix.org/ |website=Labix Blog |date=2008-02-26 |first1=G. |last1=Niemeyer |title=geohash.org is public! |postscript=;}}
* {{Cite web |last=Whelan |first=Phil |date=December 15, 2011 |title=Geohash Intro |url=http://www.bigfastblog.com/geohash-intro |url-status=dead |archive-url=https://web.archive.org/web/20120112004608/http://www.bigfastblog.com/geohash-intro |archive-date=Jan 12, 2012 |website=Big Fast Blog |postscript=;}}
* {{Cite web |last=niemeyer |date=February 26, 2008 |title=geohash.org |url=https://forums.geocaching.com/GC/index.php?/topic/186412-geohashorg/ |url-status=dead |archive-url=https://web.archive.org/web/20180309054335/https://forums.geocaching.com/GC/index.php?%2Ftopic%2F186412-geohashorg%2F |archive-date=Mar 9, 2018 |website=Geocaching Forums}}</ref> which encodes a geographic location into a short string of letters and digits. Similar ideas were introduced by G.M. Morton in 1966.<ref name="morton66">{{cite web |url-status=unfit |first1=G. M. |last1=Morton |date=1966 |url=https://domino.research.ibm.com/library/cyberdig.nsf/papers/0DABF9473B9C86D48525779800566A39/$File/Morton1966.pdf |title=A Computer Oriented Geodetic Data Base and a New Technique in File Sequencing |archive-url=https://web.archive.org/web/20190125020453/https://domino.research.ibm.com/library/cyberdig.nsf/papers/0DABF9473B9C86D48525779800566A39/$File/Morton1966.pdf |archive-date=2019-01-25 |publisher= IBM Canada |website=IBM Research }}</ref> It is a hierarchical spatial data structure which subdivides space into buckets of [[Grid (spatial index)|grid]] shape, which is one of the many applications of what is known as a [[Z-order curve]], and generally [[space-filling curves]].

Geohashes offer properties like arbitrary precision and the possibility of gradually removing characters from the end of the code to reduce its size (and gradually lose precision). Geohashing guarantees that the longer a shared prefix between two geohashes is, the spatially closer they are together. The reverse of this is not guaranteed, as two points can be very close but have a short or no shared prefix.

== History ==

The core part of the Geohash algorithm and the first initiative to similar solution was documented in a report of G.M. Morton in 1966, "A Computer Oriented Geodetic Data Base and a New Technique in File Sequencing".<ref name="morton66"/> The Morton work was used for efficient implementations of [[Z-order curve]], like in [https://github.com/yinqiwen/geohash-int this modern (2014) Geohash-integer version] (based on directly interleaving [[64-bit computing|64-bit integers]]), but his [[geocode]] proposal was not [[human-readable]] and was not popular.

Apparently, in the late 2000s, G. Niemeyer still didn't know about Morton's work, and reinvented it, adding the use of [[base32]] representation.  In February 2008, together with the announcement of the system,<ref name="first2008"/> he launched the website <code>http://geohash.org</code>, which allows users to convert geographic coordinates to short [[Uniform Resource Locator|URL]]s which uniquely identify positions on the [[Earth]], so that referencing them in [[email]]s, [[Internet forum|forums]], and [[website]]s is more convenient.

Many variations have been developed, including [[OpenStreetMap]]'s  ''short link''<ref name="osm_short_link">
The [[OpenStreetMap]]'s ''short link'', [https://wiki.openstreetmap.org/wiki/Shortlink documented in wiki.openstreetmap.org], was released   [https://github.com/openstreetmap/openstreetmap-website/blob/1d8e66016c4cdf465d06198cfbbfe76613ed3bfc/lib/short_link.rb in 2009], is near the same source-code  [https://github.com/openstreetmap/openstreetmap-website/blob/master/lib/short_link.rb 10 years after]. It is strongly based on [[Z-order curve|Morton's interlace algorithm]].
</ref> (using [[base64]] instead of base32) in 2009,  the ''64-bit Geohash''<ref>
The "Geohash binary 64 bits" have  classic solutions, as [https://github.com/yinqiwen/geohash-int yinqiwen/geohash-int], and optimized solutions, as [https://mmcloughlin.com/posts/geohash-assembly mmcloughlin/geohash-assembly].
</ref> in 2014, the exotic ''Hilbert-Geohash''<ref>{{cite thesis |last1=Vukovic |first1=Tibor |title=Hilbert-Geohash - Hashing Geographical Point Data Using the Hilbert Space-Filling Curve |journal=70 |date=2016 |hdl=11250/2404058 |hdl-access=free }}</ref> in 2016, and others.

== Typical and main usages ==
To obtain the Geohash, the user provides an address to be [[geocode]]d, or [[latitude and longitude]] coordinates, in a single input box (most commonly used formats for latitude and longitude pairs are accepted), and performs the request.

Besides showing the latitude and longitude corresponding to the given Geohash, users who navigate to a Geohash at geohash.org are also presented with an embedded map, and may download a [[GPX (data transfer)|GPX]] file, or transfer the waypoint directly to certain [[GPS]] receivers.  Links are also provided to external sites that may provide further details around the specified
location.

For example, the coordinate pair <code>57.64911,10.40744</code> (near the tip of the [[peninsula]] of [[Jutland, Denmark]]) produces a slightly shorter hash of <code>u4pruydqqvj</code>.

The main usages of Geohashes are:

* As a unique identifier.
* To represent point data, e.g. in databases.

Geohashes have also been proposed to be used for [[geotagging]].

When used in a database, the structure of geohashed data has two advantages. First, data indexed by geohash will have all points for a given rectangular area in contiguous slices (the number of slices depends on the precision required and the presence of geohash "fault lines"). This is especially useful in database systems where queries on a single index are much easier or faster than multiple-index queries. Second, this index structure can be used for a quick-and-dirty proximity search: the closest points are often among the closest geohashes.

== Technical description ==
A formal description for Computational and Mathematical views.

=== Textual representation ===
For exact latitude and longitude translations Geohash is a ''spatial index'' of [[base 4]], because it transforms the continuous latitude and longitude space coordinates into a hierarchical discrete grid, using  a recurrent four-partition of the space. To be a compact code it uses [[base 32]] and represents its values by the following alphabet, that is the "standard textual representation".

{| class="wikitable" style="text-align:center"
|-
! Decimal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Base 32
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 ||  b ||  c ||  d ||  e ||  f ||  g
|-
| style="font: 0.5em/0.5em serif;" colspan="20" | &nbsp;
|-
! Decimal
| 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23 || 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|-
! Base 32
|  h ||  j ||  k ||  m ||  n ||  p ||  q ||  r ||  s ||  t ||  u ||  v ||  w ||  x ||  y ||  z
|}

The "Geohash alphabet" (32ghs) uses all digits 0-9 and all lower case letters except "a", "i", "l" and "o".

For example,  using the table above and the constant <math>B=32</math>, the Geohash <code>ezs42</code> can be converted to a decimal representation by ordinary [[Positional notation#Base of the numeral system|positional notation]]:

: [<code>ezs42</code>]<sub>32ghs</sub> = <math>[(e \times B^4) + (z \times B^3) + (s \times B^2) + (4 \times B^1) + (2 \times B^0)]_{32ghs}</math>

: = <math>[e]_{32ghs} \times B^4 + [z]_{32ghs} \times B^3 + [s]_{32ghs} \times B^2 + [4]_{32ghs} \times B^1 + [2]_{32ghs} \times B^0</math>

: = <math>[13]_{10} \times B^4 + [31]_{10} \times B^3 + [24]_{10} \times B^2 + [4]_{10} \times B^1 + [2]_{10} \times B^0</math>

: = <math>13  \times 1048576 + 31 \times 32768 + 24 \times 1024 + 4 \times 32 + 2 \times 1</math> = <math>13631488 + 1015808 + 24576 + 128 + 2 = 14672002</math>

=== Geometrical representation ===
The geometry of the Geohash has a mixed spatial representation:

* Geohashes with 2, 4, 6, ... ''e'' digits ([[Parity (mathematics)|even]] digits) are represented by [[Z-order curve]] in a "regular grid" where decoded pair (latitude, longitude) has uniform uncertainty, valid as [[Geo URI scheme#Uncertainty|Geo URI]].
* Geohashes with 1, 3, 5, ... ''d'' digits (odd digits) are represented by  "И-order curve". Latitude and longitude of the decoded pair has different uncertainty (longitude is truncated).

[[File:Geohash-OddEvenDigits.png|680px|center]]

[[File:MortonCurve64grid-mergingCells.png|thumb|320px|The curve of the grid of 32 cells was obtained merging 2 by 2 cells of the "next level" (64 cells grid illustrated here) to obtain a geometrical representation of the "odd-digit Geohash".]]

It is possible to build the "И-order curve" from the Z-order curve by merging neighboring cells and indexing the resulting rectangular grid by the function <math>j = \left\lfloor\frac{i}{2}\right\rfloor</math>. The illustration shows how to obtain the grid of 32 rectangular cells from the grid of 64 square cells.

The most important property of Geohash for humans is that it '''preserves ''spatial hierarchy'' in the ''code prefixes'''''. <br/>For example, in the "1 Geohash digit grid" illustration  of 32 rectangles, above, the spatial region of the code <code>e</code> (rectangle of greyish blue circle at position 4,3) is preserved with prefix <code>e</code> in the "2 digit grid" of 1024 rectangles (scale showing <code>em</code> and greyish green to blue circles at grid).

=== Algorithm and example ===

Using the hash <code>ezs42</code> as an example, here is how it is decoded into a decimal latitude and longitude. The first step is decoding it from textual "[[#Textual representation|base 32]]ghs", as showed above, to obtain the binary representation:

: <math>[e]_{32ghs}=[13]_{10}=[01101]_2</math>
: <math>[z]_{32ghs}=[31]_{10}=[11111]_2</math>
: <math>[s]_{32ghs}=[24]_{10}=[11000]_2</math>
: <math>[4]_{32ghs}=[4]_{10}=[00100]_2</math>
: <math>[2]_{32ghs}=[2]_{10}=[00010]_2</math>.

This operation results in the [[bit]]s <code>01101</code> <code>11111</code> <code>11000</code> <code>00100</code> <code>00010</code>. Starting to count from the left side with the digit 0 in the first position, the digits in the even positions form the longitude code (<code>0111110000000</code>), while the digits in the odd positions form the latitude code (<code>101111001001</code>).

Each binary code is then used in a series of divisions, considering one bit at a time, again from the left to the right side.  For the latitude value, the interval −90 to +90 is divided by 2, producing two intervals: −90 to 0, and 0 to +90.  Since the first bit is 1, the higher interval is chosen, and becomes the current interval. The procedure is repeated for all bits in the code.  Finally, the latitude value is the center of the resulting interval.  Longitudes are processed in an equivalent way, keeping in mind that the initial interval is −180 to +180.

For example, in the latitude code <code>101111001001</code>, the first bit is 1, so we know our latitude is somewhere between 0 and 90. Without any more bits, we'd guess the latitude was 45, giving us an error of ±45. Since more bits are available, we can continue with the next bit, and each subsequent bit halves this error. This table shows the effect of each bit. At each stage, the relevant half of the range is highlighted in green; a low bit selects the lower range, a high bit selects the upper range.

The column "mean value" shows the latitude, simply the mean value of the range. Each subsequent bit makes this value more precise.

{| class="wikitable" style="text-align:right"
! colspan="7" |Latitude code 101111001001
|- style="text-align:center"
! bit position
! bit value
! min
! mid
! max
! mean value
! maximum error
|-
| 0 || 1 || −90.000 || style="background:#cceecc" |0.000 || style="background:#cceecc" |90.000 || 45.000 || 45.000
|-
| 1 || 0 || style="background:#cceecc" |0.000 || style="background:#cceecc" |45.000 || 90.000 || 22.500 || 22.500
|-
| 2 || 1 || 0.000 || style="background:#cceecc" |22.500 || style="background:#cceecc" |45.000 || 33.750 || 11.250
|-
| 3 || 1 || 22.500 || style="background:#cceecc" |33.750 || style="background:#cceecc" |45.000 || 39.375 || 5.625
|-
| 4 || 1 || 33.750 || style="background:#cceecc" |39.375 || style="background:#cceecc" |45.000 || 42.188 || 2.813
|-
| 5 || 1 || 39.375 || style="background:#cceecc" |42.188 || style="background:#cceecc" |45.000 || 43.594 || 1.406
|-
| 6 || 0 || style="background:#cceecc" |42.188 || style="background:#cceecc" |43.594 || 45.000 || 42.891 || 0.703
|-
| 7 || 0 || style="background:#cceecc" |42.188 || style="background:#cceecc" |42.891 || 43.594 || 42.539 || 0.352
|-
| 8 || 1 || 42.188 || style="background:#cceecc" |42.539 || style="background:#cceecc" |42.891 || 42.715 || 0.176
|-
| 9 || 0 || style="background:#cceecc" |42.539 || style="background:#cceecc" |42.715 || 42.891 || 42.627 || 0.088
|-
| 10 || 0 || style="background:#cceecc" |42.539 || style="background:#cceecc" |42.627 || 42.715 || 42.583 || 0.044
|-
| 11 || 1 || 42.539 || style="background:#cceecc" |42.583 || style="background:#cceecc" |42.627 || 42.605 || 0.022
|}

{| class="wikitable" style="text-align:right"
! colspan="7" |Longitude code 0111110000000
|- style="text-align:center"
! bit position
! bit value
! min
! mid
! max
! mean value
! maximum error
|-
| 0 || 0 || style="background:#cceecc"| −180.000 || style="background:#cceecc" |0.000 || 180.000 || −90.000 || 90.000
|-
| 1 || 1 || −180.000 || style="background:#cceecc" |−90.000 || style="background:#cceecc" |0.000 || −45.000 || 45.000
|-
| 2 || 1 || −90.000 || style="background:#cceecc" |−45.000 || style="background:#cceecc" |0.000 || −22.500 || 22.500
|-
| 3 || 1 || −45.000 || style="background:#cceecc" |−22.500 || style="background:#cceecc" |0.000 || −11.250 || 11.250
|-
| 4 || 1 || −22.500 || style="background:#cceecc" |−11.250 || style="background:#cceecc" |0.000 || −5.625 || 5.625
|-
| 5 || 1 || −11.250 || style="background:#cceecc" |−5.625 || style="background:#cceecc" |0.000 || −2.813 || 2.813
|-
| 6 || 0 || style="background:#cceecc" | −5.625 || style="background:#cceecc" | −2.813 || 0.000 || −4.219
| 1.406
|-
| 7 || 0 || style="background:#cceecc" | −5.625 || style="background:#cceecc" |−4.219
| −2.813 ||−4.922
| 0.703
|-
| 8 || 0 || style="background:#cceecc" | −5.625 || style="background:#cceecc" |−4.922
|<nowiki>−4.219</nowiki>
|<nowiki>−5.273</nowiki>
| 0.352
|-
| 9 || 0 || style="background:#cceecc" | −5.625 || style="background:#cceecc" |−5.273
|<nowiki>−4.922</nowiki>
|<nowiki>−5.449</nowiki>
| 0.176
|-
| 10 || 0 || style="background:#cceecc" | −5.625 || style="background:#cceecc" |−5.449
|<nowiki>−5.273</nowiki>
|<nowiki>−5.537</nowiki>
| 0.088
|-
| 11 || 0 || style="background:#cceecc" | −5.625 || style="background:#cceecc" |−5.537
|<nowiki>−5.449</nowiki>
|<nowiki>−5.581</nowiki>
|0.044
|-
|12 || 0 || style="background:#cceecc" | −5.625 || style="background:#cceecc" |−5.581
|<nowiki>−5.537</nowiki>
| −5.603
|0.022
|}

(The numbers in the above table have been rounded to 3 decimal places for clarity)

Final rounding should be done carefully in a way that

:<math> \min \le \mathrm{round}(value) \le \max </math>

So while rounding 42.605 to 42.61 or 42.6 is correct, rounding to 43 is not.

=== Digits and precision in km ===

{| class="wikitable"
|-
! geohash length
! lat bits
! lng bits
! lat error
! lng error
! km error
|-
| 1 || 2 || 3 || ±23 || ±23 || {{figure space}}±{{cvt|2500|km}}
|-
| 2 || 5 || 5 || {{figure space}}±2.8 || {{figure space}}±5.6 || {{figure space}}±{{cvt|630|km}}
|-
| 3 || 7 || 8 || {{figure space}}±0.70 || {{figure space}}±0.70 || {{figure space}}{{figure space}}±{{cvt|78|km}}
|-
| 4 || 10 || 10 || {{figure space}}±0.087 || {{figure space}}±0.18 || {{figure space}}{{figure space}}±{{cvt|20|km}}
|-
| 5 || 12 || 13 || {{figure space}}±0.022 || {{figure space}}±0.022 || {{figure space}}{{figure space}}{{figure space}}±{{cvt|2.4|km|mi m}}
|-
| 6 || 15 || 15 || {{figure space}}±0.0027 || {{figure space}}±0.0055 || {{figure space}}{{figure space}}{{figure space}}±{{cvt|0.61|km|mi m}}
|-
| 7 || 17 || 18 || {{figure space}}±0.00068 || {{figure space}}±0.00068 || {{figure space}}{{figure space}}{{figure space}}±{{cvt|0.076|km|mi m}}
|-
| 8 || 20 || 20 || {{figure space}}±0.000085 || {{figure space}}±0.00017 || {{figure space}}{{figure space}}{{figure space}}±{{cvt|0.019|km|mi m}}
|}

== Limitations when used for deciding proximity ==
=== Edge cases ===
Geohashes can be used to find points in proximity to each other based on a common prefix. However, [[edge case]] locations close to each other but on opposite sides of the 180 degree meridian will result in Geohash codes with no common prefix (different longitudes for near physical locations). Points close to the North and South poles will have very different geohashes (different longitudes for near physical locations).

Two close locations on either side of the Equator (or Greenwich meridian) will not have a long common prefix since they belong to different 'halves' of the world. Put simply, one location's binary latitude (or longitude) will be 011111... and the other 100000...., so they will not have a common prefix and most bits will be flipped. This can also be seen as a consequence of relying on the [[Z-order curve]] (which could more appropriately be called an N-order visit in this case) for ordering the points, as two points close by might be visited at very different times. However, two points with a long common prefix will be close by.

In order to do a proximity search, one could compute the southwest corner (low geohash with low latitude and longitude) and northeast corner (high geohash with high latitude and longitude) of a bounding box and search for geohashes between those two. This search will retrieve all points in the z-order curve between the two corners, which can be far too many points. This method also breaks down at the 180 meridians and the poles. Solr uses a filter list of prefixes, by computing the prefixes of the nearest squares close to the geohash [https://web.archive.org/web/20140513235817/http://lucenerevolution.org/sites/default/files/Lucene%20Rev%20Preso%20Smiley%20Spatial%20Search.pdf].

=== Non-linearity ===
Since a geohash (in this implementation) is based on [[Geographical coordinate system|coordinates of longitude and latitude]] the distance between two geohashes reflects the distance in latitude/longitude coordinates between two points, which does not translate to actual distance, see [[Haversine formula]].

Example of non-linearity for latitude-longitude system:
* At the Equator (0 Degrees) the length of a degree of longitude is 111.320&nbsp;km, while a degree of latitude measures 110.574&nbsp;km, an error of 0.67%.
* At 30 Degrees (Mid Latitudes) the error is 110.852/96.486 = 14.89%
* At 60 Degrees (High Arctic) the error is 111.412/55.800 = 99.67%, reaching infinity at the poles.

Note that these limitations are not due to geohashing, and not due to latitude-longitude coordinates, but due to the difficulty of mapping coordinates on a sphere (non linear and with wrapping of values, similar to modulo arithmetic) to two dimensional coordinates and the difficulty of exploring a two dimensional space uniformly. The first is related to [[Geographical coordinate system]] and [[Map projection]], and the other to [[Hilbert curve]] and [[z-order curve]]. Once a coordinate system is found that represents points linearly in distance and wraps up at the edges, and can be explored uniformly, applying geohashing to those coordinates will not suffer from the limitations above.

While it is possible to apply geohashing to an area with a [[Cartesian coordinate system]], it would then only apply to the area where the coordinate system applies.

Despite those issues, there are possible workarounds, and the algorithm has been successfully used in Elasticsearch,<ref>[https://www.elastic.co/guide/en/elasticsearch/reference/current/geo-shape.html geo_shape Datatype in Elasticsearch]</ref> MongoDB,<ref>[http://www.mongodb.org/display/DOCS/Geospatial+Indexing Geospatial Indexing in MongoDB]</ref> HBase, Redis,<ref>[https://redis.io/commands/geohash Redis-commands Guide]</ref> and [[Accumulo]]<ref>[https://geomesa.github.io/assets/outreach/SpatioTemporalIndexing_IEEEcopyright.pdf Spatio-temporal Indexing in Non-relational Distributed Databases]</ref> to implement proximity searches.

== Similar indexing systems ==
{{main|Geocodes}}

[[File:Comparing-Geoash-Hilbert.png|thumb|520px|It is possible to use same base32-Geohash codes in different indexing curves. For [[Euclidean tilings by convex regular polygons#Regular tilings|quadrilateral tiling]] the [[Hilbert curve]] is the best alternative for [[Z-order curve|Morton curve]], used for example in the S2-geometry. <br/>Codes with even number of digits (2, 4, ...) are mapped to regular grids, but codes of odd number (1, 3, ...) must be mapped to an irregular intermediary grid, with cells [https://mathoverflow.net/q/357117/153024 indexed by degenerated curves].]]

An alternative to storing Geohashes as strings in a database are [http://www.cs.umd.edu/~hjs/pubs/SametVisualComputer89.pdf Locational codes], which are also called spatial keys and similar to QuadTiles.<ref>[http://karussell.wordpress.com/2012/05/23/spatial-keys-memory-efficient-geohashes/ Spatial Keys]</ref><ref>[https://wiki.openstreetmap.org/wiki/QuadTiles QuadTiles]</ref>

In some  [[geographical information systems]] and [[Big Data]] spatial databases, a [[Hilbert curve]] based indexation can be used as an alternative to [[Z-order curve]], like in the ''S2 Geometry library''.<ref>"S2 Geometry Library" for optimized spatial indexation, https://s2geometry.io {{Webarchive|url=https://web.archive.org/web/20231211175507/https://s2geometry.io/ |date=2023-12-11 }}</ref>

In 2019 a front-end was designed by [[QA Locate]]<ref>{{Cite web|last=|first=|date=|title=QA Locate {{!}} The Power of Precision Location Intelligence|url=https://www.qalocate.com/|archive-url=|archive-date=|access-date=2020-06-10|website=QA Locate|language=en-US}}</ref> in what they called GeohashPhrase<ref>{{Cite web|date=2019-09-17|title=GeohashPhrase|url=https://www.qalocate.com/solutions/geohashphrase/|access-date=2020-06-10|website=QA Locate|language=en-US}}</ref> to use phrases to code Geohashes for easier communication via spoken English language. There were plans to make GeohashPhrase open source.<ref>{{Cite web|last=thelittlenag|date=2019-11-11|title=At QA Locate we've been working on a solution that we call GeohashPhrase {{!}} Hacker News|url=https://news.ycombinator.com/item?id=21219374|archive-url=|archive-date=|access-date=2020-06-10|website=news.ycombinator.com}}</ref>
{{div col}}
* [[C-squares]] (2002)
* FixPhrase
* [[GeoKey]] (2018, proprietary)
* [[Ghana Post GPS]] (2017)
* International Postcode system using Cubic Meters (CubicPostcode.com)
* [[Maidenhead Locator System]] (1980)
* [[Makaney Code]] (2011)
* [[MapCode]] (2008)
* [[Military Grid Reference System]]
* [[Natural Area Code]]
* [[Open Location Code]] (2014, aka. "plus codes", [[Google Maps]])
* [[QRA locator]] (1959)
* [[Universal Transverse Mercator coordinate system]]
* verbal-id
* [[what3words]] (2013, proprietary)
* [[WhatFreeWords]]
* wherewords.id
* wolo.codes
* [[World Geographic Reference System|GEOREF]] (similar 2-digit hierarchy code)
* [[Xaddress]]
* [[3Geonames]] (2018, open source)
{{div col end}}

== Licensing ==

The Geohash algorithm was put in the [[public domain]] by its inventor in a public announcement on February 26, 2008.<ref>[http://forums.groundspeak.com/GC/index.php?showtopic=186412 geohash.org announcement post in groundspeak.com forum. See also Wayback of 2018 at https://web.archive.org/web/20180309054335/https://forums.geocaching.com/GC/index.php?/topic/186412-geohashorg/ web.archive.org/web/20180309054335]</ref>

While comparable algorithms have been successfully patented<ref>[http://www.freepatentsonline.com/20050023524.html Compact text encoding of latitude/longitude coordinates - Patent 20050023524]</ref> and
had copyright claimed upon,<ref>[http://www.gps-practice-and-fun.com/nacgeo.html#Microsoft Does Microsoft Infringe the Natural Area Coding System?] {{webarchive|url=https://web.archive.org/web/20101228091709/http://www.gps-practice-and-fun.com/nacgeo.html |date=2010-12-28 }}</ref><ref>{{Cite web |url=http://www.nacgeo.com/nacsite/licensing/ |title=The Natural Area Coding System - Legal and Licensing |access-date=2008-02-26 |archive-date=2019-05-23 |archive-url=https://web.archive.org/web/20190523074747/http://www.nacgeo.com/nacsite/licensing/ |url-status=dead }}</ref> GeoHash is based on an entirely different algorithm and approach.

== Formal Standard ==
Geohash is standardized as CTA-5009.<ref>{{Cite web |title=Fast and Readable Geographical Hashing (CTA-5009) |url=https://shop.cta.tech/products/fast-and-readable-geographical-hashing-cta-5009 |access-date=2024-03-04 |website=Consumer Technology Association® |language=en}}</ref>  This standard follows the Wikipedia article as of the 2023 version but provides additional detail in a formal (normative) reference. In the absence of an official specification since the creation of Geohash, the CTA WAVE organization published CTA-5009 to aid in broader adoption and compatibility across implementers in the industry.

== See also ==
* [[List of geodesic-geocoding systems]]
* [[Geohash-36]] (is not a Geohash-variant)
* [[Grid (spatial index)]]
* [[Maidenhead Locator System]]
* [[Military Grid Reference System]]
* [[Morton number (number theory)]]
* [[Natural Area Code]]
* [[Numbering scheme]]
* [[Open Location Code]] (plus code)
* [[space-filling curves]]
* [[what3words]]
* [[Z-order curve]]

== References ==

{{reflist|30em}}

== External links ==

* {{official website|http://geohash.org/}}
* [https://github.com/adrianulbona/jts-discretizer Geohash approximations for JTS geometries]
* [https://geohash.measurement.earth/ The Geohash Playground]

{{geocoding-systems}}

[[Category:Geographic coordinate systems]]
[[Category:Geocodes]]
[[Category:2008 introductions]]