Difference between revisions of "Talk:Main Page/Archive 2"

From Geohashing
imported>Joannac
m (Protected "Talk:Main Page/Archive 2": Excessive spamming ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite)))
imported>Jiml
m (Fix typos)
 
Line 237: Line 237:
 
== Flickr (and other photo service) standard tags ==
 
== Flickr (and other photo service) standard tags ==
  
I propose that we agree on a standard tagging system for identifying geohashing pictures on the various services. It would be fun to be able to quickly cull pictures from a certain day or graticle, and agreeing on tagging now means that we'll be able to automate such a search process later if someone has a particularly cunning plan.
+
I propose that we agree on a standard tagging system for identifying geohashing pictures on the various services. It would be fun to be able to quickly cull pictures from a certain day or graticule, and agreeing on tagging now means that we'll be able to automate such a search process later if someone has a particularly cunning plan.
  
 
A good system then would:
 
A good system then would:
 
* keep track of day and graticule separately (for separate searching)
 
* keep track of day and graticule separately (for separate searching)
* indicate a standard tag for *all* geohashing pictures, regardless of day or graticle
+
* indicate a standard tag for *all* geohashing pictures, regardless of day or graticule
 
* be deterministic and consistent
 
* be deterministic and consistent
 
* be strictly alphanumeric (flickr strips all other characters and spaces when comparing)
 
* be strictly alphanumeric (flickr strips all other characters and spaces when comparing)

Latest revision as of 19:08, 2 May 2010

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)

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)
If they met while trying to reach it, it's active. If no one has ever met up because the hashes have always been inaccessible so no one has tried, then it's inactive. Robyn 20:18, 20 July 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)

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)

What happens....

...if the dow falls below 7 characters? Shadow 16:32, 26 May 2008 (UTC)

Firstly, Dow values are currently usually 8 characters. Secondly, the Dow is always appended to the date string as a regular number with two digits after the decimal point. No zero-padding, no commas, no nothing. Just a straight number, e.g., 1988-01-04-1950.76 or 1982-04-04-833.24. --Tim P 17:01, 26 May 2008 (UTC)

Coordinates good until new ones?

What is the convention for reaching a coordinate the next day before new coordinates are available? I wasn't able to get to today's hash but could do so tomorrow before the Dow opens. Does this still "count"? Tytrain 22:20, 26 May 2008 (UTC)

I think that's a reasonable interpretation... there aren't any "rules," per se... If you do go and make an expedition page for it here, though, you might want to mention that you went on a day other than what was used for the algorithm. --Tim P 03:13, 27 May 2008 (UTC)
Agree. This is pretty anarchic. Do what you want and then tell us about it (and blame the W30 change if anyone complains)! --Psud 12:43, 27 May 2008 (UTC)
Thanks for the input. I live in the Eastern Time Zone (GMT -5), actually, and stopped by the hash at 6:15 AM this morning. Yikes. It was on private property so I only did a driveby. I'll make a page for it and mention the details. Also, no pictures - I was too sleepy to find the camera in the morning, and was on my way to work. Hopefully my next hash will be more lively. Tytrain 21:53, 27 May 2008 (UTC)

Making new graticules

how would one go about making a new graticule? specifically one for the area around prescott, arizona. the problem that i found was that the nearest whole coordinate point was nearly a hundred miles away, just north of phoenix. halp! (if i put this in the wrong spot, feel free to move it to the right one) Psychomusician 06:55, 28 May 2008 (UTC)

