Talk:Main Page/Archive 1

From Geohashing

md5 Collisions?

What about collisions in the md5 algorithm?

What about them? In theory, two dates/stock market prices might end up with the same meetup point. Unlikely, and probably not a terribly big deal? Zigdon 07:39, 21 May 2008 (UTC)
There are situations where cryptographic collisions are a problem, but this isn't one of them. md5 is just being used as a pseudorandom number generator here, and it has a very small-entropy seed (someone call Debian!). So its cryptographic strenth isn't particularly relevant. --Xkcd 07:43, 21 May 2008 (UTC)xkcd

OMG geohashing predicts future dow prices!

http://irc.peeron.com/xkcd/map/data/2009/05/27 --Ryan the leach 12:33, 21 May 2008 (UTC)

heh yeh i saw that one too... this is deep magic SinJax
Yeah, I totally wasn't testing stuff, <_< Zigdon 14:54, 21 May 2008 (UTC)

Wow, now you only need to break MD5 to get rich! 81.167.17.12 12:40, 21 May 2008 (UTC)

could be future meetup? --Ryan the leach 12:33, 21 May 2008 (UTC)

Fairly inconsistent if so, what if the dow is different. WHAT THEN?!?
It won't ;) --DarkRat
well the tool wont say its different :P --Ryan the leach 12:33, 21 May 2008 (UTC)

geohash.org

There's already a thing called "geohash" which is a way to represent coordinates with arbitrary precision in a computer and query-friendly format. It's at http://geohash.org/ and it was designed and implemented by Gustavo Niemeyer.

I don't see how that's relevant. We are talking about geohashing. It's a different word.

To decimal

...now, i'm likely just too thick to get it, but how does one convert back from the half md5 hash to decimals?

It goes like this... each digit is a fraction of one but not 10^-n but 16^-n....so the first hex digit is 16^-1, the next is 16^-2 and so on. And it goes from left to right so in the hex number "8d" you get:

f = (8 * 16^-1) + (13 * 16^-2) = 0.5507

i think anyway :) - SinJax


Or, interpret the bytes from md5 as two big-endian 64-bit integers, and divide both by 2^64.

Chicago area

In the northern Chicago suburbs, the vast majority of nearby GPS areas according to the implementation are dangerous pools of dihydrogen monoxide. Is there some workaround?

Chicago area residents could just use which ever of the four locations makes the most sense. (See the Chicago page.)
Believe Adelaide in South Australia Has a similair problem but nowhere quite as severe.
dihydrogen monoxide should be avoided at all costs, if you're careful, you could go to the nearest point at the shore of the dihidrogen monoxide pool, but be sure to not ingest any.
While i'm probably the only Milwaukeean who is going to be running around and playing, my region is about 80% Lake Michigan. No good.
My region is a similar amount English Channel and Solent. I guess this just makes the occasional on-land meetup more special - perversely, I think it might actually *keep* people's attention longer. 81.187.153.189 18:45, 21 May 2008 (UTC)
Catching a statistically improbable hashpoint is more than entertaining. I watch Canterbury, United Kingdom in case I can leap on a ferry to get to the 0.00077 land area that is France (only at low tide). It's like winning the lottery. --Sourcerer (talk) 08:24, 2 July 2015 (EDT)

DOW source

What is our source for the DJIA figure? I only ask because http://irc.peeron.com/xkcd/map/dow.js has "data['2008-05-20']=13026.04", and http://irc.peeron.com//xkcd/map/data/2008/05/20 also says, "13026.04"

