WARNING: The 2.x versions of Elasticsearch have passed their EOL dates. If you are running a 2.x version, we strongly advise you to upgrade.
This documentation is no longer maintained and may be removed. For the latest information, see the current Elasticsearch documentation.
Geohashesedit
Geohashes are a way of encoding
lat/lon
points as strings. The original intention was to have a
URL-friendly way of specifying geolocations, but geohashes have turned out to
be a useful way of indexing geo-points and geo-shapes in databases.
Geohashes divide the world into a grid of 32 cells—4 rows and 8 columns—each represented by a letter or number. The g
cell covers half of
Greenland, all of Iceland, and most of Great Britain. Each cell can be further
divided into another 32 cells, which can be divided into another 32 cells,
and so on. The gc
cell covers Ireland and England, gcp
covers most of
London and part of Southern England, and gcpuuz94k
is the entrance to
Buckingham Palace, accurate to about 5 meters.
In other words, the longer the geohash string, the more accurate it is. If
two geohashes share a prefix— and gcpuuz
—then it implies that
they are near each other. The longer the shared prefix, the closer they
are.
That said, two locations that are right next to each other may have completely
different geohashes. For instance, the
Millenium Dome in London has
geohash u10hbp
, because it falls into the u
cell, the next top-level cell
to the east of the g
cell.
Geo-points can index their associated geohashes automatically, but more
important, they can also index all geohash prefixes. Indexing the location
of the entrance to Buckingham Palace—latitude 51.501568
and longitude
-0.141257
—would index all of the geohashes listed in the following table,
along with the approximate dimensions of each geohash cell:
Geohash | Level | Dimensions |
---|---|---|
|
|
~ 5,004km x 5,004km |
|
|
~ 1,251km x 625km |
|
|
~ 156km x 156km |
|
|
~ 39km x 19.5km |
|
|
~ 4.9km x 4.9km |
|
|
~ 1.2km x 0.61km |
|
|
~ 152.8m x 152.8m |
|
|
~ 38.2m x 19.1m |
|
|
~ 4.78m x 4.78m |
|
|
~ 1.19m x 0.60m |
|
|
~ 14.9cm x 14.9cm |
|
|
~ 3.7cm x 1.8cm |
The geohash_cell
filter can use
these geohash prefixes to find locations near a specified lat/lon
point.
- Elasticsearch - The Definitive Guide:
- Foreword
- Preface
- Getting Started
- You Know, for Search…
- Installing and Running Elasticsearch
- Talking to Elasticsearch
- Document Oriented
- Finding Your Feet
- Indexing Employee Documents
- Retrieving a Document
- Search Lite
- Search with Query DSL
- More-Complicated Searches
- Full-Text Search
- Phrase Search
- Highlighting Our Searches
- Analytics
- Tutorial Conclusion
- Distributed Nature
- Next Steps
- Life Inside a Cluster
- Data In, Data Out
- What Is a Document?
- Document Metadata
- Indexing a Document
- Retrieving a Document
- Checking Whether a Document Exists
- Updating a Whole Document
- Creating a New Document
- Deleting a Document
- Dealing with Conflicts
- Optimistic Concurrency Control
- Partial Updates to Documents
- Retrieving Multiple Documents
- Cheaper in Bulk
- Distributed Document Store
- Searching—The Basic Tools
- Mapping and Analysis
- Full-Body Search
- Sorting and Relevance
- Distributed Search Execution
- Index Management
- Inside a Shard
- You Know, for Search…
- Search in Depth
- Structured Search
- Full-Text Search
- Multifield Search
- Proximity Matching
- Partial Matching
- Controlling Relevance
- Theory Behind Relevance Scoring
- Lucene’s Practical Scoring Function
- Query-Time Boosting
- Manipulating Relevance with Query Structure
- Not Quite Not
- Ignoring TF/IDF
- function_score Query
- Boosting by Popularity
- Boosting Filtered Subsets
- Random Scoring
- The Closer, The Better
- Understanding the price Clause
- Scoring with Scripts
- Pluggable Similarity Algorithms
- Changing Similarities
- Relevance Tuning Is the Last 10%
- Dealing with Human Language
- Aggregations
- Geolocation
- Modeling Your Data
- Administration, Monitoring, and Deployment