I've implemented geohashes before. The algorithm is not difficult, and pretty straight-forward to understand… and not the sort of thing I'd call out to a separate service over the network for. It's a pure computation that will take nanoseconds; is that worth involving the Internet and a third-party API?

Edit: well, some of http://geohash.world/about.html makes it sound like a pet project for learning purposes. In which case, anything goes, I guess? But I'm still not sure if it's only a pet project?

Hey, thanks for your comment! I coded the geohash implementation from scratch, and it was really easy!

The main reason I did it (other than a fun weekend project) was to make other people interested in it, and enable them to build something fun, very quickly. There wasn't a free+modern+easy-to-use-in-bulk API available, and this way me and others can spend their weekend/hackathons building something on top of geohashes instead of wrestling with the algorithm itself.

Edit : as a greek, I really dig your username :P

>It's a pure computation that will take nanoseconds; is that worth involving the Internet and a third-party API?

reminds me of http://left-pad.io/

I honestly don't understand why anyone would use Geohash? Because it's one number instead of 2?

The short definition is "A geohash is a convenient way of expressing a location (anywhere in the world) using a short alphanumeric string, with greater precision obtained with longer strings."

Here's another way to "use a short alphanumeric string" and "get greater precision with longer strings": "37,122", "37.7,122.4", "37.77,122.41", "37.774,122.419"

That seems so simple and universal and has been a standard since before our great grandparents were born, time to disrupt it to save a couple of bytes?

There are some algorithms that are trivial to implement with Geohashes that are non-trivial with lat-long coordinates. For example, given a set of n points find the k nearest neighbors. To do this with geohash you maintain an ordered list of geohashes, and find k points adjacent in the list. Doing this efficiently with lat-long requires some relatively exotic data structures like an R-tree or k-d-tree.

That is a lossy, incorrect algorithm. Sorry, there is not a continuous mapping from one dimension that covers two dimensions.

Did you reimplement the algorithm, or are you just redirecting the result from the geohash.org api?

Sorry for the late response! I did reimplement it in Go, and I'm going to upload on Github once I'm done toying with deployment.

It was pretty straightforward and there are already a couple of dozen libraries out there, in any language you wish, to get some ideas!

FYI, https://geohash.world/ doesn't go anywhere (for example, clicking in the logo on the top left of the linked page)

Thanks! Yes, HTTPS is not supported right now, as I'm experimenting with various caching/routing. Once I'm done toying around, it will be the default option.

When I see services like this or W3W, I cannot understand what is the goal? What's wrong with coordinates themselves?

Geohashes are incredibly useful when building geospatial software (at least at the UI layer or close to it). With them, bucketing multiple data points that are in close proximity to each other is a breeze, and you then do zooming, panning, etc. with those buckets.

W3W (or the better alternative of Plus Codes) is then essentially just a layer of human readable names to have a digestible encoding of geohashes.

Also, if you are set on using a geocode system, geohashes and plus codes are open-source, public-domain algorithms, unlike w3w, to avoid issues like [1] which was being discussed on HN yesterday.

[1] https://justpaste.it/39hat

The point of a geohash is that it’s super short.

So are the coordinates, right? I thought the point was that they were easier to remember and communicate?

A geohash is 6ish characters and coordinates are usually 10-15 digits. They are both pretty short either way, but a people can remember/communicate 6 characters way easier than 10-15.

Why hop the network for this?

Indeed, I would rather use a library for this

I agree that it's something easy, with already-available libraries. Nevertheless, I hope some people would find it useful, and enable me and others to use it quickly and build something on top of geohash, instead of messing around to get the algorithm right.

How much messing around would there be though?

The first hit for a geohash gem (I'm a ruby guy) returns a github page where the instructions to use are pretty much an include statement and then encode/decode statements.

I don't mean to be harsh, but I have a big problem with APIs where libraries would do, and I think many consider network hops to be too cheap and available. The Sr Engineer in me would never allow a project to make calls over a network unless absolutely necessary.