(I threw this onto your user talk page, too, but I thought you might see this first.) It's not tough to make a new Graticule site. First, I would go to one that already exists, and you like, and "edit" their page - just so that you can copy-and-paste their code, don't actually save anything yet. Then, go to the "Active Graticules" page, and edit it, putting your new one in the right place in the list, and in the same format as all the others. When you save that, your new one will show up as a red link. When you click on it, it will give you a text entry box for creating your new page. Paste your copied material in there, edit it to make it specific to your home, and save! Have fun, and feel free to ask me (or any of a thousand other people, I'm sure!) any questions like this. Cheers! AshleyMorton 07:02, 28 May 2008 (UTC)

Data errors on 2008-05-30 on irc.peeron.com (resolved)

Okay, the Main Page lists the co-ordinates for 31 May 2008 as:

West of -30°: 0.0374870832648067, 0.2812664767643918 East of -30°: 0.0374870832648067, 0.2812664767643918

However, the irc.peeron.com/xkcd/map/ for my graticule [3] shows co-ordinates of 0.702114 and 0.838062. What's going on? AshleyMorton 14:06, 30 May 2008 (UTC)

The data the map uses is wrong. It's using the DJIA from yesterday, I think. I just noticed that the opening values from today and yesterday were exactly the same and came here to see if anyone noticed any funny business. :) --ZorMonkey 14:15, 30 May 2008 (UTC)
  • Direct future discussion on this topic to Template talk:Expeditions/2008-05-31.
    • This has been corrected. --Tim P 19:12, 30 May 2008 (UTC)
      • And code has been updated to avoid this kind of thing from happening in the future. Zigdon 20:34, 30 May 2008 (UTC)

Issue with the map

When I type the date 2008-06-01 into the map, I get the error "Market data is not available for 2008-06-30" However, I can type in 2008-05-32 and also 2008-05-33 and get coordinates. The 34th gives me "Market data is not available for 2008-06-02" (I'm looking at places east of -30°, by the way). Loggie 22:37, 30 May 2008 (UTC)

I get the same problem. BTW the coordinates returned for 2008-05-32 are *not* the correct coordinates for 2008-06-01, since it uses wrong date (2008-05-32) in the hash. Not sure if you realize this or are just pointing out more data -- at first I thought you had found a tricky workaround :)
Another observation, the page is also looking for DJI data on 2008-07-01, when I type in 2008-06-02, this is rather odd. --124.168.225.106 02:42, 31 May 2008 (UTC)
Arrow4.png Please direct all further discussion on this topic to Talk:Implementations#Wrong_market_data_for_June_2008_in_locations_east_of_-30.C2.B0.

Tim P 05:40, 31 May 2008 (UTC)

UPDATE: Fixed. --Tim P 02:48, 1 June 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 the 'abs' parameter, it gives the coordinates of the NYC graticule as 40, -74: http://irc.peeron.com/xkcd/map/map.html?lat=40&long=-74&abs=1 However, if the link does not include 'abs' parameter, 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

The map always marks the northwestern edge of the graticule - otherwise, it'd have to add a parameter for N/S and E/W. So when given the 'abs' argument, it takes your coordinates as the northwestern corner, and without it they're parsed as what the comic presents them as. Perhaps this should be made more explicit though. Zigdon 18:22, 21 May 2008 (UTC)
This absolutely needs to be made more explicit. --Tim P 23:44, 24 May 2008 (UTC)
Most of graticules are already referered using the -0 convention (except few ones in United Kingdom). Again, the whole problem has been sum-up (including reference implementation change) in page -0 Issue. And yes, it should be made explicit. --Gissehel 13:54, 25 May 2008 (UTC)

Achievements

I made an Achievements page to list some extra challenges that can be achieved so people can brag about some of the harder places they've gotten to (eg, i've got a Water GeoHash achievement when me and a friend hired a boat and went to the location on water). I thought of a few, but needless to say there are quite a few possibilities. zorg

So, I discovered I can see the point from my backyard. Is there an award for that? 2008-05-24 40 -111 McKay 18:27, 24 May 2008 (UTC)
I think that gets the Superbly Lazy Couch Potato Achievement. Darcy 01:56, 26 May 2008 (UTC)
I shouldn't think so. Just because he can see the spot from his backyard doesn't mean it's in his backyard. --Tim P 03:50, 26 May 2008 (UTC)
hahaha thats just unlucky really, so close but so far. --Zorg 04:03, 26 May 2008 (UTC)
How many points can you reach (in different graticules) in one day? Would require some luck, but it would be an awesome achievement / high score page. Or a different variation- choose a time frame (say a week 1 year ago) and visit all of the points from that time frame in as short a time period as possible. Thoughts? 70.162.29.88 22:58, 24 May 2008 (UTC)
Since there's a Twister achievement, don't you think there should be a tape measure achievement too? thepiguy

