Talk:Main Page

Putting this at the top so someone else doesn't do it as well, I've made a template Template:Surrounds, for putting in the surrounding graticules. Pretty basic but you get the idea.Gormster 15:52, 21 May 2008 (UTC)

Conventions

You might want to come up with some basic conventions and outline them very clearly, very quickly. This site is going to explode pretty quick, and without any, it will become a mess.

EG:

- Region/Graticule pages named "City Name, Country" where "City Name" is the most major (by population) urban center contained within it.
- Activity pages named "YYYY-MM-DD GRATICULE"
- Graticules referred to by top-left coordinate.
- Hell, create a template for region/graticule pages so they have some semblance of consistency. And some sort of outline on what it should contain
- (Descr of region, image of graticule, Activities Section, Notable Events Section).

Just my $0.02. NuclearDog 10:20, 21 May 2008 (UTC)

I think I like the first options best, makes searching (through Special:Allpages, especially) considerably easier. Working on Eindhoven, Netherlands right now. Also it might not be a bad idea to keep discussions on upcoming meetings to the talk pages. Nazgjunk 14:23, 21 May 2008 (UTC)

I personally just wanted to add that we need to set a convention on how the locations are listed. I personally liked them ordered by latitude and longitude (east to west and north to south) but they appear to be recently edited into alphabetical order. Which I do not think is as 'smart' because they are listed by only one city in the area and someone might accidentally add the area again using a different city. Once the list is long duplicates will be hard to spot.--KDinCT 15:19, 21 May 2008 (UTC)

The list of graticules on the Main Page gets this right, doesn't it? That is, the instructions are there. Execution of those is PEBKAC, of course. Nazgjunk 15:22, 21 May 2008 (UTC)

This has since been fixed back into locational order. --KDinCT 15:32, 21 May 2008 (UTC)

Graticules should be named by their lower right corner since the algorithm adds to the graticule's integer, right? Actually... it would be: (Lower right in NW Hemi, Lower left in NE Hemi, Upper right in SW Hemi, Upper left in SE Hemi.) That seems a lot for a convention, but all you have to say is "graticules are areas with the same integer coordinates." --Apocalypsepony 15:30, 21 May 2008 (UTC)

What should the convention be when a main city is split (ex. 61, -149(or -150) (Anchorage, Alaska) and 41, -96 West of 56th St; 41, -95 East of 56th St. (Omaha, NE))? My view is that these areas should be seperated and one will get visited sometimes and the other will get visited other times.--KDinCT 15:32, 21 May 2008 (UTC)

What if in a case like that, you have a city page that links to the individual graticule pages in the area? For now, you'd still leave the graticule pages on the main page. I'm thinking over this problem too for Philadelphia -- the city is basically on top of (40, -75) so there's 4 graticules in the area, only one of which I've named Philadelphia. --Apocalypsepony 15:52, 21 May 2008 (UTC)

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

Europe Time Zones problem

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

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

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

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.

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

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?

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.

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

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

• 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).

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)

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

Python-CGI-JSON-o-Rama implementation

Hey so i've made a python version of the reference implementation that returns a JSON parseable object containing the lat/long when given a date, xloc and yloc. It uses the XKCD cache of dow values. I'll put it online in the next 5 mins :D

Here it is, fairly simple actually, hope someone finds it useful :)

Update

I've tried to make it classify the region recommended for a particular day using the euclidian distance of the colour of the image provided by Google Maps

The code is on the link above, tell me what you think :)

SinJax

Cool! I was thinking of making it act as a web service, but for reference implementation it's more important to be simple than useful :) Zigdon 14:53, 21 May 2008 (UTC)

I mostly canabolised yours anyways! :) But yeh here you go. The webservice version returning AJAX from python can be found: - AJAX geohashing - Example using the web service

The implementation also has the ability to tell you whether the particular area is water, park/forest or other. It does this by checking the colour on google maps and doing a thresholded euclidian distance check against the expected colours for those things. Also If its water it tells you its probably not accessible I wanna try to add more features like this, things like rating locations based on food and letting you say how far your willing to travel

