Talk:Geohash

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

XKCD cartoon[edit]

Should this article mention the XKCD Geohashing algorithm? Probably not notable. yet...  ;-) --W0lfie (talk) 03:43, 25 May 2008 (UTC)[reply]

Waiting for WP:N and WP:V, or it would have been in here days ago. -- SEWilco (talk) 05:53, 25 May 2008 (UTC)[reply]
I've seen newspaper articles about it, but probably can't turn up a reference on the spot. 72.53.92.48 (talk) 23:03, 24 May 2009 (UTC)[reply]
Their number is still quite limited.
* http://technology.slashgeo.org/technology/08/06/16/1324229.shtml
* http://www.polylog.tv/videothek/videocast/15824/ (German TV)
* http://www.drs.ch/www/de/drs/sendungen/drs-3-digital/100273.luzi-guido-und-reto-auf-digitaler-schnitzeljagd.html (Swiss radio)
-- Ravn (talk) 13:21, 19 October 2009 (UTC)[reply]
I think that as long as geohashing-the-sport it is noted somewhere on Wikipedia, it is useful to link to for disambiguation. -- Phyzome is Tim McCormack 23:00, 9 November 2009 (UTC)[reply]

Proximity search[edit]

Storing 2-3 geohash-like data for each point, with the origin point offset by 120 degrees longitude and 60 degrees latitude (1/3 in binary is 0.010101...) makes geohashes more effective for proximity search. I've tested it with 1000 random points:

Cumulative with 1 index(es): 

[565, 714, 780, 833, 870, 894, 915, 920, 927, 935]

Cumulative with 2 index(es): 

[  0, 800, 800, 922, 922, 963, 963, 979, 979, 988]

Cumulative with 3 index(es): 

[  0,   0, 889, 889, 889, 974, 974, 974, 992, 992]

(The nth element of each list is the chances that the true closest point is within the 2n closest neighbors sorted by the indexes. You can't get just 2 or 4 neighbors from 3 lists, thus the 0s in the 3-index case.) 187.143.9.207 (talk) 14:22, 30 July 2010 (UTC)[reply]

"Limitations"[edit]

The Limitations section includes two paragraphs which both deal with proximity searches. These are really the same limitation. Presenting them in this way makes it look as if the system has more drawbacks than it really has. Doug Ewell 17:34, 28 March 2012 (UTC) — Preceding unsigned comment added by DougEwell (talk • contribs)

Category:Geodesy

External links modified (January 2018)[edit]

Hello fellow Wikipedians,

I have just modified 2 external links on Geohash. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 09:24, 26 January 2018 (UTC)[reply]

Group articles of WGS84 One Code Systems[edit]

Perhps ideal is a comparison page. --Krauss (talk)

There are many systems to be compared, all are "one input code" — one unique number encoding lat and long with a non-numeric representation — using LatLong WGS84 as main convertion reference:

Advertisement?[edit]

The article reads like an advertisement! Was this all written by Gustavo Niemeyer? Nice that it seems to be an adopted technique but I would expect "geohash" to be a generic term. The approach of using Z-Order (Morton order), Hilbert curve, and other space-filling curves has been used for many decades in computer lookup and storage of location-related data. It was in fact first published by Morton, and used to build an enormous map database of Canada. There is a link to the web site at the beginning of the article, which is rare in Wikipedia articles -- usually only wikipedia links are used. Here are some references to start (breadcrumbs for me later to fix this page).

B ̈ohm C, Berchtold S, Keim DA. Searching in high-dimensional spaces Index structures for improving the performance of multimedia databases. ACM Computing Surveys 2001; 33 (3):322–373 https://doi.org/10.1145/502807.502809

A. J. Fisher. A new algorithm for generating hilbert curves, Software Practice and Experience, Jan 1986 https://doi.org/10.1002/spe.4380160103

J. G. Griffiths. An algorithm for displaying a class of space-filling curves, Software Practice and Experience, Volume 16 Issue 5, May 1986 https://doi.org/10.1002/spe.4380160503

Morton, G. A Computer Oriented Geodetic Data Base and a New Technique in File Sequencing, IBM Ltd., 1966. https://domino.research.ibm.com/library/cyberdig.nsf/papers/0DABF9473B9C86D48525779800566A39/$File/Morton1966.pdf

Dr Ian K Crain, CGIS + 50: Origins, Innovation, and Legacy http://cca-acc.org/wp-content/uploads/CCA-2017-Ian-Crain.pdf [Overview of the multi-decade project by IBM to create computer maps of Canada.]

R. F. Tomlinson, An introduction to the Geo-Information System of the Canada Land Inventory, 1967 https://gisandscience.files.wordpress.com/2012/08/3-an-introduction-to-the-geo-information-system-of-the-canada-land-inventory.pdf — Preceding unsigned comment added by Ericjster (talk • contribs) 21:07, 24 January 2019 (UTC)[reply]

Accuracy[edit]

The section on Number of geohash characters and precision in km is wrong, or I'm just not understanding what is happening. Considering that I have had to deal with presenting graphics on a globe (and the massive headaches with the anti-meridian) I'm thinking it is the former. First of all, given the same number of bits for dividing the latitude and longitude the error for the longitude will always be twice the angular measurement. This is reflected in the table.

This leads to the second problem. Given a conversion factor from latitude/longitude to kilometers, there will be only one latitude at which this conversion factor will be correct. This is because at any given latitude, the DISTANCE between two degrees of longitude will be the greatest at the equator and zero at both poles. The difference between two degrees of latitude at any given longitude will be the same along the entire line of longitude. (Except for minor variations from the geode.) Val42 (talk) 04:33, 4 September 2019 (UTC)[reply]

The accuracy table is definitely misleading or even wrong as for the "km error" column. Let's see: If we assume that the equator measures 40074 km and that a meridian measures 20004 km, then at the equator, 1/32 of the width (equator) would be 1252,31 km and 1/32 of the height (meridian) would be 625,13 km. This would be the precision of a 2-character geohash for any position on the equator then: (sqrt(1252,31^2+625,13^2))= ± 699,83 km. If we go on like this, precision for 4-characters would be ± 21,87 km, six characters ± 683,43 m and for an eight-character Geohash, I get ± 21,36 m. On the other hand, if I go from the equator to a position with 45°latitude, then the precision for an eight-character Geohash would be only ± 16,54 m. My suspicion is that the "km error" is supposed to be an average for different latitudes...149.172.254.151 (talk) 12:03, 14 October 2019 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Geohash&oldid=1207385398"