Facebook

It was inevitable, because I am a Facebook whore: Geohashing on Facebook I might start work on an app after I finish my current one. Gormster 12:51, 22 May 2008 (UTC)

There are also some local groups. So far, I know of: Geohash - Toronto, IVSLO Geohashers (Southern Cal somewhere?), and Geohash - Denver (which I created, for the record). --Doubt 21:00, 22 May 2008 (UTC)
I've also created Oklahoma City Geohashers. Trvsdrlng 19:51, 24 May 2008 (UTC)
I have added the Cincinnati Area Geohashers group. Scottkuma 19:34, 30 May 2008 (UTC)
I created a group for Lubbock Geohashers. elxverde 01:03, 31 May 2008 (UTC)

There is a page to keep track of facebook groups: Facebook groups. Zigdon 07:34, 31 May 2008 (UTC)

Flickr (and other photo service) standard tags

I propose that we agree on a standard tagging system for identifying geohashing pictures on the various services. It would be fun to be able to quickly cull pictures from a certain day or graticule, and agreeing on tagging now means that we'll be able to automate such a search process later if someone has a particularly cunning plan.

A good system then would:

  • keep track of day and graticule separately (for separate searching)
  • indicate a standard tag for *all* geohashing pictures, regardless of day or graticule
  • be deterministic and consistent
  • be strictly alphanumeric (flickr strips all other characters and spaces when comparing)
  • include something geohash-specific to keep non-geohashing noise out

Therefore, I suggest the following:

  • All geohashing photos: geohashing
  • Graticule tag: geohashing(N|S)##(E|W)###
  • Date tag: geohashingYYYYMMDD
  • Eg: This photo would get "geohashing", "geohashingN35W120", "geohashing20080524"


Thoughts, reactions, counter-proposals? --Psthomas 07:49, 27 May 2008 (UTC)

Sounds good to me. --Psud 12:45, 27 May 2008 (UTC)
It should perhaps be added that (lat,lon) should not be zero-padded (i.e., geohashingN51W1, not geohashingN51W001), but that dates should be zero-padded (i.e., geohashing20080601, not geohashing200861). Just my 2¢. --Tim P 03:03, 31 May 2008 (UTC)
Good catch; thanks Tim. I agree. Think other people will actually do this? --98.207.21.65 23:59, 31 May 2008 (UTC)
I sure hope so. Seeing pictures of complete strangers gathering at random places is always fun... --Tim P 23:05, 2 June 2008 (UTC)

Expedition archives

Is it possible to have a version of the expedition archives box at the top of each hash with options to go to the previous, current, and next geohash just for that graticule? Tytrain 23:11, 28 May 2008 (UTC)

Depends. Do you want to go through every possible date, or just selected ones (picking and choosing the ones that people actually went to)? One case is far easier than the other, and it's the one I used while making both Template:Date nav and Template:Expedition archive nav. --Tim P 07:12, 29 May 2008 (UTC)

Possible Dangers of Geohashing

One problem I can see with geohashing is that in certain parts of the country, if the coordinates fall on someone's private property, you may be taking a risk of being shot on sight for trespassing. I believe that in some states, it might even be legal for landowners to do this, at least if they have warning signs posted on their property - although as an explorer, you can't necessarily depend on reliably being able to see the warning signs. Therefore, I would strongly advise all prospective geohashers to check their county's GIS for the land ownership records for their destination (and any properties that must be traversed to get there), and contact the landowner(s) and get permission to visit their property before heading out. --mpf

Hey, any ideas for...

archiving a "Hey, we want to trespass on your property!" flyer. Something like: the person who's handing this flyer to you is absolving you of any liabilities in exchange for peaceful and litter-free incursion into your property for the purpose of the Internet", with a drag 'n' drop 'n' print feel to it. Don't have the editing chops to create this yself, but thought it could be handy for explaining to those not fortunate enough to realize that they could've earned a Couch Potato Achievement! Patrick from 41, -71

Spam

