Talk:Main Page/Archive 2

Talk:Main Page Archives

• Archive
• Archive3
• Archive 1
• Archive 2
• Archive 3
• Archive 3/wgh/wgh/wgh/index.php
• wgh/wgh/index.php

See also: Current Discussion

Use of one degree grid sucks

The usage of integer lat/long as the grid for this is really simple but it doesn't perform well. For example, the DC metro area is split into four zones each which contain a small populated area and a large area no one wants to travel to. Alternatively, consider Milwaukee Wi, where there is a 80% chance of the meeting location being in the middle of Lake Michigan, likewise for a number of other coastal cities.

Instead what should be done is someone should search for a tessellation of the world where each tile has the same area as a 1deg/1deg grid but optimized on the following criteria:

• Tiles should not span national borders.
• Where the boundary lines avoid areas of large population
• Tiles should not simultaneously contain large amount of water and non-trivial numbers of people
• Any others?

Once a tessellation is found the hashing could just be an index into each tile. It would be somewhat more complex, and require knowing the tessellation, but it's not like anyone is doing MD5 in their heads.

Perhaps a contest could be held for tessilations? People could compute ones then argue why theirs were the best. ;) --Gmaxwell 22:01, 22 May 2008 (UTC)

People don't want to travel there? I wouldn't be quite so sure about that. Geocaching is rather popular in large foresty areas, and the visited hashes we've seen so far were busy enough even though they were in the middle of nowhere. I actually see your point, but I think that it's not possible to create anything better than this which isn't particularly difficult or annoying to implement. As for the national borders - I'm fairly happy that's not too much of an issue here in Europe ;) Nazgjunk 22:07, 22 May 2008 (UTC)

At least you can expect find something at a geocache. Seems to me that the value of a geohash is meeting the other hashers. When the selected location is often multi-hour drive (due to geographic features and lacking roads) into an unpopulated area it's likely that no one will show. So people will lose interest and be aware of it the few times it is in a good location. With something around 300 geocaches found I think I've only run into other geocachers three or four times or so, and most geocaches are in locations far less random than geohash locations.

I think the people who will spend hours getting to an adverse location will really enjoy the conversations they'll have on the days when they do run into someone. And I think you may be underestimating just how geeky xkcd readers may be -- to me the adverse locations sound most attractive. For those who'll go only when "it is in a good location," there's still the joy of the hangfire of not knowing when that will be until just beforehand. I like the idea of multiple people having determined in their heads to partake in an adventure of unknown complexity, even subject to whatever personal qualifications, where the fruit of the mutual determination doesn't materialise until the adverturers converge on the target. Lastly, I guess geocaching doesn't have any goal of meeting others, and wallclock time is not part of the target, so it doesn't sound surprising you'd rarely run into others? —Christian Campbell 17:27, 23 May 2008 (UTC)

Even when crossing borders is easy, differences in available data might lead to different tessellation rules. I know where to get good population data for the US, but I don't personally know how to get the same data for Mexico.  :)

As far as complexity goes.. geohashing already requires an MD5 .. is indexing into a big table of polygons that much harder?  :) (though the MD5 should be dropped.. if the random seed is random enough, just xoring the digits should be more than random enough...) --Gmaxwell 22:24, 22 May 2008 (UTC)

No one claims the DJIA is very random. But with the MD5, even the slightest change produces a completely new point. That's why I'd argue the MD5 should never be dropped. Zigdon 23:57, 22 May 2008 (UTC)

In Europe, meeting with people from other countries only makes it more fun. Integer grids are good, you can always go to another graticule if it's closer. Nobody says you should take your home's location, you can travel to another location and take the geohash there. --FrederikVds 13:56, 23 May 2008 (UTC)

You're missing the point. See Lowman's post below. Gormster 15:33, 23 May 2008 (UTC)

I don't think so. Maybe you understood me wrong. What part of the point am I missing? --FrederikVds 17:33, 23 May 2008 (UTC)

Saturday's meetingpoint

I was wondering. Is the saturdaymeetingpoint calculated with the date of saturday and the dow opening of friday? Or is the date you use always the date of the dow opening? --Evo-- 13:22, 23 May 2008 (UTC)

My understanding is that you hash in Saturday's date, so that the locations for Fri, Sat & Sun are all different, and are available at 09:30 EDT on Friday. Speaking of which, could someone post the Saturday location? I don't have a hasher. AshleyMorton 13:40, 23 May 2008 (UTC)

Yes, that's right... Current date, most recent DOW opening. Speaking of the hasher/locator, is anyone else having trouble with the peeron one? everytime I hit update it jumps the point around a couple times. I'm at a loss for where I'm supposed to go. --WokTiny 14:06, 23 May 2008 (UTC)

For some reason it adds a few zeros to the Dow Jones every time you click calculate, screwing up the algorithm. StJimmy 14:22, 23 May 2008 (UTC)

I'm not seeing this. Steps to reproduce the problem, or is it fixed? --Xkcd 16:40, 23 May 2008 (UTC)Xkcd

