6 ms·

The article mentions GeoHash [1] and suggests 10:10 is better as it contains a check digit. The advantage of a GeoHash is you can have arbitrary accuracies. For

The article mentions GeoHash [1] and suggests 10:10 is better as it contains a check digit. The advantage of a GeoHash is you can have arbitrary accuracies. For example, if you take the GeoHash for Buckingham Pallace (gcpuuwme9mzp3) and remove the last 6 characters (to give gcpuuwm) then the GeoHash covers a large area of London. [1] http://en.wikipedia.org/wiki/Geohash http://en.wikipedia.org/wiki/Geohash

jgrahamc 15y ago
Fair enough, but that's not the use case for the code. It's designed to get someone who's using a consumer navigation device to a location with reasonable accuracy with high accuracy in entering the location itself.
- bryanlarsen 15y ago
  You've said "that's not the use case" 4 times already, which is almost half the number of comments. Perhaps this is a clue that your proposal needs a bit of work. That's the great thing about hacker news -- you can throw an idea at them, get some feedback, and iterate while it's still cheap to change.
  - jgrahamc 15y ago
    Or it's an indication that people are throwing up use cases that weren't what I was designing the code for. For example, people have said that the ability to compare two codes is important to see how close they are. They've said this without justification and it is not a use case for which I designed the code. Also, people have said that arbitrary levels of accuracy are important, they are not needed for a navigation device being used by an individual to get to a location. Others have brought up the issue of using it instead of postcodes. It was not designed for that either.
    - estel 15y ago
      But isn't it the case that a system for encoding location is more likely to be widely accepted if it can be universally applied to a wide range of use-cases?
      - qntm 15y ago
        Maybe wide acceptance isn't the use case! It's okay to intend a tool for a specific purpose! It's okay to do one thing well.
        owenmarshall 15y ago
        Then the blog post should mention what it does well. In my case, I figured out one place where it would: http://news.ycombinator.com/item?id=2674732 http://news.ycombinator.com/item?id=2674732 This post left too many blanks, and we are trying to fill them in. If you don't show people why we should use your tool, and why it is better than the alternatives, people may not figure them out.
    - politician 15y ago
      "For example, people have said that the ability to compare two codes is important to see how close they are. They've said this without justification and it is not a use case for which I designed the code." So, actually, that property would be pretty helpful for deduplication.
    - owenmarshall 15y ago
      >For example, people have said that the ability to compare two codes is important to see how close they are. They've said this without justification and it is not a use case for which I designed the code. I've raised this objection, but I still think it is quite valid. Compare "43 Montgomery St" to KN4 HNA M33B. First off, I'll tell you immediately which one I find more memorable! I can use any number of mnemonics to store the first; the second is near incomprehensible. Ignoring even that, people have quite a bit of experiential knowledge of local street addresses. Give most people an address -- even an unfamiliar one -- and they can provide with some degree of accuracy what's around, a way to get there, etc. For local use only, this encoding doesn't make sense to me. But, if we assume that the typical user of SOC would be a person who strictly uses their GPS to navigate from point to point, this encoding has some advantages. Another possible use case would be for travelers. Costa Rican addresses are based on distances from landmarks, and as a traveler I quickly learned that many of the landmarks refer to buildings that were demolished in the 1970s! In that case, 75 m Norte de la Coca Cola means exactly as much to me as HFW QMJ BBBE, and this encoding could actually be entered into my GPS.
  - owenmarshall 15y ago
    I kicked this back and forth a bit. IMO, the idea has merit but the presentation wasn't narrowly tailored. It took me ~20 minutes, but I came up with a fairly strong use case: travel. When I traveled to Costa Rica, I quickly learned that no formal addressing system exists, and instead everything is based on landmarks. This made use of GPSes extremely difficult, to the point that many people say using a GPS in Costa Rica is fairly worthless. If I was back in Costa Rica, I'd love to be able to type HFW QMJ BBBE and be directed to my destination, rather than trying to parse "75 m Norte de la Coca Cola" -- first, where's "Coca Cola"? Wait, it's a bus station?! It was a Coca Cola plant back in the 1970s? Gee, that's helpful... More generally: this is why everyone MUST narrow your idea's scope and build everything around that. When I hear "positioning code", my mind jumps to using this code to locate a new restaurant that opened downtown. That's worthless. Just tell me the damn street address instead. But if you told me that this code could let me navigate to a restaurant in a city I've just traveled to for the first time, in a country that doesn't speak my native language, and doesn't do street addresses like I'd expect? I'd say you were an absolute genius. This happens because the post focused on the idea, and barely spent a single line talking about the applications. Thus, I do what everyone else does -- I filled in the blanks. Don't let people fill in your idea's blanks!
- JoeAltmaier 15y ago
  I can easily imagine a consumer navigation device showing me ever-more precise maps as I enter a geohash code. This would be very valuable for orienting myself. I don't just have to arrive there; I want to see where the place is!