Seems we're being hit by spam bots at the moment. Any way to prevent this? --Bobbert 11:48, 2 June 2008 (UTC)

Also people, please use undo to remove spam, as just removing the spam leads to things getting lost as the spam bots also delete some content. --Bobbert 13:09, 2 June 2008 (UTC)
I've put an advisory (Template:Spammed) on the main page (in a place the spambot has yet to replace) alerting people to this fact, and so far the reverts have been done properly. --Tim P 22:31, 2 June 2008 (UTC)

Any chance we could see 89.149.197.252 banned, since that seems to be the IP address of the spammer? --Tapin 23:48, 2 June 2008 (UTC)

Seconded. mediawiki IP blocking should be fine unless we get dist-spammed. (doesn't seem to be the case so far, just a couple of addresses. A week-long block can be put in and should be sufficient IMHO).
On this line of thought however, as the wiki grows it's likely to need extra sysops to manage such tasks. I hope that is being looked into? --Nemo 05:24, 3 June 2008 (UTC)
89.149.197.252 was just put under a one-week block, and the Main Page may now only be edited by logged in users. See Talk:Main Page#Note_from_Randall. --Tim P 14:56, 3 June 2008 (UTC)

Recent and upcoming expeditions -- move?

The Recent & Upcoming Expeditions section is very cool. It's also very big, and sort of detracts from the main page, which I think should be more of a "kicking off" point. Should we move R&UE to its own page, and put a link under Active Graticules?

I see that R&UE is slated for automatic updates (it's already heavily templated.) It would be good to do this change before the 'bot is coded, to save on his maintainer. Ted 21:35, 2 June 2008 (UTC)

Actually, with what I had in mind, it wouldn't matter if this section was moved before or after I automate. Don't let that stop you. I do think, however, that there should be some inclusion of current activities on the Main Page, though I agree that the current amount is a bit much. I'd like to hear others' thoughts before I share my own as to what the overall structure of these pages should look like. --Tim P 23:03, 2 June 2008 (UTC)
I think for the moment, maybe reduce it to the last couple of days (which should allow all timezones a chance to be updated after their hash and get a little bit of time on the front page), rather than keeping a whole week. That would clear things substantially without being a conceptual change. In the long run, perhaps some kind of 'featured expiditions' might be worthwhile - they could be linked on the frontpage and so would encourage higher quality photos and writeups - and give people ideas of what the most inventive groups out there are doing... --Nemo 23:46, 2 June 2008 (UTC)
So, would five days perhaps be better? Because after Friday morning's Dow open, you have new coordinates for Friday (west), Saturday, Sunday, and Monday (east)... so you'd probably want to keep Thursday on there to have something to work with. Thoughts? --Tim P 00:26, 3 June 2008 (UTC)
That makes sense to me... maybe as "the last 3 DOW openings" - though that alters the number of days in view depending on weekend proximity... pro: weekends get a bit more time on the front page. con: weekends are the BIG days which are filling the space and causing this issue in the first place. :/ --Nemo 00:36, 3 June 2008 (UTC)

Perhaps we could show the current two days as well as a Saturday? Such as:

Time of Week (US Eastern) Dates known (non-30W) Dates known (30W) Dates to show
Mon 09:30 - Tue 09:29 through Monday through Tuesday previous Saturday; Monday, Tuesday
Tue 09:30 - Wed 09:29 through Tuesday through Wednesday previous Saturday; Tuesday, Wednesday
Wed 09:30 - Thu 09:29 through Wednesday through Thursday previous Saturday; Wednesday, Thursday
Thu 09:30 - Fri 09:29 through Thursday through Friday previous Saturday; Thursday, Friday
Fri 09:30 - Mon 09:29 through Sunday through Monday Friday through Monday

Dow holidays could be programmatic exceptions. Just a thought. --Tim P 01:36, 3 June 2008 (UTC)


Alternatively, if the MediaWiki Implementation ever gets installed on this wiki, we could just show the coordinates for the last five or six days on Main Page, and have them link to the corresponding date pages. To be honest, I like this alternative better: it's cleaner and easier to program with templates (seeing as I'm probably going to end up doing it). Plus, people who just want coordinates can get them without paging through. Thoughts? --Tim P 01:39, 3 June 2008 (UTC)

So... I think that could be done now, albiet with manual updating of page, right? ie, a list of the last 8 days of coordinates, with links out to the list-of-geohashes which have been added in. It's the lists which are the space killer. Without those, a week (8 days as per original logic (I assume) to always have a complete saturday on the list), seems entirely sane. I'd even put in a just-thought-of argument that it should be done using the existing templates, with something like {{Expeditions|2008-06-03|nolist}} - the header with coords and 'add your expidition' gets in, but the list of them all doesn't. Does template programming allow for that flexibility? --Nemo 01:53, 3 June 2008 (UTC)
I could certainly do something like that in the near future, if I hear no objections (let's say by 00:00 UTC, 4 June). The way it's set up now, the {{Expeditions|2008-06-03}} simply calls up and includes Template:Expeditions/2008-06-03 in its entirety and adds the appropriate subheading and "add your expedition" link. See Template:Expeditions for how that works. If you look at 2008-06, you'll see that if such a page doesn't exist, it prompts you to make one.
Although it would certainly be more desirable to have the MediaWiki Implementation take care of coordinate calculation directly, for the time being, I could create another template just for the coordinates, and then include those on the resepective "expedition date" templates. That way, the main page would have just the coordinates and links to the "expedition date" templates where people will add stuff. Objections? Further musings? --Tim P 01:57, 3 June 2008 (UTC)
P.S.: Yes, the original logic in having 8 days was to always have a Saturday showing. But so long as we have prominent links, it shouldn't be an issue. --Tim P 01:59, 3 June 2008 (UTC)
Looks good to me. I'd be tempted to suggest waiting for the mediawiki implementation to go in rather than make alot of changes just to re-change them later. I've no further brainwaves or objections... I'll bow out for a bit and let others comment. (incidentally, as of now I'm about 6 hours away from possible IRC real-time-like speedier discussion :)--Nemo 02:03, 3 June 2008 (UTC)
I'll try to keep an eye on IRC from 14:00-15:30 and 20:00-03:00 UTC on 3-4 June, if you want to discuss this. Otherwise, I really hope the MW implementation is installed soon. --Tim P 05:40, 3 June 2008 (UTC)
I agree that something has to be done, we need to analyze the purpose that it is serving, if someone is looking at it they might a)want to know timing, dow openings, days, holidays etc or b)their specific graticule coords most people probably don't care enough about other meet ups to justify it being on the main page, maybe a link to a secondary page of "Recent Meet ups" or something similar and as for this section make it serve as a jumping off point for daily geohashing (maybe a link ot the calculator who knows).--Ishboo 19:59, 3 June 2008 (UTC)