I'm still seeing this. Just go to the page in Internet Explorer and either move the map, zoom, or hit the "Update" button again. The coordinates and the marker will change. The bug doesn't show up in Firefox but it does in IE7, I don't know about other versions of IE.--Ahecht 18:37, 23 May 2008 (UTC)

Cookie/Bookmark?

Is it possible to set one's browser to always start at a certain point when viewing the geohash calculator? The first time I visited it (when I was at home in Berkeley), it started out zoomed to my home graticule. Now that I'm at my parents' (in Los Angeles), it defaults to the Boston graticule. I don't know if this is something to do with our respective internet providers or if something has changed with the mapping program, but it would be great if there were an option to default the map to the current view (whatever that may be). If there's already something that I'm missing, someone can just enlighten me. Thanks!!! Darcy 02:15, 26 May 2008 (UTC)

Yes, that would be useful. Done. Zigdon 06:56, 26 May 2008 (UTC)

Awesome, thank you! Darcy 16:24, 26 May 2008 (UTC)

Using the Dow is a Bad Idea for anyone east of the US

Please consider time zones next time :( - some poor european guy

See 30W Time Zone Rule. There's already been a whole load of discussion about us non-americans, and the final decision was that if you in Europe, Asia, Australia, or just about anywhere that isn't North or South America you use the prior day's Dow. Just means you get a bit more warning that the Americans. --Psud 11:25, 26 May 2008 (UTC)

And the previous discussion: Talk:Main Page/Archive#Europe Time Zones problem --Psud 11:30, 26 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).

Should states be abbreviated or spelled out in the list of graticules on the Region/Graticule pages? Currently is a hodgepodge and the OCD in me is cringing. --KDinCT 20:14, 21 May 2008 (UTC)

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.--h[User:KDinCT|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)

In most cases, though, these are sorted NtoS and then WtoE. In many cases, it would make much more sense to sort WtoE first because we already do that mentally with time zone divisions. --Tim P 22:58, 23 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." --TLP 15:30, 21 May 2008 (UTC)

I noticed that this convention causes the name of the graticule to not match the link. Is that an issue? --Scooter 18:32, 21 May 2008 (UTC)

Yeah I just saw that too, but only in some places. Dublin is linked from the bottom left, Bremen is linked from the bottom right. 9i would think it would be reversed, but it's not...) --TLP 21:38, 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. --TLP 15:52, 21 May 2008 (UTC)

I'd say in your case, for example, the same Philadelphia link should be listed four times (once per graticule) on the Main Page. The target page will explain the multigraticule situation, and maybe any locality-specific ways you handle individuals perhaps using more than one. —Christian Campbell 18:58, 21 May 2008 (UTC)

Yeah that could work maybe. It definitely would for just two graticules, but I wouldn't want to put four of them on one page, especially since the NE one in this case includes Staten Island and lower Manhattan. --TLP 21:40, 21 May 2008 (UTC)

In graticule pages, I suggest using the following template: {{graticule |map=<map lat="37" lon="-122"/> |e=East Bay, California |ne=Sacramento, California }} Zigdon 02:08, 22 May 2008 (UTC)

I suggest that every project undertaken in relation to this wiki should be code-named "The Annexation of Puerto Rico" --Xkcd 21:53, 25 May 2008 (UTC)

This is of course excepting any project that actually involves annexing any part of Puerto Rico. --Xkcd 21:53, 25 May 2008 (UTC)

Automatic land-water filter / other filters

geosplashing; see below for using DJIA==0 as a workaround.
--Pyron Beta 21,25 May 2008

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

Wouldn't it be simpler just to have a standardized method of determining where to go if the geohash is over water? Say, "Follow shortest straight north, east, south, or west line to land and meet at the coast" or something along those lines. -- Curtmack (67.141.84.48 01:44, 22 May 2008 (UTC))

But whats the point of simple when it ruins my fun. Also i think it'd be better to try to keep everyone meeting at the geohashes or as close to as possible. Then we'll get custers of people. More people means more fun :). check out the implementation of this here: [Finding Alternative Geohashes]

Hence the point of a standardized method. Although I agree, it is more fun to try and go over water, but it could be horrendously difficult and downright impossible in some cases (i.e. your geohash is several miles out on water and all you can conceivably rent is a rowboat). Just a thought anyway. Curtmack 00:26, 23 May 2008 (UTC)

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?