However, WSJ (http://online.wsj.com/mdc/public/npage/2_3051.html?symbol=DJIA), usually reliable for this kind of thing, has an opening of "12,958.06" for 5/20/2008.

I could be misinterpreting something. Mattflaschen 13:27, 21 May 2008 (UTC)

And http://finance.yahoo.com/q?d=t&s=%5EDJI does have, "13,026.04". Mattflaschen 13:28, 21 May 2008 (UTC)
We get the data from finance.google.com Zigdon 14:55, 21 May 2008 (UTC)

I think this may help explain the problem with opening values. Perhaps the closing value should just be used as that seems a bit more definitive -- someone may want to check the sources named in this section to see if they agree on closing value. If the closing values of all three of Dow, Nikkei and Euronext were summed, this would still allow for surprise most mornings of the week worldwide -- your surprise would just be based on the closing of a market partway around the world. See #Time_Zone_Discussion for discussion of combining multiple indices. —Christian Campbell 19:32, 21 May 2008 (UTC)

Well, I don't know. The article says, "the posted opening price on the Dow will be close to the previous day's closing price (which can be observed by looking at Dow price history) and will not accurately reflect the true opening prices of all its components." But that's a criticism that the posted opening is meaningless (from an economic point of view). It doesn't necessarily imply that different services post different openings.
The three (Google Finance, Yahoo Finance, and WSJ) do agree on today's closing price. However, I recommend we stick with opening and just state a definitive source. Mattflaschen 20:57, 21 May 2008 (UTC)
Okay. The statements above seemed to indicate that different sources post different openings, and I thought the article might explain that.
Regardless of opening vs closing, the definitive source solution seems helpful. —Christian Campbell 21:42, 21 May 2008 (UTC)

I realize that this is just for spontaneity, and that's great, but lest someone decide to use this for something serious, it ought to be noted that the entropy of the DOW isn't very high: the biggest change ever over the course of a single day is -684.81 (http://www.djindexes.com/mdsidx/index.cfm?event=showavgstats#no4), which is about 16 bits. Most daily differences are much smaller, around half that many bits. It's very amenable to a dictionary attack. --Mike Stay

True... adversaries could prepare to target the 32768 likeliest meetup sites tomorrow. I'll risk it.  ;-) —Christian Campbell 19:21, 22 May 2008 (UTC)
The entropy of the DJIA doesn't actually matter. A single digit change is enough to toss you completely to the other end of the graticule, since the MD5 would be *completely different*. Zigdon 23:49, 22 May 2008 (UTC)

Not just for games

This idea interests me but not necessarily just for games. My only problem is the use of the DOW. Say you maintained a group of people who you want to secretly convene at certain times and locations. The times are all set in advance. You don't want to transmit the location itself since it could be intercepted. Replace MD5 with your own convoluted scheme. Transmit the keys to that algorithm online, through numbers stations, whatever. The point is that you can select their location in advance, compute the key, transmit the key, and nobody would be able to figure out what it meant. If they did know it associated to a geolocation, then they would have to crack your algorithm.

You don't need to replace MD5. Just arrange on a password, and concatenate it with the date and number before doing the MD5. Then you can publish the number and even the method, and your location won't be determinable. -- lilac

Planning Ahead

I tried creating a geohash for june 26th, but it seems you are going off of market data, because it says "no market data for 6/26".

Um, yeah, that's rather the point. Did you actually read the cartoon? The reason for using something unknowable in advance is so that one does not know in advance (except at weekends) where each day's location will be.
Its about spontaneous fun adventures my deary! Just let go, find out where things are on the 25th and make it happen. see you there! SinJax

Map datum?

One thing left unspecified so far is "What map datum should the coordinates be interpreted in?" I suppose that everyone is using the same thing Google Maps uses, by default. Having searched for what it is, I see a lot of people speculating that it is WGS84, though the Google Maps API doesn't say so. --Recursive 18:31, 21 May 2008 (UTC)

It is. (as defined by the recent EPSG standard (that's actually based on MS VE, but Google use the same thing)) --Edgemaster 17:28, 22 May 2008 (UTC)

Europe Time Zones problem

Official Solution

The official solution is the 30W Time Zone Rule, which has been implemented into the map program and will begin affecting coordinates east of -30° longitude from Tuesday, May 27, 2008. The discussion is shown below for archival purposes.

Proposed Time Zone Solution

It seems there are two main proposed solutions. One is to use yesterday's stock openings for regions where the NYSE open is too late in the day, and the other is to use the Nikkei/London for east Asia and Europe respectively. We'll make a decision on that later tonight after reading over all the discussion. If you have an opinion, voice it here. --Xkcd 09:50, 21 May 2008 (UTC)xkcd

Update: Okay, here's my proposed standard: It seems like the simplest, least break-y solution is to simply consider any Dow opening published after noon local time to have happened on the next day. That is, whatever location you calculate at noon using the most recent DOW opening and the current date is the final location for that day.

This is a reasonable interpretation of the original comic, and will only require a small change to the online tool. It means that for everyone in the US, there's no change. Everyone in Europe learns the next day's coordinate the afternoon/evening before. And everyone in east Asia learns it sometime overnight. It also means that for people in Europe, Friday and Saturday will use different openings for their hashes, but Saturday will be known by Friday afternoon. It also, as far as I can tell, means the current calculated location for Saturday doesn't change anywhere in the world.

This would be a problem for places where the local time on one side of the graticule is before noon at the opening and local time on the other side is after noon, but as far as I can tell, all these locations are in the Atlantic Ocean and relatively uninhabited.

Any thoughts? If there are no objections by this evening (EDT) I say we make this the official standard and write it into the reference implementation.--Xkcd 16:16, 23 May 2008 (UTC)Xkcd

Rather than dealing with messy definitions of "local time" (which are a programmer's nightmare), couldn't we specify a longitude, say -30, east of which the previous day's data are used (with apologies to Greenland, of course)? Tim P 16:33, 23 May 2008 (UTC)
That also sounds reasonable. Votes? --Xkcd 16:44, 23 May 2008 (UTC)Xkcd
Yeah, I'm ok with the -30 line. I'll just make sure the tool makes it clear that this rule is applying, and allowing it to be overridden. Zigdon 17:04, 23 May 2008 (UTC)
Pro. This makes the last problem go away, and it doesn't really matter for Greenland anyway, one part of Greenland just knows its location sooner than another part. --FrederikVds 17:19, 23 May 2008 (UTC)
I suppose technically you'd also need to specify an eastern bound. Longitude ±180 would be fine, except then you have to apologize to people in extreme Eastern Russia for not thinking of the International Date Line. I guess those people east of ±180 would just have to use the previous day's coordinates altogether, since they're technically at a longitude where it should be the previous "day". --Tim P 19:29, 23 May 2008 (UTC)
I should add that when the NYSE opens at 09:30 EDT, the mean solar time is 11:30 at that longitude, and it's 12:30 when the NYSE opens at 09:30 EST (November-March), both of which are very close to the "noon" solution of which you speak and much more consistent. Tim P 16:36, 23 May 2008 (UTC)
I don't understand what you're getting at. We don't *want* it to be close to noon anywhere inhabited when the Dow opens, since there will be ambiguity there. --Xkcd 16:44, 23 May 2008 (UTC)Xkcd
I was more so specifying that my -30 longitude solution is roughly equivalent to your "noon" solution, and is actually less ambiguous since it doesn't rely on a shaky definition of "local time." I guess the words just came out wrong. --Tim P 19:01, 23 May 2008 (UTC)
Besides, who's to say what "local time" even is in international waters? --Tim P 19:02, 23 May 2008 (UTC)
Good solution. I can see only one problem: the Monday location will be known on Friday, which is a bit early. But it's probably the best solution. --FrederikVds 17:19, 23 May 2008 (UTC)
But say, in Australia, it won't be known until very late on Friday (sometimes after 00:00 Saturday depending on who's in DST). Effectively, such a solution "redefines" the weekend for those east of -30 as Saturday to Monday, which in many regards is just as reasonable as the Friday to Sunday definition west of that longitude. Besides, there are more Monday bank holidays anyway. --Tim P 19:38, 23 May 2008 (UTC)
Wouldn't it be better to have everyone using yesterday's stock exchange instead, so that everyone has the same co-ordinates on the same date? This way we're going to have two sets everywhere. Nicktaylor 20:09, 23 May 2008 (UTC)
But then we wouldn't be backwards-compatible.  :) That isn't much of a sticking point, but still, it's important to some. --Tim P 20:16, 23 May 2008 (UTC)
Surely half the world is going to be non-backwards-compatible anyway? Nicktaylor 20:20, 23 May 2008 (UTC)
I mean non-backwards-compatible with many of the original excursions and the comic (all of which, calculated before this site went live, are west of -30 lon. Besides, the -30 lon rule would effectively just "reassign" our version of the International Date Line (for DJIA purposes) to -30 lon. --Tim P 20:38, 23 May 2008 (UTC)
Personally, flagging a dozen or so early excursions as "old algorithm" seems a small price to avoid having two sets of coordinates for every day. In the long term it will be far less messy.
If we have to have two sets, surely it'd be better to use a different market index for the East, Nikkei is probably best, in order to maintain minimal predictability. Using yesterday's Dow Jones I'll be able to see coordinates at 2.30pm the day before. Nicktaylor 20:47, 23 May 2008 (UTC)
We will not have two sets of coordinates for every day. We will have one coordinate per day per graticule, same as before. Defining openings which are too late in the day to count toward the next day, by effectively moving the international date line, seems like the best solution. It preserves the fact that North Americans learn the times the same day they happen (for fair races, should that become a thing), it preserves the example in the comic and every North American implementation, and it keeps the Saturday meetups the same as before (which is a feature of both proposed systems).--Xkcd 01:46, 24 May 2008 (UTC)
I vote that if we go that route, someone create an "old algorithm" template. That seems like a fairly reasonable solution. I'm still in favor of the -30 lon solution, because our version of the "date line" has to occur somewhere. --Tim P 21:00, 23 May 2008 (UTC)
That sounds like the fairest, neatest and most International solution to me. Using yesterdays data for everyone also means early-rising American geohashers will get the same location as an afternoon geohasher. Nicktaylor 21:04, 23 May 2008 (UTC)
I'm not sure how the -30lon solution (coining a term, I'm sure) gives different results in America depending on when one checks it. Since all of the US (ignoring the Aleutian Islands) are west of -30lon, they would use that day's opening price, which is released at 09:30 Eastern, 06:30 Pacific, etc. So, the East Coasters will have to wait until later in the morning than the rest of the country. So what? That's how the algorithm was originally defined, and spontaneity is part of what this project is about. --Tim P 21:33, 23 May 2008 (UTC)
  • To summarize my endless blather here: The proposed solution which Randall seems most in favor of (and I am not a Randall) is what I think should be called the -30lon solution. That is, all graticules between -30° and +180° longitude will use the previous day's Dow opening with the current date in their hash. Any users who are anomalously "between" 180° longitude and the International Date Line (such as Russia's Kamchatka Peninsula or Kiritimati Island) are cordially asked to use the date that corresponds with their longitude, not their time zone. And of course, apologies to Greenland for splitting them up. --Tim P 02:09, 24 May 2008 (UTC)

Time Zone Discussion

Even if different regions were to use different values, users in countries and individual graticules/supergraticules will still define meeting times according to local sensibilities, and sometimes will necessarily use the penultimate value when they need more time. Multiple values doesn't really solve this, and makes definition of local convention more complex (deciding whether to use last closing value is tied in with which index to use, dealing with nationalism/regionalism...). Summing a few market closings (see #DOW_source for discussion of opening vs closing values) leaves local convention to a simple definition of how recent a value to use (most recent, second most recent...) and what time/timezone to meetup. Plus, using a common value is just cooler. —Christian Campbell 19:49, 21 May 2008 (UTC)

9:30 AM EST is 04:30 PM CET. So for us europeans it's half an hour or even 1½h after meet up times... :(

So what's a sensible Europe policy? If we can come up with something reasonable we can certainly adjust the tool. (The time zone stuff always makes my head spin a little).
Perhaps we should have anyone east of the Atlantic, up to a point, use the previous day's stock opening. Anyone in Europe have any thoughts?
I'm sorry for missing the point, but 9:30 AM EST on Friday is, by my calculation, 13:30 UTC, so with daylight saving taken into account: 15:30 (3:30PM) in central europe, on Friday. That would give us more than enough time to organise meetups on Saturday, right? The question is: do we do meetups at 3 PM local time or EST? - DWizzy
I vote for using the Nikkei/FTSI

Indeed, how inconsiderate. We could, ofcourse, just say we use the previous day coordinates. Another option would be to use the numbers of a local stockmarket, but that could be a problem here, in the Netherlands, where I live. The country is quite small, and the chances of the meeting point being in one of the neighboring countries (especially Germany) are significant. However, if the Germans use their own stock market, they would have a different meeting point, possibly even in the Netherlands. Since it doesn't really matter which stock market we use, nationalistic feeling aside, we could just pick any one of them, or use the sum or some other calculation of various stock markets. -Sparky


Well, we want to pick something as simple and universal as possible. Some kind of EU market sounds reasonable; I hadn't really thought about that. It'd be nice if there were an elegant global solution that just involved a simple change ... if people here can get a consensus, we'll change the tool for handling Europe better. --Xkcd 07:36, 21 May 2008 (UTC)xkcd
Ideally, the global solution would be to use a market as far east as possible, so that everyone has the co-ordinates in time. But this happens at roughly the same time that the Dow closes the previous day, so that might be easier. It would give people in the western hemisphere a longer time to plan their trip than those in the east, but even New Zealand would get the number in time. -- Zephyr
That could, ofcourse solve the problem, but it's basically the same thing as using the previous days location if you're east of the Atlantic. - Sparky
Of course; but the pedant in me dislikes the idea of having a different algorithm depending on whether one is in the Americas or not. Actually, I suppose it isn't, if only the javascript interpreted "most recent" correctly :) -- Zephyr
Maybe just enter full time with local timezone as a reference time. I mean in the webapp you enter your local, timezoned time. The algorithm converts it to the stock market timezone and counts the latest opening before that. Geohashers around you are more than likely to use the same timezone, as you, so they will get the same location. No problem. Just enter Saturday, 4PM CEST (or whatever TZ you live in now) and you get *some* *predictable* stock market opening. - Tadeusz
Unfortunately, there's no way to have a real "global" solution when using a local stock market. Some random number source from space would work, but would be boring, and too hard to discover. I like the stock market idea. How about this:
  • Hawaii to Newfoundland (UTC -10 to UTC -3.5) uses the Dow Jones
  • Greenland to India (UTC -3 to UTC +5.5) uses Euronext 100
  • Bangladesh to Micronesia (UTC +6 to UTC -11) uses the Nikkei 225
Calculating the local timezone is an exercise left to the reader... -Lucky
I agree about the no-real-global-solution point and in liking the stock market idea, but I don't see why random numbers from space would be boring. The md5 hash deprives the stock market index of meaning -- the only value is the fact that the number doesn't come into our knowledge until a predictable time in the morning. Maybe we can think of something intrinsically local per location? Like the opening value of your country's currency? —Christian Campbell 09:42, 21 May 2008 (UTC)
Like I pointed out before, that would cause new problems near country boundaries, but it shouldn't be a problem in Europe, since most of it uses the Euro anyway. It might be better than choosing any particular stock exchange in Europe, since it's more neutral. - Sparky
I picked Euronext because it's France, Netherlands, Belgium, Portugal, and the UK (but not LSE). But how about this:
  • The most recent opening of the Dow Jones, Nikkei and Euronext multiplied together. The "when" still needs to be taken into account, so say 10am New York for the Americas, 10am London for Europe/ME/Africa and 10am Tokyo for Asia. -Lucky
Great idea, Lucky; I was actually thinking of something like this as I drifted to sleep last night. This neatly keeps the benefit of the coordinate not coming into being until a certain time, but allows three such times per day; is a global solution; and still leaves weekends with a long period of stability (assuming Nikkei and Euronext are closed on weekends -- I'm not familiar with them). Local meet-up times will still be a matter of local convention, for various definitions of local.
One caveat: I'd say they should be added rather than multiplied. Adding would make it insensitive to different ways of multiplying.
See #DOW_source for discussion of opening vs closing values. —Christian Campbell 19:20, 21 May 2008 (UTC)
Lucky, perhaps I misunderstand your "when" point. I think you need to rely on a time when the value stops fluctuating and can be agreed on (such as closing). So I don't suppose you meant to look at a market during a time while it is open. If you meant to hold off performing the calculation until 10 o'clock with a value from an earlier time, I don't see the point, and anyway people are going to perform the calculation as soon as the inputs are available. Besides, that's half the cool factor: jumping on it. =-) —Christian Campbell 20:08, 21 May 2008 (UTC)
there are currently, I believe, 6 'areas' covering The Netherlands, but we could always decide to rotate fairly between those coordinates - with, as a bonus, we have a backup location when one is unreachable. I'd say, leave that to the locals. -DWizzy

I am in favor of the "use the DOW of the previous day" solution. This makes the tool simpler, and the point distribution around the globe uniform. - Sec

I'm not quite sure what to make of it. For Central Europe (I'm Dutch myself) and everywhere else I can't see why we wouldn't just pick a stock market on twelve hours distance from the Dow. As for Dutch meetups I'm all for cycling through the different areas as to get more people at one meet. Nazgjunk 09:24, 21 May 2008 (UTC)
No, honestly. You want to meet at Saturday, 4PM UTC (or whatever european time zone)? Get the latest Dow opening before Saturday, 4PM you-local-time. Just works.
Problem is that the sample calculator uses this page to grab the data of the Dow Jones. And that one will only show the opening price after the Dow has closed already. At least, according to my clock the Dow Jones is already open, and it still only shows the data of May 20th. - MadJo
Using the value available at the time of the calculation looks the way to go

Why not use the Dow value from (meetup_date - 1 year)? That lets you generate a meetup spot up to 364 days in the future (leap year pedagogues, keep it to yourself), and time zones become irrelevant.

Because not knowing the meetup time until shortly before it happens is a very important feature, not a bug. Otherwise why use the Dow in the first place? --Xkcd 01:47, 24 May 2008 (UTC)

Is the DOW/timezone thing a problem for Saturday meetups in Europe? Saturday's coordinates are generated from Friday's DOW opening value, which is available at 0930 EDT (1430 BST in the UK) on the Friday. So there's over 24 hours notice for the meetup coordinates in Europe. - Ytaya

Ehm, you have a point here. We seem to have collectively forgotten that the Saturday calculation uses Fridays numbers. - Sparky.
Yeah, that works for Saturdays but what about other days? Maybe the thing with the DOW from the previous day works, most news stations report about that anyway. - Kiwi
I'd suggest only doing the meeting on saturday, to increase the chances of meeting, possibly even with a smaller grid to reduce travel distances, and most people have to either work or go to school at 3PM on weekdays anyway. - Sparky
If we're only likely to meet people from our own graticule (and possibly neighbouring, watery graticules) then we only need a local convention. I agree with Ytaya, in the UK at least the Friday DOW opening for a Saturday meet 4pm local time or the previous day's opening for a week day seems to retain the elegance of the system. - Nick


I can't believe we are actually arguing about this. It says so in the comic itself: "That date's (or most recent) DOW opening". So, if the DOW hasn't opened yet, you use yesterday's opening. Simple as that. Why complicate it further? Arj 13:33, 21 May 2008 (UTC)

The problem is the specifics around your phrase "hasn't opened yet". Given a region where the figures become available half an hour before the meetup time, then either people take the previous day's value and meet up in a location which is technically incorrect by the time of the meetup, or you rule out anyone who cannot check the value, plan a journey and travel to the location within half an hour. To me, the obvious solution is that the value used has to be defined as the value that was available at a fixed offset from the meetup time - for example six hours before. But that complicates the JavaScript that pulls the figures, as mentioned above... --cfm

That would still leave some ambiguity for the area around the timezones that are 6 and 7 hours before EST, because the time of the meeting depends on which timezone the meeting takes place in. Again, there could be 2 meeting in different places, 1 hour apart within the same region, of no meeting at all. This could happen on every single day except Saturday, and thus would happen quite frequently. - Sparky

I guess the reason to use stock exchanges is that those numbers may be available to everyone even without the internet. If we don't care about people who don't have internet, it seems most logical to just make the server grab a true random number from somewhere every day or interval and use that. Then we are in control of the situation and can set it up however we want. - forest

Why not use yesterday's DOW opening *everywhere*? This would have the pleasing result that you could have one destination for each midnight-midnight day and there would be no time when it wasn't defined. - Sarah


How about there's a fixed time at which the algorithm is run, for example 10am local time. That way it's standardised as to whether you need to take the day before's or today's (i.e. has it passed 9:30AM EST yet by 10AM in your local time). This also means everyone has at least 6 hours notice before meeting, so we don't get the issue like in the UK where it's available at 2:30pm and I'd struggle to make places in 90 mins given I go by train and bike everywhere. If we stray too much into different stock market figures or different timings for things, I'd fear we'd split the community over which version to go with and people go to different places on the same day, missing each other. I think a standard and an agreement is important above all. --AvengerPenguin 12:52, 22 May 2008 (UTC)

If the coordinates can be calculated further in advance (ideally a week, since most meetings will be weekly and most people wouldn't have time to attend more) people would be better able to schedule meetings. UK train tickets are cheaper when bought in advance. I also second comment below mine.-- waq (forgot to sign the first time)

I notice this still hasn't been resolved, so I'll suggest a further simple solution. If everyone everywhere just replaces "today's Dow Jones opening" with "yesterday's Dow Jones closing" then everything works fine. 131.111.202.214 15:09, 22 May 2008 (UTC)

Algorithm shortcomings: are we missing the point?

A significant number of people are commenting on "shortcomings" in the algorithm. e.g. some cities are split between over multiple graticules, meet up points over water, the Dow not suitable because of time zones, etc, etc, etc......

While from a geek standpoint I admire the pursuit to "improve" the algorithm, I think its missing the point. My interpretation of Geo Hashing is it’s about a chance to do something out of the ordinary, make our lives a bit weirder, and maybe even meet and communicate with your fellow human beings. The algorithm itself is just a starting point for these activities. Even the "perfect" Geo Hashing algorithm isn't going to make these things happen unless we step outside the front door. 

--Lowman 00:00, 23 May 2008 (UTC)
Absolutely - and it's absolutely geekily cool that we're taking a numerical contruction (latitude and longitude) and laying it over the physical and human geography, and saying - "no, sorry, we're sticking with th numbers..." Then, there's the fact that I'm doing something here in rural Norway that you're doing in - wherever - Chicago, Portland, London, whatever. So please, stop trying to break this thing. If you want to organize something centred on your city, or optimised for your life, join the Kiwanis. (not to degrade the Kiwanis - they're cool, just they're not GeoHashing). AshleyMorton 00:17, 23 May 2008 (UTC)
Lowman is spot on. I completely agree. It's supposed to be random. "Fixing" and "Improving" something like this just detracts from the core purpose: to go with the flow and have fun. Adding constraints just weighs everything down. That said, it's gotta be annoying for those residing on tiny islands. When the coastguard picks you up from an offshore reef on Saturday, tell your rescuers "the internet made me do it". - Somersault 03:24, 23 May 2008 (UTC)
I'll agree here, so what if half the graticule is over water or in another country, wont that just make it more special when you do finally get to go to one? --Zorg 07:57, 23 May 2008 (UTC)
Another vote of agreement here. For the vast majority of people, if they really want to go to a location, you can travel to the next graticule over, which won't be more than a couple hours away. And even if you can't do that, one in every 20 or 25 times it will be in a decent location. If you want more than that, start geocaching or go on a site where humans have picked the locations. The fun of random is that it doesn't always work. Who wants to meet every week or go to a location every day anyway? It would get old way too fast if it was too easy to do. --Cahlroisse 08:05, 23 May 2008 (UTC)
Second, third, whatever. If it doesn't work - over water, private property - then don't go. No-one's forcing you to. Gormster 15:31, 23 May 2008 (UTC)
I totally agree with those ideas. but, what if you lived (LIKE ME) in a graticule wHich was 50% OF water? how could you ever have some fun? most points are over water. Don't take me wrong. I can swim rather will... but 5miles of swimming will probably kill me.

Most of the time it's just a waste to check the points. I get very disappointed. I'm very adventurer and love geohash and I really don't mind whatsoever to reach very hard to reach points even private property, mountains, islands etc, I even enjoy a lot more those kind of locations. but... over water?! I can't afford a boat capable of surviving the ocean. even if I could after 10 points over water it wouldn't have any fun... isn't what geohash is all about? having some fun? I feel I'm being graticule discriminated. Now you tell me, next gradicule? well.. it's over water too. And what if some of my friends who live in azores and want to geohash? really... I would abolish all water locations, or at least something like this: "if point is X miles from nearest point on land, generate another point" or wtv.

Saturday Times

Um the blog post says the meet ups are at 4, the wiki says they are at 3, is one time more official?

We were still going back and forth and the wiki hadn't been updated. For now, 4:00 -- closer to dinner :) Xkcd 06:55, 21 May 2008 (UTC)xkcd

What happens if the meeting point and me end up in different time zones? This is a particularly serious problem for those who live near the International Date Line, where it deviates from the 180° meridian. I guess the most natural way would be to define that the meeting time should be 4:00 according to the destination's local time, but as far as I can see, this is nowhere defined --62.20.90.195 10:54, 21 May 2008 (UTC)

Well, if you arrived according to your local time, people from either side of the International Date Line would arrive at different times. So it seems sensical for it to be the meeting time according to the destination's local time, as you said. -- 212.219.57.58 11:55, 21 May 2008 (UTC)
That still leaves a problem near the date line: there could be two consecutive Saturday meetings, one on either side of the date line, or there could be no Saturday meeting at all, because one day, the meeting point could be on the side where it is Friday, and the day after, on the other side, where it then is Sunday. The problem is that the date is not clearly defined in a region that is divided by the date line. I doubt it will be a problem in reality though, as the date doesn't seem to run over land, so any region that it runs though will have one side that is completely in the ocean. If we'd just agree to use the local time at the meeting point as the time reference, the whole time line problem is solved, I think. - Sparky
Um, the IDL deliberately avoids crossing nations internally, and I suspect that there aren't that many corner cases where the differing time zone becomes a problem. 192.43.227.18 14:10, 21 May 2008 (UTC)

Perhaps it would be a good idea to have the meetings at lunchtime (say, 12:30 local time), so that people who have to work on weekdays (or Saturday, for that matter) can still go to meetings during their lunch break if it happens to be close enough to where they work. - Sparky

What about weekday meetup times? Should that also be 1600 since people who work won't have time to attend weekday meetings anyway. If I had to set a meetup time, I'd say 6:30pm, which gives enough time after work to get to the place and isn't too late. --waq

Nearby Points?

I forgot to mention that the algorithm doesn't necessarily find the point closest to your present location. Ofcourse, the user can manually select the other regions around his location to find the closest meeting point, but it would be nice if the google earth app would show the 4 closest locations. That way, the chance of meeting different people is greater, because any user would be in 9 regions instead of just one. This could also be useful if the closest point in unreachable, where the user could choose to go to the next closest meeting point. - Sparky

Well, it depends ... generally you'll have one population center surrounded by fairly empty areas. I think we'll be able to better answer this question after a week's experience. --Xkcd 07:46, 21 May 2008 (UTC)xkcd
That, also, depends on where you live. The distance between two closest points horizontally or vertically is approximately 111km. The Netherlands is barely 200km wide. Especially in the western part of the country, which is the most densely populated, cities are rarely more than 15km apart. - Sparky
The thing with having one region is that you get to meet with the same people each time, which could be a good thing - since otherwise, you don't know who you're going to see again. (Though that could be seen as a plus, of course.) My region includes most of London, so in my case I'm probably going to get more people coming to the meet in my region than I am if I was to go to whatever was the closest on the particular day. - Kira. (74.52.15.98 13:16, 21 May 2008 (UTC))

This is most excellent, I know I'm participating! -Sir_Lewk

Would it be possible to include the route-planning feature in the map? For those without navigation systems, that would be very useful. - Sparky.

I'm from Australia, is there any chance of this being implemented in the Pacific Region as well? It sounds like a great idea. - Zorg

This does work for the Australian Region. I'm in Sydney, as of July I'm getting on board --Phraedus 10:20, 21 May 2008 (UTC)

Two thoughts for improvements:

  • Maybe use a smaller step size ? If you do not own a car then the destination can be unreachable. Also in Europe (where i am) the polpulation density is in general higher, so one grid cell might encompass two major cities.
We discussed this quite a bit -- currently, the average driving distance is something like 45-50 miles. But if you're trying to have an xkcd meetup for your city, it'd only compound the problem of cities being split up. Half your friends would go to one and half to another. It's already bad enough in DC and Chicago. --Xkcd 09:12, 21 May 2008 (UTC)xkcd
This, ofcourse, strongly depends on the population density (or actually, the XKCD reader density). If you make the regions smaller, the chance of 2 or more people meeting there decreases. As people fail to meet, they stop trying, further reducing the change of a successful meeting for those who try at a later date. - Sparky.
And L.A., Pittsburgh, Philadelphia, Denver... - Cahlroisse
  • 45-50 miles is too much for nonprofessional cyclists, are we encouraging petrol burning? Too bad for the ecosystem :P 80.36.82.38 10:01, 21 May 2008 (UTC)
I agree with your point about encouraging petrol burning, however, at some (maybe most) places, such large grid size is needed to have any significantly non-zero chance of meeting somebody. The problem seems to be that there is no clear one-size-fits-all grid size. Implementing a variable grid size sort of eliminates the elegance of the algorithm. Maybe this is just a stage we have to go though; you come up with a simple idea, which grows ever more complicated as it's developed, until you end up with a simple solution - Sparky.
  • I'd propose a cell size proportional to the population density. I agree it undermines elegance and simplicity, but sometimes (most of the times?) simpler solutions are just not satisfactory. Besides, seeing the cell sizes changing along with the local population density has a coolness of its own. --80.36.82.38 14:35, 21 May 2008 (UTC)
The ecological implications of petrol burning aside, i just don't have a car ;-) But I agree with you. To allow actual meetings to happen, you need a big grid size, especially in the beginning. -Mucki
I don't have a car either, because I far prefer a motorcycle. I don't really see any options that would enable the use of public transportation without sacrificing to many other properties of the proposed system. I'm afraid the only thing you can do is wait until the meeting point is within a reachable distance. If you can travel 20km in any direction (by bicycle, for example), about 9.8% of the meeting points will be within your range. - Sparky
Perhaps the solution should include people developing their own cell sizes on the city pages to allow for better distribution based on population. For example I can see that there might well be demand enough for both a San Francisco city based cell (based entirely within the city limits) and a larger cell that would include the surrounding areas. At present the cell for SF includes the penninsula far more than it includes the city and has a rather large amount of water as well. Since we have such a high degree of population density, however, it would likely not be a problem to cause such splits. Clearly the issue that's really raised here is that a one-size fits all approach based on pure geography without regard for population is not necessarily the best one. - Belgand
  • I think the algorithm should include the base coordinates (the integer portion of your gps location, or maybe even some secret number?) in the hash, otherwise the meetup points form a regular grid, offset by a fixed value from the base coordinates. - Mucki
I don't really see why that's a problem. In fact, it has a couple benefits -- if one coord is all the way to the north of a graticule and you're at the south end, it means the coord in the graticule to the south will be close to you. --Xkcd 09:12, 21 May 2008 (UTC)xkcd
I'd agree; I don't see what's wrong with a regular grid of possible meeting locations, while the upside is that the nearest location is at most 1.4 * 111 / 2 = 78.5km away (half the diagonal of a 111 * 111 square), assuming it is reachable, ofcourse. - Sparky.
I just thought I should add something: this is, ofcourse, only true on the equator, because the distance between the medians reduces as one moves away from the equator. - Sparky
Well, it is not really a problem in itself, but I find that a very regular spacing of the points somehow diminishes the beauty it gets from being otherwise completely random and unpredictable. -Mucki
I would agree with that, however, this does guarantee that there is a meeting point relatively close to you (regardless of reachability).
Except if you live on the Greenwich meridian, and then occasionally the shortest distance will be an entire box-width west or east. And if you live in the N-S centre of a graticule, this maxes out as the diagonal of a 111 * 111/2 rectangle, or 124km. (sucks to live at 0,0... in the ocean south of Ghana...) In the UK, it's more like 111 * 67, an 87km diagonal.

Oddly, where I live (Boreham, Chelmsford, Essex, UK), apparently whatever day it is, I should be meeting in the exact same place in the Thames estuary (I've tried about 5 different dates). Is there something amiss?91.107.26.104

It seems to be working fine. Different coordinate for every day this past week in the 51, 0 (east) graticule that contains Chelmsford. Any more details on the problem? --Xkcd 09:24, 21 May 2008 (UTC)xkcd

hi there, about one thid of my sector is covered with water. are you going to do any sea/ocean detection?

Could I suggest adjusting the main wiki page to say if your meetup is covered by water, click on the next closest square away from the water? Might solve some problems --Phraedus 10:20, 21 May 2008 (UTC)

This may have been covered already, but i'm confused about how the center of mass calculation is working. No doubt a cost function of some kind, but the question is why land mass isn't taken into account, or so it would seem! For example: where i am (Southampton, Hampshire, UK) the center of pass seems to be somewhere in the ocean. Now i realise this is probably due to the isle of white right below southampton. Possible solution, if the area covered by the center of pass holds more than...i don't know...40% water, adjust some variable to force a reduction in granularity. Mainly because the geohashes for the past 4 days have been in the middle of the sea and the reason is clearly just the odds given the amount of water in southampton's center of mass. Also, i've got a python implementation of this appy going, but i don't have access to the center of masses, though this might be me just being silly. Are these available somewhere in a handy dandy XML format?, cheers - SinJax

The squares are the zones bounded by latitude and longitude lines, nothing more. This means the configurations are sub-optimal for some cities, and there will be various conventions for dealing with those.
Oh i see! Talk about over complicating things in my mind :). And the lat/long for each square is the center of the square i assume? or what? Also is it cool if i use the dow data avaiable at http://irc.peeron.com/xkcd/map/data/ for my python implementation directly? or should i contact another webservice somewheres? SinJax
The boundaries of the zones run along the exact longitude and latitude lines closest to your location. - Kira. (74.52.15.98 13:20, 21 May 2008 (UTC))

I live nearly on top of a confluence (northeast of Indianapolis). Would you say that I could choose one of four grid areas, so that I don't have to travel too far? Halcyone1024

Pittsburgh is annoyingly (or beneficially) split down the middle(the very middle 40.441419, -79.977292)

People here have a point about population density. In some places in the world everyone has a car, but in other places a lot of people don't. I almost think that separate areas should have entirely separate rules or something. But again it all depends on how complicated it should be. It could be super simple like it is now and work okish, or be super complicated and maybe work better or maybe not. Personally I currently live in the middle of nowhere so there aren't enough people to make it work, even if we were willing to drive quite a ways and use large graticules. I have also lived in other places where car ownership is low and for most people on most days the meeting point would be out of reach. - forest

Polar coordinates?

I've played a bit with the map, and found out that my town, Freiburg, is right at the edge of a grid (48°000), and that the grid is fairly large. An alternative implementation could use city centers as fixed points and calculate polar coordinates (distance and angle) from the "random" seed. -- tillwe 132.230.104.57 10:02, 21 May 2008 (UTC)

I think this issue is deeper mate. It would seem that the grid implementation is remarkably unsatisfactory when it comes to places in europe and especially england, however, a random distance from city centers wouldn't work very well in sparse areas like america. Some concept of centre of population is required here. SinJax

The problem with living near an edge is non-existent, I think. The maximum distance to the closest point is always half the length of the diagonal of a grid cell. - Sparky

I think we should try to preserve the simplicity and elegance of the algorithm, which, in it's basic form, relies on only 3 pieces of information: the date, the random seed (stock exchange), and the integral part of your location. Adding information like databases of population density would completely ruin it, if you ask me. You might as well include information about computer use and the percentage of the population that can read english, as there are things that strongly influence the XKCD reader density. - Sparky

Maybe we could use a smaller grid size, and have a convention that in more scarcely populated areas, only the even numbered ones are used, or use the ones closest to city centers or something. We don't have to deal with all the cases in the calculation algorithm, we could have the user execute part of the "algorithm". However, the idea is that the user can't really choose where to go. If the user has any control, it should be limited (at the moment, the user can ofcourse choose any of the ~40000 reachable points on the planet) - Sparky

Good call that sounds workable, fixes the problem in southampton anyways :) SinJax

I've been a follower of geohashing for years. This is the biggest problem of geohashing. it's stupid. it has major flaws. I love the concept and I would love to play. except... I can't ever play! I live in Azores. you known, a small group of islands in the middle of the Atlantic. How am I supposed to play if 99% of the hashes are on the sea?!?! This happens a lot! and that's not only with me. My brother who lives in Lisbon also complains a lot about it since a great number of hashes are always unreachable unless you are a rich geohasher who has a sea worth vessel capable of dealing with the high seas. and even if I had any boat it wouldn't be any fun to always travel to a location surrounded by water. you could easily fix this! "if hash location is on water (or X km from nearest land point), generate another hash for the graticule" I also want to be a geohasher :( I'm being target of geohash discrimination.

Page Forwarding

I am just learning how to work on wiki's so please forgive me but I am wondering if there is a way to make a page automatically forward to the correct graticule page based solely on the latitude and longitude. For example, if I am linking to the page currently called "Springfield, Massachusetts" I want to link to 42, -72. I see this as a benefit in case someone later down the street decides to rename this page "Springfield, MA" and my "Springfield, Massachusetts" link no longer works. Or are the links not changed when the page name is change?--KDinCT 17:17, 21 May 2008 (UTC)

There are some ways for this.
-Having pages redirect to others, using #REDIRECT [[NewPagename]]
-You can give links different names using [[Pagename|Linktitle]]
This should get you running. Nazgjunk 17:30, 21 May 2008 (UTC)

failsafe distributed geohashing

There are a few undesirable issues with the data source for geohashing:

  1. It relies on data from the stock market, and the stock market is a yucky, yucky institution.
  2. in case of a nuclear winter, terrorist attack, natural disaster or other breakdown of society, the data source for entropy disappears (same with weekends or mornings before 9am).
  3. it is insufficiently DIY.
  4. there is only one location per day (or three days in the case of weekends). This means that if you discover that your communication channel has been compromised and that THE ENEMY knows where you are going to meet, there is no way to broadcast new information over the compromised communication channel such that the BAD PEOPLE won't be able to find out the new meetup location but the GOOD PEOPLE will.

A solution: The weather is a source of data that is always available. Further within a local area weather is fairly (though not completely) constant so it is suitable for DIY weather stations. If time is built into the procedure then it can give multiple points per day, plus a broadcastable variable such that the BAD GUYS can't figure out the new location (assuming they don't know how you generate the locations).

Procedure: Choose the date plus a begin and end time (measured in 10 minute blocks). Then you go and find out weather data for yesterday for your location. From this choose the data points for you start and end time as well as the max and min temp (and when they happened. Then use the following (or something like it) to generate the data for the hash:

  • <date>
  • <start time> <last digit of temp (decimal point rounded)> <second and third last digits of pressure (last digit rounded)>
  • <end time> <last digit of temp (decimal point rounded)> <second and third last digits of pressure (last digit rounded)>
  • <last digit of max daily temp (decimal point rounded)>

Example: [23-05-08] [6.50 9 02] [7.00 9 02] [0 2 4 5] (square brackets are only to enhance readability). from original values:

  • date: 23-05-08,
  • time: 6.50-7.00 (24 hour time of course),
  • temp and pressure at 6.50: 18.6 C 1018 hPa,
  • temp and pressure at 7.00: 18.9 C 1017 hPa,
  • max temp:29.9 °C at 12:25,
  • min temp:13.5 °C at 06:52.

Because such a small time window was used the temp and pressure ended up being the same for our purposes, however for time windows of an hour or longer this would rarely be the case. If you want more entropy you could add sunrise/setplus, average rainfall over the preceding month, max and min UV index, etc. Importantly, it should use variables that will be different from one day to the next, but which are able to be measured with reasonable accuracy from any place in a smallish city. This means that the fine end of a measurement (ie. decimal point) should not be used, nor should the gross end (eg. the thousands for hPa and the tens for temp). For those without their own weather station you can easily use one of the billions of publicly available ones eg. http://www.wxqa.com/stations.html .

-rjs.

I don't see this as failsafe. You all have to agree on a particular weather station. If everyone had their own weather station, everyone would get slightly different readings. Even minor differences can have major effects on the resulting md5 calculated location. --engunneer
Besides, what's to say that your chosen weather station will be failsafe itself? --Tim P 19:07, 23 May 2008 (UTC)
Also sunrise and sunset are not entropic at all; there are algorithms in place to calculate this data very far in advance. --Tim P 19:08, 23 May 2008 (UTC)

Flags

Did you ever watch The Amazing Race? They had red and yellow flags and arrows to signify that there was something to do with the race nearby. Red and yellow were their colours. I'd suggest a similar two-colour pairing so that fellow geohashers can easily find each other at the marker. I'm gonna suggest blue and green, because, you know, geo. Gormster 15:43, 23 May 2008 (UTC)

Except that blue and green would blend in with the scenery? --WokTiny 15:47, 23 May 2008
Won't be liking that choice (i.e. blue and green) during the hunting season on a MNIMB Geohash. --KDinCT 16:12, 23 May 2008 (UTC)
 ??? I'm confused. Gormster 00:29, 24 May 2008 (UTC)
How about brown and khaki -- and antler hats? --Ahecht 16:56, 23 May 2008 (UTC)
Um, who would be cleaning up all these flags from all over the world? I don't think we want to be littering quite that much? Zigdon 17:48, 23 May 2008 (UTC)
If you need flags for anything, they make a biodegradable flagging tape for just this sort of reason. Geocaching sometimes uses it to signify things during day-long events. If it gets left behind it's no big deal that way. 155.41.240.238 18:55, 23 May 2008 (UTC)
Okay, when I said flags I didn't mean literally flags. I meant something to alert others to your presence. It can be anything, paint, tape, as long as it's those two colours. Gormster 00:29, 24 May 2008 (UTC)

World map

The Active Graticules page is getting too big, so I was thinking about making a world map, linking to the graticule pages. I'm trying though I don't know if it's easy.--FrederikVds 16:03, 23 May 2008 (UTC)

Amen to the Active Graticules page getting too big. I too was trying to think if there was a visual way to lay it all out. Or a way to break it up so it isn't such a huge list. But then again if all of the graticule pages are properly categorized with countries (and states) the category page will help locating graticules much easier. I will be interested to see what you come up with. --KDinCT 16:10, 23 May 2008 (UTC)
The code will probably be something like Template:Worldmap, only the wiki doesn't seem to let me use <script> tags for obvious reasons. I was also thinking about using an iframe, but it doesn't let me use that either. How is it done for the <map> tag? --FrederikVds 16:36, 23 May 2008 (UTC)
The <map> tag is an extension I wrote to the wiki. Would a link from the map tool itself to the appropriate wiki page be useful? Zigdon 17:49, 23 May 2008 (UTC)
I'm not sure what you mean. My basic idea was a big world map (Google Maps) with all active graticules surrounded by a red rectangle, and clickable. Maybe you can extend your map tag to do that?
Edit: I tried if it's possible using a static map image and a table, but that's too hard. --FrederikVds 19:10, 23 May 2008 (UTC)
The new version of the map page (which should go online tonight) includes links to active graticules. It doesn't make it obvious where they exist - I'll see if I can generate a gmaps overlay to make browsing easy. Zigdon 03:01, 24 May 2008 (UTC)

How to recognize each other?

There should be some distinctive sign for geohashers so they can distinguish fellow geohashers from people that are just passing by. The problem is, if you just start asking random people "are you geohashing?" you are going to make a fool of yourself, but on the other hand, if you spend an hour standing without moving in a weird place looking particularly weird, you are also quite likely to make a fool of yourself. So this sign should be obvious enough so that geohashers would immediately recognize it, but at the same time discrete enough so as not to draw attention of other people. --Ilia 20:30, 24 May 2008 (UTC)

Keep an eye on #Radio Frequency Standard on this page; ideas are being discussed. --Tim P 23:10, 24 May 2008 (UTC)
Buy an xkcd shirt, and wear it on your geohashing trips? 71.34.59.134 03:42, 25 May 2008 (UTC)
Haha. Sounds like a reasonable solution to me! --Tim P 15:16, 25 May 2008 (UTC)
(a) What's so bad about making a fool of yourself? I would think that's fully in the spirit of things! (b) It shouldn't be TOO hard to find the folks staring at a GPS geeking over the 100,000ths digit, out in the middle of the woods ;) Ok, even in town, that should be an easy one. I had several Google-Maps printouts, a GPS and a camera when I arrived. I'd think others would be similarly prepared. (c) why would we not want to draw attention? If The Revolution is to take place at all, it must be noticed!  ;) Ted 18:48, 25 May 2008 (UTC)

Zero degrees longitude

Note that there is a negative zero, for those of us near the Prime Meridian (e.g.: London). The algorithm will then lead to longitudinal coordinates such as -0.1234 instead of 0.1234.

Correct - this is by design. Zigdon 14:55, 21 May 2008 (UTC)
Heh, indeed - To clarify, I added this info because London West was originally listed as longitude -1 (as opposed to -0). I didn't intend to imply it was a problem to have negative zero, I just wanted to flag the issue. Sorry for any confusion. 194.74.151.201 16:19, 21 May 2008 (UTC)
Actually, it appears zones are numbered with the WESTMOST longitude coordinate. In the west, it doesn't make much intuitive sense, because, for example, all locations in a zone labeled with -80 longitude begin with W 79°. As such, London West actually is -1. Tjtrumpet2323 22:21, 21 May 2008 (UTC)
A heads-up to the person who created the rss feed: the script doesn't recognise the existence of -0, but if you pass it -1, you get (as you shoulld) a longitudinal co-ordinate -2 < x < -1. There's no way to get any of the graticules where -1 < x < 0.


If this was by design, then can the design please be reconsidered? For everyone else, the maximum distance to a meetup is the diagonal length of a graticule, but for people on zero degrees longitude / latitude, it's further than that. For instance, the nearest two meeting points to me (in Cambridge UK, at 52, 0) are at 52.179467°, 0.861536° and 52.179467°, -0.861537°, both of which are too far for me to visit. Can we change the algorithm to round down, rather than truncate, the starting location? -- lilac


The map tag for the graticule template also doesn't recognise -0 - for example, it is impossible to add a map to Northampton, United_Kingdom, the map just keeps centring on Cambridge. Nicktaylor 14:12, 23 May 2008 (UTC)

This will be fixed shortly - you will able to specify the 'abs=1' tag, which would mean that entering "-1" would be the grat between -1 and 0 (instead of -1 and -2). Zigdon 17:43, 23 May 2008 (UTC)
Am I to understand that with the new parameter, one will be able to directly specify the integral portions of their home coords? That would be ideal. In any case, please make sure that the reflections around 0 (both E/W and N/S) end up being very well documented when you make this change. At times, the Active Graticules page has been a mish-mash of many systems. --Tim P 22:16, 23 May 2008 (UTC)

I created the -0 Issue to summup this problem (and to bring a solution).

Small Islands / Countries

One problem with this are small countries such as Malta ([1]). It's split into two reagions and both are very small relative to the degree grid box. It would make more sense two have the entire country as part of a single region (i.e. shift by half a degree). This of course would not occur to you, big country - americanites ;)

I don't see why this would be a problem since if it is a point on the western part of the grid then you go to the east side of the island (and it's associated degree grid box) and if it is a point on the eastern part of the grid then you go to the west side of the island (and it's associated degree grid box). But then again I am just a big country Americanite.

We could, for such case, agree to add .5 degrees to the coordinates as needed to have the meeting point on land, or you could just all agree to swim or row to the meeting point instead. - Sparky

Yeah, in Halifax NS (where I live), most of the square is in the sea. In Victoria BC, (when I happen to be right now), a good chunk of the square is in the sea, and a good chunk is in another country. In Wellington NZ (where I'm from), most of the square is either in the sea or an expensive 3-hour ferry ride away on another island. I suggest that you should be able to set the centre of the square with a higher granularity - say 1/10 of the square size. Then it's still not too hard to make sure everybody is using the same square, and it allows you to position the square such that it's mostly overland, and mostly in your country. 24.68.238.83 14:06, 21 May 2008 (UTC)

I've said this before, and I'll say it again: the boundaries of the cells are completely irrelevant, because the meeting point is in the same place in every single cell. The meeting points are exactly 111km apart in both directions, and there will be a meeting point within ~78km of every single point on the surface of this planet. If that point happens to be 30km out to sea, there will be another one 111 - 30 = 81km inland. If you live on an island which is significantly smaller than 111 * 111 km, well, you're just not destined to meet people, I guess ;-)
Okay. Don't get me wrong. I agree with the system, but what you're saying isn't entirely correct. It is possible to have meetup points further apart than that. Like, for example, what if you lived in Haywards Heath, UK. It's close to the Prime Meridian. Because of the algorithm, it's possible for the geohash to give something like .99999 west or east. Like for example May 11. It's just a hair over that, but it's possible to get further. (Greenwich may 18th...). McKay 15:21, 21 May 2008 (UTC)
Yes, you are entirely correct. I didn't realise that the algorithm mirrors the coordinates around the 0 medians (on the north-south and east-west boundaries). This artifact of the algorithm can be removed by inverting the fractions in, for example, the east and south hemispheres. - Sparky

I would love to see if we could design an algorithm for New York City. Currently over half of our graticule is over water and most of the rest is in long island, inaccessible to anyone who those who live in the city and dont have a car. Maybe if we defined the geographical center of the boroughs (on a set of rotated axes, of course) and then scaled down the minutes to fall within the range of Manhattan to Brooklyn we could keep the number of feasible locations as high as possible...any thoughts? Or, like most people in NYC, do I just care too much? -Monica

Problems with original implementation east of 30W

I just edited the map.html to apply the 30W rule only for dates on-or-after 2008-05-27. Zigdon 15:21, 25 May 2008 (UTC)

I don't suppose its possible for me to get the map tag on 2008-05-21_54_-2 to show the coordinates as they were when the trip was made, ie, under the original rules? Nicktaylor 18:14, 24 May 2008 (UTC)

Not presently. I'm surprised Randall didn't write a split-date into his implementation. --Tim P 20:09, 24 May 2008 (UTC)
Update: I've updated Template:30w compliant to allow for implementations to be flagged as partially compliant. I've also updated the Implementations page accordingly to show that the official interactive calculator (which is used by Template:meetup graticule) falls into this category. Hopefully all will be resolved soon. --Tim P 20:25, 24 May 2008 (UTC)
Someone has pointed out that you can subtract 360 from the longitude to get it to show properly. This is fine as a temporary solution, but for backwards compatibility, I think a full implementation should either automatically use the old algorithm before 27-05-08, since that's when this site claims the new rules come into effect, or at least offer a parameter to choose the old algorithm. Nicktaylor 23:33, 24 May 2008 (UTC)
Agreed. --Tim P 02:09, 25 May 2008 (UTC)

I might be wrong, but it seems that there either are, or were, problems with the implementation on http://irc.peeron.com/xkcd/map/ . It seems to me that if I enter a day, for example 22 May, I should get the same result as I used to get on 23 May in the original pre-30W-rule implemntation. However, this is not the case. 145.97.227.131 01:31, 25 May 2008 (UTC)

Firstly, the reference implementation is not backwards-compatible with 30W. That is, it applies the 30W Rule retroactively to all dates, even those before its intended effect on Tuesday, May 27. I've addressed this issue on the Implementations page. Secondly, the 30W Rule does NOT say to use the previous day's coordinates altogether; rather, it says to use the previous day's Dow opening with the current date when hashing the algorithm. As such, locations east of 30W should get a completely different set of coordinates than locations west of 30W for any given day. This isn't viewed as a problem because, with the exception of northeastern Greenland and perhaps some small islands, 30W does not cross anywhere inhabited. --Tim P 01:57, 25 May 2008 (UTC)
Thank you, you are right, I overlooked your second point. 145.97.227.131 02:45, 25 May 2008 (UTC)

Who owns the land?

One of the things that early geocachers quickly learned is that even public land that they thought would be safe to hide a geocache on ("...it's not harming anyone...") was "owned" or cared for by someone. I think geohashing is going to quickly run into a similar problem. You will get your coordinates, everyone will rush out there and maybe you'll even find a public right of way that leads you close. But the times someone ends up on private property chasing their GPS signal or people go off-trail in a public park against posted policies or whatever slight someone takes like if they land in a graveyard and some participants still want to play "games" upon arrival, well, those are the ones that geohashing will be remembered for and the people who follow out there that day are not going to have any idea what kind of hurt feelings or possible repercussions they're about to run into when they arrive.

Just a caveat from a learned geocacher for geohashers to keep in consideration. No means no and even the times when you think you're in the right, you might be doing more harm than good by forcing the issue. Be smart from the time you leave the house to the time you determine you have no right to go any further. 24.218.222.86 01:59, 22 May 2008 (UTC)

I agree with this, to some extent. The point of this idea is adventure, so we sort of want to have weird places to try to get to. But sadly we can't just walk anywhere we want, so some filtering of the locations might be in order. "bad" locations that end up on private land or non-walkable locations might get moved to the nearest accessible point or recalculated with some predictable randomness added to the hash until an acceptable solution is found. This would probably be hard to implement correctly though, and it could be that a super simple solution is best. - forest
You're not thinking globally. No one can pick a proper new location every day for every place in the world. Yes, some days the locations in your area might not work out, that's too bad. Try again tomorrow! Zigdon 06:43, 22 May 2008 (UTC)
Think more pragmatically: How early in the process can you determine that the day's location will "work out"? Is there a way to learn from others' experiences for the day that the site didn't "work out"? What is the impact on the person who owns the land where the hash isn't "working out" when people will just continue to show up unannounced? How can the geohashing/xkcd community avoid a bad rap for following a "wierd internet trend" that leads people to just showing up en masse on a stranger's front yard/street corner/field? Those are a lot of the same questions that geocaching (particularly non-Geocaching(tm) geocaching) has had to deal with. Geocaching(tm) avoids some of this by requiring approval for locations and methods of hiding before being listed for the world to see. Here, the hash is determinable without any central authority or QA. This means there's little control over the actions of the community members...which could mean problems for the community and the activity as a whole that should be given some consideration.
My answer would begin with laying out some guidelines in a high profile place, like this wiki's Main Page, to help shape how new community members may be influenced. Some things may be obvious to certain people who come here to "just have fun" or "go back another day" but you'll find someone who will want to do something like a "10 days in a row Achievement". There will be community members with less self-control who will want to run through someone's property just to "catch'em all" or keep up their streak or whatever have you. Again, these are just some of the issues I have seen in geocaching which may even be more exacerbated by the fact that you don't even need to search or leave something behind to geohash, therefore you're more likely to see less harm from trying to reach your coordinates when they're not legally accessible. I haven't even gotten to the warped problems, like having a group of 4-5 people meeting up in the bushes at a public park, just to get reported because they're less than 30 feet from a group of children playing in a sandbox. Then there's the xkcd twist in that situation...half of the hashers are wearing raptor masks and the other half have swords. 24.218.222.86 18:00, 22 May 2008 (UTC)
I got distracted from your point by your awesome idea at the end... =-)
Um, back to your point. You're right, geohashing has nothing to protect. Geocaching wants to preserve the ability to place things and the expectation of finding them again. Geohashing wants to preserve people showing up randomly. The only way to screw that up is to overregulate it. Not to say we won't individually want to minimise hassles with less lateral thinkers, but don't we deal with that daily?
I think the allure is doing something orthogonal to "normal," and "approved" is a directly conflicting goal.
Now, we like figuring out systems, so you could probably with some success cast a best practices guidelines section as a parameterisation of what property owners/police want to perceive. Taking that idea too far, we could have a cover story where we're all in a book club or something else that can be ignored as "safe." (Everybody arm himself with a copy of A Wrinkle in Time.) On a side note, unless you know some librarians, you might be surprised the things a lot of them do on weekends. —Christian Campbell 18:19, 23 May 2008 (UTC)
How close do you have to get to have achieved a location? The location for me today is ending up in the middle of a field of wheat. Would the nearest field boundary be acceptable? Or the nearest public access point?
Many States and Counties have an online GIS system that allows you to lookup more than just an areal photo of the land, like who owns it, for example. I suggest people look into this before heading for a location to make a more informed decision about whether and how far to proceed. Example in Charlotte, North_Carolina . WokTiny 22:56, 23 May 2008 (UTC)

Split Cities

I have created a Split cities category (temporarily?) for cities such as Chicago and Washington, DC, which don't quite fit squarely into a graticule. It's just a way to categorize them, not a proposed solution to the problem (hell, it's even debatable whether there is a problem). Feedback? Tyler 02:05, 22 May 2008 (UTC)

I think the alternative i've coded up should solve this problem as well. Check it out: Alternative Geohash
In the event of a split city, I think the simplest solution is for people to go to the nearest location. If you live in the north half of a split city, and the point of the day is far north, just try the point in the graticule directly south, where the point is probably within the south urban area of your city. no? WokTiny 15:46, 22 May 2008 (UTC)
No city can possible have it worse that Columbus, Ohio: split into four exactly in the center. Tytrain 01:04, 23 May 2008 (UTC)
In Sydney we've solved this problem by making it officially whichever one is closest to the CBD. If there's any contention, it's xkcd rules - whoever posted first is correct. Gormster 15:35, 23 May 2008 (UTC)
Retrieved from "https://geohashing.site/index.php?title=Talk:Main_Page/Archive_1&oldid=27975"
Powered by MediaWiki