OKAY, it looks like I'll start working on something for the interim while we're waiting for the MediaWiki Implementation... something that can easily be converted to use the MWI once it's done. I'll post updates here and keep looking for other users' thoughts. --Tim P 20:47, 3 June 2008 (UTC)

I just had a thought - mediawiki supports hidden text (table of contents is the common example). Wikitables support this. Could the list of hashvisits on each Expidition subpage be put in hidden text. That keeps the current layout, shortens the front page, but shows the data instantly when it is called for --Nemo 23:25, 3 June 2008 (UTC)
Sorry, Nemo... I don't think this is installed by default. --Tim P 00:08, 4 June 2008 (UTC)
Yeah, fair enough too. I also didn't notice the 'don't use this' policy on wikipedia regarding hidden text until *after* I posted the idea here. --Nemo 02:28, 5 June 2008 (UTC)
Well, of course, it's the weekend days that provide all the big bulk, with them being the common meetup days. I vote for having the R&UE section only display the link to the day's adventures. All of the individual expedition links are duplicated on the page for that day, anyway. Or maybe it can look something like this:
[link: Thursday 5 June 2008] (No expeditions, yet)
[link: Wednesday 4 June 2008] (4 expeditions)
[etc] Tuesday 3 June 2008 (8 expeditions)
Monday 2 June 2008 (7 expeditions)
Sunday 1 June 2008 (23 expeditions)
Saturday 31 May 2008 (47 expeditions)
Friday 30 May 2008 (14 expeditions)
[etc]