Thanks to User:Sigmund Fraud from the IRC channel for the space on his server with python installed - SinJax

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)

Automatic land-water filter / other filters

geosplashing
Pyron Beta 12:42, 21 May 2008 (UTC)

Does anyone know of open-source data for determining whether a coordinate lies on land or water? This would be an interesting feature in a calculator which tries to automate this a bit so one does not have to manually check against a geohash calculator every day.

E.g:

• every morning, calculate the days geohash
• apply filters:
  • is coordinate on land?
  • is coordinate not in known list of bad regions (area 51, etc.)
  • other personal filters, e.g. is coordinate < n miles from home
• if pass all filters, notify of coordinate, provide image of (or link to) map

--Recursive 11:15, 21 May 2008 (UTC)

Hmm. Seems like http://www.openstreetmap.org/ found this data somewhere, so presumably it's only a matter of digging up that separate dataset and parsing it. Here's another mess of links: http://opensourcegis.org/

OSM has some form of land detection, but it's a little crude. The readme in [1] should provide the details required. -- Edgemaster

(of course, this isnt the exact data in the OSM database, but a highly simplified version) If you want to go to the trouble of parsing all of the coastline shapefiles, they're here: [2]

And a third edit to say that we use this datasource.

Of course, having the data is not necessary, merely being able to query a web service for whether a coordinate is land is sufficient. The crudest approach would be to graphically scrape google maps, but, that's kind of lame. --Recursive 11:24, 21 May 2008 (UTC)

So i'll assume by kinda lame you meant awesome and i went ahead and implemented that, here it is: Enjoy

Active Graticules

Can it be done to automatically sort the active graticule list? --Psud 11:49, 21 May 2008 (UTC)

be useful if people started catergorizing their pages too --Ryan the leach 12:34, 21 May 2008 (UTC)

What if we redo the active graticules entirely? Better soon than later. Create a "Active Graticules" page with lists of all graticules, and then only list the most active graticules on the main page? --Tsen 13:53, 21 May 2008 (UTC)

Agreed. There should be a page of ALL graticules and then once it has had more than 5 visits (or some other arbitrary number) it can be moved to the 'active graticules' list on the main page. --KDinCT 14:10, 21 May 2008 (UTC)

How can we add new Graticules? I live in South Africa and Geocaching itself is a becoming a big deal. Can we add an African region? More specifically a South Africa; and then Johannesburg?

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.

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)

---

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.

Small Islands / Countries

One problem with this are small countries such as Malta ([3]). 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

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)

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)

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 below zero 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

bug in reference implementation

The reference implementation is biased against results in the .0..., .0... range. This seems to be because the code that converts a hash string to a fraction stops dividing as soon as the remaining characters are all false (zeros.) This division should probably happen a fixed number of times, instead. 76.121.107.210 17:26, 21 May 2008 (UTC)

Good catch, fixed Zigdon 18:18, 21 May 2008 (UTC)

Negative coordinates and adding versus appending

There's possibility for confusion with regard to graticule coordinates. For example, the larger NYC graticule's longitude ranges from -73 to -74. If, like it seems in the comic, you're supposed to append the random <1 number to the coordinate, then NYC's graticule should be listed as 40, -73 (since every point within the graticule has longitude -73.xxxxx). If, however, you're supposed to add the random <1 number to the graticule, then NYC's graticule should be listed as 40, -74 (since the random number is always positive, this will always lead to a -73.xxxxxx number unless the random number is zero). I therefore recommend changing the algorithm to specify adding the random number, not appending it.

As a side note, the implementation of the algorithm linked to from the comic reflects this confusion. If the link includes zoom parameters, it gives the coordinates of the NYC graticule as 40, -74: http://irc.peeron.com/xkcd/map/map.html?lat=40&long=-74&zoom=8&abs=1 However, if the link does not include zoom parameters, the longitude has to be changed to -73 to give the same graticule: http://irc.peeron.com/xkcd/map/map.html?lat=40&long=-73