Just edit the main page, copy/paste an existing entry, alter it to match your location and save. It should create a link to your page, which should still be blank. Then edit that, (perhaps copy/pasting another graticule's page to keep a semblance of order) and add all you want.

On another note, I'd be willing to reorder the pages for Active Graticules and cut down the bulk, but what criteria should we use for "More" active graticules? Since this has only really hit the interwebs in the last day, there hasn't been time to see which areas are really going to be busiest. Do we create an active graticule page now, removing them all from the front page and then adding more active/interesting ones to the main page as they come up? --Tsen 03:25, 22 May 2008 (UTC)

What about just having categories for "at least 10 users", "at least 50 users", "at least 100 users", "at least 500 users", "at least 1000 users" etc. There seems to be a convention developing of listing user names in each graticule for those who are interested in participating (though this probably doesn't scale well... perhaps an average count of recent Saturday participants instead?). Then as time goes by and they grow, we can just start linking to bigger and bigger category pages to see the most active groups. --Cahlroisse 05:44, 22 May 2008 (UTC)

I would suggest that, after this weekend, a graticule is only listed as active if a meeting has taken place. That is, it has been proven that at least two strangers have actually met on a weekend by geohashing in the graticule.--121.73.94.250 05:55, 24 May 2008 (UTC)

But what if it was inaccessible? --Tim P 20:55, 24 May 2008 (UTC)

Larger Events

If this turns out to be successful, I think it would be nice to group sets of graticules together and have state- or even national-based events (although this may be tricky in nations that cross timezones... maybe we could just have time-zone based events) for special occasions. StJimmy

How are you going to do that when you have no idea where you'll be going or even if it's public property? Gormster 15:38, 23 May 2008 (UTC)

Atom Feed

I noticed yesterday that before the stock exchange data becomes available, the atom feed creates a kind of 'intemediary' geohash using todays date and yesterday's data. This might be intentional, but personally I find that undesirable on weekdays. Could it be modified to show yesterday's date and geohash until data is available? Nicktaylor 14:04, 23 May 2008 (UTC)

I'm currently working on getting an alternative Atom Feed implementation ready for public use (although I think I'm going to wait until the Time Zone issue is resolved). Mine will only update at 09:40 Eastern daily (accounting for DST changes), and uses the irc.peeron.com source for the DJIA, which is updated at 09:35.

I will certainly post it here when it's done, so stay tuned. --Tim P 20:10, 23 May 2008 (UTC)

The time zone issue has been resolved with the 30W Time Zone Rule. I'll continue to work on getting my implementation ready. --Tim P 04:34, 24 May 2008 (UTC)

I don't know if I'll bother with my Atom implementation. I copied your original request at Implementations; I'll keep an eye on it there. --Tim P 05:17, 26 May 2008 (UTC)

Missing Historical Data

There is a good chance that no one cares, but the reference Geohashing Coordinate Calculator will not work for several valid dates. I think some just havent been copied from the previous day, but some may have just been missed. I've put a list of those dates up, delete it if you'd like. --ZorMonkey 14:20, 24 May 2008 (UTC)

FunkyTuba regenerated the data, using a more complete source, so there shouldn't be any more days missing. Do let me know if you find more. Zigdon 08:34, 26 May 2008 (UTC)

Using the Dow is a Bad Idea

If this wasn't including the DJIA, then people would be able to know in advance where these things will be. While that might potentially be thought of as less fun, it will allow for carpooling and other more renewable forms of transportation, and other advantages of advance notice, such as the ability to secure permission from private property owners

Randall, would you please endorse a fork of this which uses DJIA == 0, for those of us who dearly wish to participate but, for example, are surrounded on three sides by water, and anyone else who could benefit from advance notice? Thank you for this fun idea. Pyron Beta 14:21, 25 May 2008 (UTC)

More time to plan and coordinate would be nice in some cases, but I think the surprise of not knowing where you'll be going is key. It wouldn't be as interesting if you could see all meeting points for any day in the future. Maybe a compromise would be to use DJIA from X days ago, giving you X days of planning? --ZorMonkey 17:23, 25 May 2008 (UTC)

A long advance list of meetup locations would result in far more people picking and choosing rare meetups every few months that are most convenient, both (a) removing the regular get-together element that was a major goal, and (b) fragmenting the attendance at any particular meetup greatly in already-sparse graticules. I also, to try to make the system unkillable, built in little advance notice to limit word trickling out to the 'real world' about upcoming meetups. I don't want the police being sent lists of next month's meetups so they can have a patrol car nearby, overly paranoid nearby-property owners making a point to be around, etc. It's our responsibility to act appropriately and avoid trouble, but the short meetup time makes it more likely that we'll fly under the radar. No reason to invite confrontation.

For graticules with a lot of water or other geographic problems, I don't think the advance coordinate list is really what you want. It would just mean a few rare meetups a couple times a year, which is what big conventions already are.

Social circles used to be extremely local, with people only having friends in their hometown. Now they're extremely global, with people seeing friends for giant parties a few times a year. I want a middle ground. So the idea with geohashing is taking these cool internet cultures and giving them a bit of a geographic focus, pulling people from similar geographic areas for regular meetups.

Hence, if geography is a problem, what I'd recommend is that you get together with people in your graticule and come up with a custom solution for your region, then follow that. The official geohashing structure -- which is at this point hopefully set in stone -- is just a starting point. Coordinate generation is a toy for your region to play with. Take this as an excuse to get to know each other, then come up with something that's right for your area. --Xkcd 18:19, 25 May 2008 (UTC)