Proposed Consolidation

PROPOSED: Something along the lines of the following, spruced up a bit to make it easier to read:

Date West of -30° East of -30°
Thursday 5 June 2008 Announced 13:30 UTC, 5 June. 0.3023171947630265, 0.4839450359119979
Wednesday 4 June 2008 0.18029229786871545, 0.8450323290648286 0.7008177097112361, 0.704888801316744
Tuesday 3 June 2008 0.9579926703969455, 0.12893491871843724 0.7427834473658905, 0.6356494013762755
Monday 2 June 2008 0.5095264463869317, 0.5215911826227673 0.3859189793932023, 0.0292893119354716
Sunday 1 June 2008 0.3491079341188037, 0.9162389042702137
Saturday 31 May 2008 0.0374870832648067, 0.2812664767643918
Friday 30 May 2008 0.8531025811716042, 0.2446021959360299 0.3227205387098275, 0.7045834347042035
Thursday 29 May 2008 0.4647015535871903, 0.0341244048140951 0.2783266160961512, 0.7411420442829273

This way the coordinates are still on the homepage. Let me know what you guys think. --Tim P 02:40, 5 June 2008 (UTC)

Also, the links could just go directly to pages of the form Template:Expeditions/2008-06-04 if there's such a mandate. I wish there were an easy way to include pages of just the form 2008-06-04 onto Expedition Archives pages... --Tim P 02:43, 5 June 2008 (UTC)
Nice, Tim -- you've got my vote! /me resists the temptation to bikeshed this one to death :) Ted 02:55, 5 June 2008 (UTC)
I very much like the look and simplicity of this as well. My only comment is that in the longer run, I'd like to see some rollover of hashvisit images on the front page (as mentioned in another thread above). The table seems to preclude easily including images from recent hashes alongside the rolling links of each day. That caveat aside, I would still say to go with this - it shortens the page wonderfully and images and the prettyfying can be looked at later. :) --Nemo 03:42, 5 June 2008 (UTC)
Perhaps whatever image-featuring system gets going could be included below this? Couldn't the dates for the images just be included in their captions, rather than tying that into this table? I honestly think these can/should be two separate things, for simplicity's sake, and everyone's sanity. --Tim P 04:13, 5 June 2008 (UTC)
yup on all counts. See new section below :) --Nemo 04:14, 5 June 2008 (UTC)

I've heard a lot of positives. If I hear no objections, I'll implement this on the main page once Thursday's Dow is announced at 13:30 UTC today, and I'll work on beautification immediately thereafter. Half the battle is the fact that the current system makes the table of contents huge, too. This will eliminate that. Long-term goal will obviously be automation, but that relies on the MediaWiki Implementation coming through, as well as me having a couple hours of free time one day... Leave me thoughts to wake up to at 12:45 UTC; bed for now... --Tim P 04:25, 5 June 2008 (UTC)

This has now been implemented on Main Page. --Tim P 13:43, 5 June 2008 (UTC)
It's very nice and all, but there seems to be a bug now; edits applied to the day pages (today's, for instance) don't seem to stick. That is, edits made to the template page does not show up on the actual page. Someone knowledgeable about wikis should probably deal with this.
Do they never show up at all? Or just not immediately? Mediawiki caches pages the templates interpreted in. When a template changes, it has to update all the pages which include that template - and it doesn't happen automatically. Those updates get queued up into a job queue, and then on every wiki page load, an item from the queue gets run.
I hope that helps :) --Nemo 23:42, 5 June 2008 (UTC)

Graticule Archiving

In a related need, having a slightly modified but just as useful table of the upcoming few and previous few links for a single graticule page would be nice. For example, the Boston page has every date since inception listed in a growing list of links for each day's specific page and a small description of the location (some visited, some not). It'd be nice if this was reduced to the next day's link and the last like 4 other links (5 total) and a link below that to an archive of the previous pages for that graticule. An automated template that does this would be awesome. Ju66l3r 07:53, 10 June 2008 (UTC)