Maxious 15y ago
I use geopo rather than geohash: http://geopo.at/intl/en/developer/ http://geopo.at/intl/en/developer/ Can't remember why (the database schema calls the column geohash) but it is great in either system to be able to do a really fast lookup based on a substring and then use proper distance algorithms to narrow down to what's actually close. You need to over shoot as mentioned in the Geohash article because boundaries could be very close to the position.

jgrahamc 15y ago

Fair enough, but that's not the use case for the code. It's designed to get someone who's using a consumer navigation device to a location with reasonable accuracy with high accuracy in entering the location itself.

bryanlarsen 15y ago
You've said "that's not the use case" 4 times already, which is almost half the number of comments. Perhaps this is a clue that your proposal needs a bit of work. That's the great thing about hacker news -- you can throw an idea at them, get some feedback, and iterate while it's still cheap to change.
- jgrahamc 15y ago
  Or it's an indication that people are throwing up use cases that weren't what I was designing the code for. For example, people have said that the ability to compare two codes is important to see how close they are. They've said this without justification and it is not a use case for which I designed the code. Also, people have said that arbitrary levels of accuracy are important, they are not needed for a navigation device being used by an individual to get to a location. Others have brought up the issue of using it instead of postcodes. It was not designed for that either.
  - estel 15y ago
    But isn't it the case that a system for encoding location is more likely to be widely accepted if it can be universally applied to a wide range of use-cases?
    - qntm 15y ago
      Maybe wide acceptance isn't the use case! It's okay to intend a tool for a specific purpose! It's okay to do one thing well.
      - owenmarshall 15y ago
        Then the blog post should mention what it does well. In my case, I figured out one place where it would: http://news.ycombinator.com/item?id=2674732 http://news.ycombinator.com/item?id=2674732 This post left too many blanks, and we are trying to fill them in. If you don't show people why we should use your tool, and why it is better than the alternatives, people may not figure them out.
  - politician 15y ago
    "For example, people have said that the ability to compare two codes is important to see how close they are. They've said this without justification and it is not a use case for which I designed the code." So, actually, that property would be pretty helpful for deduplication.
  - owenmarshall 15y ago
    >For example, people have said that the ability to compare two codes is important to see how close they are. They've said this without justification and it is not a use case for which I designed the code. I've raised this objection, but I still think it is quite valid. Compare "43 Montgomery St" to KN4 HNA M33B. First off, I'll tell you immediately which one I find more memorable! I can use any number of mnemonics to store the first; the second is near incomprehensible. Ignoring even that, people have quite a bit of experiential knowledge of local street addresses. Give most people an address -- even an unfamiliar one -- and they can provide with some degree of accuracy what's around, a way to get there, etc. For local use only, this encoding doesn't make sense to me. But, if we assume that the typical user of SOC would be a person who strictly uses their GPS to navigate from point to point, this encoding has some advantages. Another possible use case would be for travelers. Costa Rican addresses are based on distances from landmarks, and as a traveler I quickly learned that many of the landmarks refer to buildings that were demolished in the 1970s! In that case, 75 m Norte de la Coca Cola means exactly as much to me as HFW QMJ BBBE, and this encoding could actually be entered into my GPS.
- owenmarshall 15y ago
  I kicked this back and forth a bit. IMO, the idea has merit but the presentation wasn't narrowly tailored. It took me ~20 minutes, but I came up with a fairly strong use case: travel. When I traveled to Costa Rica, I quickly learned that no formal addressing system exists, and instead everything is based on landmarks. This made use of GPSes extremely difficult, to the point that many people say using a GPS in Costa Rica is fairly worthless. If I was back in Costa Rica, I'd love to be able to type HFW QMJ BBBE and be directed to my destination, rather than trying to parse "75 m Norte de la Coca Cola" -- first, where's "Coca Cola"? Wait, it's a bus station?! It was a Coca Cola plant back in the 1970s? Gee, that's helpful... More generally: this is why everyone MUST narrow your idea's scope and build everything around that. When I hear "positioning code", my mind jumps to using this code to locate a new restaurant that opened downtown. That's worthless. Just tell me the damn street address instead. But if you told me that this code could let me navigate to a restaurant in a city I've just traveled to for the first time, in a country that doesn't speak my native language, and doesn't do street addresses like I'd expect? I'd say you were an absolute genius. This happens because the post focused on the idea, and barely spent a single line talking about the applications. Thus, I do what everyone else does -- I filled in the blanks. Don't let people fill in your idea's blanks!
JoeAltmaier 15y ago
I can easily imagine a consumer navigation device showing me ever-more precise maps as I enter a geohash code. This would be very valuable for orienting myself. I don't just have to arrive there; I want to see where the place is!

Maxious 15y ago

I use geopo rather than geohash: http://geopo.at/intl/en/developer/ http://geopo.at/intl/en/developer/ Can't remember why (the database schema calls the column geohash) but it is great in either system to be able to do a really fast lookup based on a substring and then use proper distance algorithms to narrow down to what's actually close. You need to over shoot as mentioned in the Geohash article because boundaries could be very close to the position.