recent geohashvisit images

This is my first-draft proposal for per-day gallery of best-images for the front page. Each day would have it's own gallery for easy rollover, and images are likely to be about 3k each - so limiting to the gallery tag default row of 4 per day seems sensible. Weekends get perhaps 3 rows? I'm guessing admittedly, might well depend on how many good pictures come up.

Issues I can think of...

  • What are the "good" images to include? (For this sample, I just grabbed the best image (IMHO) from a couple of the visits from the given day. What makes the cut is a matter of community consensus... who is willing to make the edits and be fair about it :)
  • editwars - deal with as they occur? :)
  • order of images - best to worst seems too subjective. west to east (from 30W) is a bias towards Australasia (me!) and against the Americas. Does it matter?

--Nemo 03:58, 5 June 2008 (UTC)

With respect to order: I'd say either randomize it, or just do it in the order added. --Tim P 04:16, 5 June 2008 (UTC)
As I think about it, reverse order added (ie, add newest at the top) makes most sense to me. Everyone gets to be "first" for a bit, with poor images weeded out over time :) Once the long listings are removed, we can tackle this (I'm itchy to put images up, but better wait a bit longer eh? :) --Nemo 04:33, 5 June 2008 (UTC)
Just to continue my work on this so far, I've started a new template so that each days best images can be not only included to the main page without huge globs of code, but that they can be archived nicely (and maybe included with other pages for the day as a permanent record :)
I've added in three days (fri/sat/sun) worth of galleries to the Main_Page now. It's a danger of being overload with much more - so I'm thinking that perhaps 3 days images is sufficient for the rolling gallery. On that light, galleries for newer days still need to be made. Any other comments on this? (the discussion page here has been pretty quiet the last day, thus I went ahead to the front page. More likely to get reactions that way ;) --Nemo 01:16, 6 June 2008 (UTC)

Could there be a voting system (like LOLcats or slashdot) so that people could browse through the photos and vote up the good ones, then the system automatically put the favourites on the front page?

Sadly, unsigned commenter, there isn't much support for such methods on MediaWiki. Someone inventive might be able to figure out some method, but I wouldn't hold out too much hope. --Tim P 16:17, 7 June 2008 (UTC)

not bushland

that canberra shot on the front page is not bushland. from the looks of it, it is the remains of what was a pine plantation. Pine trees don't grow naturally in oz.

it's bushland by local terminology though - ie, anything that isn't urbanised. It's very much a pine plantation - which was burnt rather stunningly several years ago. But no, I never claimed it was *native* bushland --Nemo 14:33, 5 June 2008 (UTC)
Well, when we added the photo galleries to Main Page, this picture got removed. No longer an issue in any case. --Tim P 16:22, 7 June 2008 (UTC)

Random Expedition

I'd like to have a "show random expedition"-button - just like Special:Random. --Hermann 19:56, 6 June 2008 (UTC)

This would probably require fairly strict standards on page categorisation that would be hard to do. Logic tells me that there should be more expedition pages than date pages, say... so although Special:Random might be as good as we can feasibly get (at least in the short-term), it might also be as good as you could reasonably need. --Tim P 16:25, 7 June 2008 (UTC)

FAQ -- More questions

Hi!

I would have added my question directly to the page, but can't edit it.

Q: Is it okay to visit a geohash location in a neighbouring graticule instead of the "own" one?

A: ???

kR --84.119.35.161 22:43, 7 June 2008 (UTC)

A: Sure! There's no rule saying you can't visit other graticules, and in some cases (for example, San Francisco), you would almost have to in order to actually access a hashpoint. Geohashing is about meeting other people, and it doesn't matter whether you do that here or there. In fact, finding a new mix of people might be a good thing. Go ahead and geohash on vacation for all we care!
I hope this answer is satisfactory. I'll add it to Main Page shortly. By the way, 84.119.35.161, due to recent spam attacks, only registered users can edit Main Page. So register and join us!!! --Tim P 01:23, 8 June 2008 (UTC)

Note from Randall

I'm currently adding a few admins and blocking IPs to deal with spam.

One thing that I think should be added is more indexing of interesting pictures, especially on the front page. I think a set of rolling "best geohashing picture of the day/weekend" that's prominently displayed that anyone can set to anything would be really good for the project. There are a lot of images on a lot of disparate meetup pages which aren't too well-indexed or easy to browse through, and we want to show everyone examples of geohashing's success.

Looking forward to Saturday's meteup, and any points I make it to before then!--Xkcd admin 14:49, 3 June 2008 (UTC)

Rolling pictures would be awesome. For the time being I've thrown a couple of cool pictures to the Main_Page manually, with the thought/aim that myself or someone else will roll something else over them as found. A 'featured picture' per day? How do choose said picture in a fair and timely manner however? Once the current Main_Page bulk of hash locations is reduced (see elsewhere on this Talk: page), I think it will be easier to re-layout for image friendlyness. --Nemo 00:10, 4 June 2008 (UTC)
Once the bulk of the page is removed in the massive listings of visited hashes, I think a few photos per day (say, 4 on weekdays, and maybe 12 for each sat and sunday) can be added to the front page. I was about to edit this in myself (using gallery tag) right now, but the increase in size to the front page (in visual size moreso than bytesize - each thumb in a gallery contributes only 2-4kb in size) made me wary.
regarding bytesize: At 4kb per thumb, 4 per weekday is 16k per day - 80kb to the download. Plus 96kb for the weekend. So 176kb is my worst-case scenario for page size increase. Comments anyone? --Nemo 02:26, 5 June 2008 (UTC)
Arrow4.png Please direct all further discussion on this topic to Talk:Main_Page#recent_geohashvisit_images.

Radio Frequency Standard

How about coming up with a frequency standard that we can use with two-way radios? Then anyone in the vicinity can announce their arrival and meet with the others nearby. --waq

Agreed. This way, nobody should feel the need that they have to trespass. Obviously, in any case, you'll still have people who will try, but at least you can mitigate the possibility.
Only potential problem is for the non-Saturdays, who's to say when anyone will show up? 16:00 local time is only the standard for Saturdays. On a Monday, someone could go at 12:00, announce his (near) arrival via radio, and no one would answer. That wouldn't stop anyone from trespassing alone at 20:00. --Tim P 19:17, 23 May 2008 (UTC)
BTW, I suggest FRS Channel 6, if for no other reason than the comic number ends in '6'. --Tim P 19:19, 23 May 2008 (UTC)

Agreed. I formally propose that FRS Channel 6 (US) and PMR446 Channel 6 (Europe) be made the official xkcd geohashing radio communication standards. Waq 12:26, 24 May 2008 (UTC)

Seconded, let's make a page for Radio Frequency Standard and put a link on the main page so people can find out about it?

--Ishboo 19:48, 3 June 2008 (UTC)

Agreed - If you have "Privacy Codes" on your FRS radio, I further propose using Code #1. Also, as a ham radio operator, I also propose 146.520 (the 2m calling frequency) --Scottkuma 19:14, 30 May 2008 (UTC)

I would advise against using Privacy Codes, as not everyone can use them... so those who have them should just use Code 0. --Tim P 19:40, 30 May 2008 (UTC)
That makes better sense. --Scottkuma 03:44, 1 June 2008 (UTC)

For Australia / NZ; I would suggest UHF 26 (instead of channel 6, as Ch.6 is a repeater output) --DancingMan 10:11, 31 May 2008 (UTC)


OKAY, so if I don't hear any other suggestions by 02:00 UTC, 4 June, I'll create a starter page with the following suggested frequencies:

Continent Radio Channel Frequency
North America FRS/GMRS Channel 6 462.68750 MHz
Europe PMR446 Channel 6 446.06875 MHz
Australia/New Zealand UHF CB Channel 26 477.05000 MHz

Of course, even after the fact, you could add your own suggestions. Just research the channels on Wikipedia first. --Tim P 20:15, 3 June 2008 (UTC)


ADDED to Main Page#FAQ and at Radio Communications. If you feel there needs to be more (and there probably could be), feel free to round out the article. --Tim P 03:58, 6 June 2008 (UTC)