Difference between revisions of "Talk:Main Page"

From Geohashing
imported>Fippe
(Graticules without weekday geohashes: New Section)
imported>Benjw
(Graticules without weekday geohashes: two suggestions)
Line 171: Line 171:
  
 
How do we approach this? I don't know about any geohashers from these areas. The only graticules with pages are [[Chatham Island, New Zealand|Chatham Island]] and [[Pitt Island, New Zealand|Pitt Island]], and they seem to be inactive. Is this a problem that should be solved, or one that can be ignored? --[[User:Fippe|Fippe]] ([[User talk:Fippe|talk]]) 10:51, 17 September 2018 (UTC)
 
How do we approach this? I don't know about any geohashers from these areas. The only graticules with pages are [[Chatham Island, New Zealand|Chatham Island]] and [[Pitt Island, New Zealand|Pitt Island]], and they seem to be inactive. Is this a problem that should be solved, or one that can be ignored? --[[User:Fippe|Fippe]] ([[User talk:Fippe|talk]]) 10:51, 17 September 2018 (UTC)
 +
 +
:I guess it's a slightly grey area, owing to the inexact wording of the algorithm, but the Dow *does* have an opening price on the desired day, even though the local time in New York is the previous day.  You'd use the date in your graticule with the opening price for the Dow at whatever point on your local date the Dow opens.  Example: It's Wednesday 2 February in a graticule in the GMT+13 time zone (which I think is 18 hours ahead of New York).  From the point of view of that graticule, the Dow would open at 03:30.  At that time point, it would be 09:30 on Tuesday 1 February in New York, but that doesn't matter.  To calculate our hashpoint, we would use the current date in our timezone (2 February) and the value of that Dow opening.
 +
 +
:I think this is acceptable under the current wording for graticules west of -30 longitude: "if there is no opening price for the Dow on the desired day..." because either (a) there isn't an opening price: the Dow opens after the desired day has ended, and we therefore use the previous or most recent trading day -- which we'll obtain at 03:30 when it's announced; or (b) there is an opening price, and it's the one that happens at 03:30 regardless of the difference in dates between New York and our current graticule.
 +
 +
:The other way to approach it would be to say that graticules west of the dateline are defined for algorithm purposes as being "east of -30 longitude".  Then the rule would be to use the current local date and the most recent Dow opening at midnight at the start of the day, which for our example graticule would be the Dow opening on New York date Monday 31 January.
 +
 +
:Either way, it's not a problem which is likely to occur often (it's been ignored for the last ten years), and I'd be happy with any approach to a solution, as long as it was reasonably thought through and didn't take the mick.  I think both of the suggestions above are reasonable and would be acceptable locally. — <span style="text-shadow:grey 0.2em 0.2em 0.1em; class=texhtml">[[User:Benjw|Benjw]]</span>&nbsp; <sub>{[[User talk:Benjw|talk]]}</sub> 09:16, 19 September 2018 (UTC)
  
 
= Older Topics =
 
= Older Topics =

Revision as of 09:16, 19 September 2018

Archive.pngTopics on this page which have clearly been handled or resolved can be found in the archives.
When archiving a section of this Talk page, please say so in the edit summary here.
Due to repeated spam attacks on this wiki page, this page is editable by registered users only. Please log in and join us!

Contents

HTTPS

This site is not HTTPs, and google is now informing people that it's not secure. (unsigned comment by User:Mckaysalisbury)

I think the site should get an HTTPS certificate. Relet already asked about this eight years ago. Getting one these days does not cost anything but a little time, but I do not know who has the rights to install one. Probably the Bureaucrats, that is Randall, Joannac and Zigdon. I'll write on their talk pages, but I don't think they're active. If nobody responds, perhaps Randall will answer to an email. --Fippe (talk) 19:04, 2 September 2018 (UTC)

Proposed changes to Algorithm

Tenth Anniversary Anti-Discrimination Algorithm Upgrade

Over the years, the fairness of the Algorithm has come into question. Geohashers in different parts of the world get unequal advance notice of their future coordinates. To celebrate our tenth anniversary and as a symbolic measure, could we eliminate this source of geohashing descrimination? To level the playing field, each time zone could get 12 hours notice of tomorrow's coordinates which remain valid for 24 hours. So at noon today, local time, you'd discover tomorrow's coordinates. Now we need to find a new metric for use in the algorithm. Earthquake json data might be usable and could lead to a new San Andreas Achievement. We'd could use the data from the quake nearest to and before noon, local time. --Sourcerer (talk) 11:14, 31 July 2017 (UTC)

The current algorithm is indeed a bit unfair. The W30 rule was a good idea to amend some disadvantages players in the eastern hemisphere 1) have. However now the players in Europe have an advantage over those in America. I won't complain about that since I live in longitude 11 east, but I can see the point.
I don't think that there is a fair solution that uses a certain event (like the Dow opening) for the whole world while keeping each time zone's beginning of the day. Using different stock market indices for different regions would soften that a bit, but it would also make the calculation more complex.
A fair seed value would have to be:
  • published at the same local time for each time zone (well... time zone borders are not always straight lines, but this is a different problem)
  • distinct and verifiable
  • not dependent on a certain provider
Especially the last point is a huge advantage of the DJIA since there are several sources to get the value. I'm not sure if the earthquake JSON satisfies that.
1) I don't really like the phrases eastern and western hemisphere, since the division is completely arbitrary. There is no east pole and therefore no natural eastern half of the globe. But in this case I lack a better word. -- Solli (talk) 12:59, 31 July 2017 (UTC)
I think we keep the DJIA for continuity's sake but make the point valid for twenty four hours from the time of announcement. That means that at 9:30 New York time on Monday, which is 4:30 Kiritimati time on Tuesday an offset will be announced from the southwest corner of the graticule which will be valid for twenty-four hours until 9:30 New York time on Tuesday, which is 4:30 Kiritimati time on Wednesday. Yosef (talk) 15:04, 1 August 2017 (UTC)
You can't sensibly have an announcement of the co-ordinates at a given local time in each time zone. That would require 24 different announcements/data sources. There's got to be just one data source (or pedantically/arguably two, given how the current W30 rule works).
I also think that having co-ordinates only valid for (up to) 24 hours on a given date, ending at midnight, is one of the key things about geohashing. The date is part of the algorithm, so making co-ordinates valid across two different dates, even if only for 24 hours in total, seems wrong. Even to the east of W30, where co-ordinates are announced the previous day and people get more notice of the location, the location itself doesn't become valid until midnight ticks around and the date changes accordingly.
Putting those two observations together says that, for me, if a change is made, the W30 rule should be adopted globally, and today's DJIA announcement should be used to define tomorrow's co-ordinates, valid from midnight to midnight, no matter where in the world you are. I have no strong opinion on whether a change should be made or not, but if it is, this is the only option that seems sensible to me. PaintedJaguar (talk) 06:42, 2 August 2017 (UTC)
Painted Jaguar you have a point, but the date would be anchored in New York, or if we wish to be respectful to Randall Munroe who created this site, Boston. In other words, we have to anchor ourselves on something somewhere, so we might as well use our origin. Yosef (talk) 12:40, 2 August 2017 (UTC)
I get your point. I just wanted to point out that every algorithm that depends on a singular event like the Dow opening results in having all coordinates available at the same point in time - and at different local times around the globe. If this is considered unfair, we would have to find another source of randomness. We could also skip the idea that hash points are valid on a given day (starting at 0:00 and endig at 24:00 local time) and make them valid, let's say from midnigt to midnight UTC or nine a.m to nine a.m. EST or whatever. But this would make Midnight Geohashes a bit awkward if they can be reached at lunch time in certain places. -- Solli (talk) 12:53, 2 August 2017 (UTC)
I agree Solli. I think that the Midnight Hash is a reasonable sacrifice in order to keep everyone on the same page with timing. In other news, let's try to get Randall and some of the developers involved. I'd also like to see if we can contact Pastori and Tilley because Pastori is super active and Tilley writes his expedition pages. Yosef (talk) 09:13, 3 August 2017 (UTC)
Even though I'm not really affected I see the point. I think the idea of PaintedJaguar is the best one, even though it still is kind of unfair. I don't like the idea of having the coordinates valid from the opening, but that's probably just because I'm not used to it. But it would make it possible for some people to make a double-hash on one local day, while others wouldn't have that possibility. I'll let it sink in. Also I think the tenth anniversary would be a sensible time to address the issue! RecentlyChanged (talk) 13:27, 3 August 2017 (UTC)
I think the only possible change could be, like PaintedJaguar said, is to enact the W30 rule in totality. It's a lot fairer, and has the benefit of the ENTIRE world having the same point rather than the current split. RecentlyChanged, I'm not sure what you mean. The 30W rule would create the hash for the next day and would be good for the 24 hours of that day(going active at Midnight). The closest you get to a double-hash in the same graticule is what Sourcerer does a lot with his midnight runs by the -0 to 0 border...but maybe I'm not understanding your concern.
...Next thought...The current day's hash would be yesterday's opening and...yesterday's date? Hmmm...maybe there should also be a change to use Yesterday's opening and <Date-of-hash> to calculate the fractions(like what is already done on the weekend). Being in the Eastern Time Zone, I've never really paid much attention to the 30W rule. I think the biggest barrier to this change from the start(from what I've read), was that Randall wanted this to be a completely spontaneous expedition that couldn't be planned for until the day of. I feel like he has left this game to the community and we can collectively decide how to proceed. With everyone east of 30W already having a few hours to half a day to plan, this throws a wrench in the original intention anyway. Pedalpusher (talk) 20:01, 4 August 2017 (UTC)
Since I was asked to comment, here are my thoughts:
- With the current rules, East of 30W there is less time during the week, but there is more time to plan the Saturday meet-up (which is arguably the most important one), so that seems like a fair compensation. Of course having done only one hash East of 30W I'm not the most qualified to have an opinion on that matter.
- How big is this issue really? Maybe someone should compute the average hash per user East and West of 30W?
- There are other properties of geohashing that arguably make it "unfair" - graticules get smaller when you go further North/further South of the Equator, so for the people in Anchorage in average the geohashes are closer than the ones in Quito.
- Remember, the 30W rule was created as an extension/precision, by the original author, and only a few days after the original announcement. Diverging too much from the original idea would be like creating a new game... Unless there is really a consensus, there is a risk of a split in the community, which is already not that large. If there is ever a vote on a revision of the algorithm, we should decide in advance of a very high threshold required to adopt the proposed change (for instance 90% in favor, as well as a certain share of all users active in the past 12 months taking part in the vote).
--Crox (talk) 22:57, 5 August 2017 (UTC)
I'd like to kind of recenter everyone on what I think is important in geohashing so that I can make my argument for basing it off of a Universal time from the opening of the stock exchange.
1. Get to the hashpoint. It doesn't matter which vehicles you use, who you see there, get there.
2. Chances are that point is a place you've never been before and will open your eyes to a new view.
3. Spontaneity is key. There is a minimal amount of time to plan.
With all of this in mind I can understand applying the 30W rule for the whole world but I think that making the point valid immediately is part of what makes the challenge exciting. Nonetheless, there should be at least a 24 hour period where each point is valid.
Finally I'd like to add that for the sake of those living along the Prime Meridian I would like all hashpoints to be offset from the southwest corner of the graticule. When the east/west offset is very high the points are very far apart making it unnecessarily more difficult for those hashers. We can publish negative offsets for those in the western and southern hemisphere who are too lazy to do subtraction. - Yosef - 17-Aug-2017
As someone who actually lives about 12 km from the prime meridian, I'd say this is a complicated solution to a problem that doesn't exist. Yes, some days my nearest hash is very far away, but I'm not going to go hashing every day anyway. Some days my luck is in and I get two hashpoints nearby. The weird goings-on in this part of the world are part of the interest of hashing, and are a very small price to pay for the simplicity of the Algorithm -- everyone has the same decimal coordinates. Please don't change that. — Benjw  {talk} 09:24, 31 December 2017 (UTC)

I'd like to protest the current unfairness towards the western hemisphere with my formal PROTEST hash: 2017-08-20 42 -87 No graticule should be left without a valid hashpoint for more than 24 hours. The hash point was announced at 8:30 Chicago time on Sunday, and I reached it by 8:15 Chicago time on Monday. Yosef (talk) 18:49, 29 August 2017 (UTC)

Nice one. What about one simple additional rule: "Each hash point is valid until the next valid hashpoint for this graticule is announced." Im just an elitist European and I don't have such problems, but I can't see why it should not be allowed to go hashing in the morning hours in certain areas. -- Solli (talk) 07:13, 30 August 2017 (UTC)
Thanks Solli. How do we get proper consensus for such a change? Do we need the developers to change their techniques or can we just leave it alone? Yosef (talk) 14:34, 31 August 2017 (UTC)
I have to reject your protest for 2017-08-20 42 -87, because the coordinates for the Sunday hashes are published on 8:30 Chicago time on Friday! --GeorgDerReisende (talk) 17:12, 31 August 2017 (UTC)
Understood Georg. Where do you think I should have gone for my Monday morning hashpoint before 8:30? Yosef (talk) 18:59, 31 August 2017 (UTC)
As far as I can see we have two different approaches. Step 1 would be to keep each hashpoint valid until new coordinates are published for a given graticule. To do this we just have to update some Wiki pages, but no Implementations have to be changed. Just select the cooridnates of the previous day and have a nice expedition.
However one might still consider this unfair because at 9:30 EST the new coordinates become instantly valid with zero preparation time whereas east of 30W we can prepare in advance. If we wanted to amend this we would have to make more severe changes to the algorithm. --Solli (talk) 09:15, 1 September 2017 (UTC)
For the time being we can encourage these kinds of PROTEST hashes until something gets worked out. Yosef (talk) 04:09, 6 September 2017 (UTC)

Did you realize that in the Original Comic it says: "That date's (or the most recent) Dow opening"? Before 9:30 EST the most recent Dow opening is that of the previous (business) day. Taken literally this means that in western time zones there are two coordinates per day, one before 9:30 EST and one after. However I assume that Randall's intention was to have one set of coordinates for each day and graticule. So IMHO it makes sense to use the previous (business) day's coordinates until a new Dow Jones opening value is published, as proposed above. I'm going to add this to the Known Issues and update The Algorithm page if there are no strong opinions against it. --Solli (talk) 09:30, 6 September 2017 (UTC)

I am going to say no to that concerning The Algorithm. We don't want someone like Sourcerer, NWoodruff, Pedalpusher or Pastori who have all done more than one-hundred points to find out one morning that their algorithm changed. Get approval from a couple of them including GeorgDerReisende who has already expressed displeasure and then change it.
I don't get you point. Past expeditions will stay valid. And everything that is considered a valid expedition now will continue to be valid in the future. The only thing I want to change is to create the additional possibility to go hashing west of W30 before the Wall Street opens. Isn't that exactly what you wanted to promote with your protest hash? But yeah, I'll try to get feedback from the 100+ users before I edit any page. --Solli (talk) 11:27, 7 September 2017 (UTC)
Wow, I never thought I'd be summoned for something like this before, and I appreciate you all value my opinion. :) For me, I believe Solli summed it up perfectly:
"Did you realize that in the Original Comic it says: "That date's (or the most recent) Dow opening"? ... Taken literally this means that in western time zones there are two coordinates per day, one before 9:30 EST and one after."
Whether you allow the carry over from the day before or calculate a 'fresh' hash before the DOW opens for the day, you will have 2 hashes available in one day. This can get confusing and much more difficult in writing up/reading the Expedition reports since the date on the report is not the same as the day you went. Because of all this, my vote on this idea/rule change is a firm and unyielding NO. I don't mind the current setup of today's rules: that it is good from when the hash is published to midnight. That keeps the dates/hash calcs very simple and easy to understand. Unfair? Somewhat, I have to wait 9.5 hours into the day for my daily hash, but I still have over 150 expeditions under these rules(and NWoodruff has over 500 in the same time timezone). Plus, I still have most of the day to plan and the entire evening to go if I'm able and it's accessible. No, we don't have Sunrise or the first Midnight Hash, I can't get a hash on the way TO work(during the week), but these aren't detrimental to the game, and it makes it that much more satisfying to get when you finally do. Yosef, as for your Protest hash, I'm sorry but like GeorgDerReisende said, that is already defined as a Retro-Hash for Sunday. That being said, if we are going to discuss a global 30W Rule, I am fully on board as, in my mind, it meets my 'simplicity' rules as well as being a lot more fair. Yes, we would slightly lose the spontaneity of it (but only West of 30W) and that is a minor negative well overbalanced by the positives of enacting such a rule. Pedalpusher (talk) 15:27, 9 September 2017 (UTC)
Pedalpusher Note how I defined it. It doesn't say anywhere on the page that the expedition was considered successful. That's why I called it a protest hash and not a true hash. What is most important to me is that there will not be a moment anywhere in the world that will be without a hashpoint. That includes Australia at 1 AM. I would prefer to go by UTC so that we can have keep things sane on timezone borders, but I understand your request for simplicity. Yosef (talk) 19:49, 10 September 2017 (UTC)
Yosef, I understand what you are saying, but my point was that this type of expedition is already defined as a Retro-Expedition, whether or not you make it(and your's a successful one at that since you made it). How will changing the Timezone activation make things better? What exactly am I missing here? Honestly, I will vote against anything that has local hash-times (wherever local is for you) carry over into the next day. The only solution I can currently see (and would be willing to vote for) is a Global 30W rule. In that case, at your local time Midnight, the new hash (Derived from the Dow Opening the day before and presumably the current date) would activate and be valid for 24 hours, just like it currently does in Australia and everywhere else East of the 30W line. I'm hesitant to suggest this, but do we need a Proposed Changes to the Algorithm page were someone could fully explain the rules and methods of their change and maybe a Pros and Cons section to debate the merits of each suggestion? I'm going to poke a few West Coasters that I know have been active somewhat recently and have also done a lot of hashing in the past to get a few more comments here. Pedalpusher (talk) 21:32, 10 September 2017 (UTC)
Pedalpusher - Every fifteen degrees longitude there is a timezone change. Most of these changes happen in the ocean or at international borders, but nonetheless there are places which are corner cases particularly in the United States, Canada, and Russia. Some graticules have two time zones. There are ocean graticules that have two different dates because of the international date line. This all gets to be a little nutty, but if everyone used UTC time, then there would not be any question. We could put up a sign that would be very clear as to when the hash would become activated in your time zone. Yosef (talk) 08:55, 12 September 2017 (UTC)

I've been out of hashing for too long and just returned. Utilizing a Global 30W rule may be the easiest to implement if a change is agreed. I "missed" a point because I was way that day and was able to hit it the next morning before the DOW opened. I counted it, however, I had a IRC conversation where the general thought was my run was a Retro-Hash because of the day change. If you make it is in the eye of the beholder and usually that's the person on the expedition. If we are going to change, I think Global 30W rule is best. I also think the more productive hashers should have more of a say. If the hashing community can't come to an agreement, then the system as is should remain in place. User:Whoa Knock (talk) 03:00, 17 September 2017 (UTC)

It sounds like the only thing that can be agreed upon is make the 30W rule for the entire world. Anything more drastic would not have enough support. Yosef (talk) 10:48, 18 September 2017 (UTC)

Has this not been summarized for formal vote yet? I am for a planetwide 30W rule change. For us in the states, any loss of the "spontaneity" requirement is balanced by actually having 24 hours to visit a geohashpoint for 7 days, not just 2. Now if only the "global" algorithm didn't produce so many poles... --Thomcat (talk) 13:53, 18 September 2017 (UTC)

Count me in favor of a global 30W rule. I feel as though points remaining valid for a 24 hour period is more in the spirit of the game than is rigidly adhering to calender days. Mystrsyko (talk) 04:07, 22 September 2017 (UTC)

I have to admit that I don't see this as being that unfair, but I also live someplace where we only lose 6.5 hours a day on weekdays. Personally, if I only had the time to try make the previous day's hashpoint before work, I'd just go and mark it as a Retro, but I also live someplace where most of my expeditions end up as "No Trespassing." I think that trying to completely change the Algorithm is a bad idea. Our tools don't seem to have a lot of support behind them - I seriously doubt they'll get updated to support something new, and then we'll really have a mess on our hands. The easiest solution to my mind, which requires no changes to the tools, is to simply allow people to use the previous days coordinates until there are new ones available, which means this change will only come into play Mon-Fri local midnight until 9:30AM Eastern. My next preference, except that it requires tools to change slightly is a global 30W rule, but I somehow expect that someone will be complaining that people on the West coast get more time to prepare for the expedition than people in Europe even though everyone gets a full 24 hours to go the hashpoint. Jiml (talk) 23:13, 21 October 2017 (UTC)

Jiml has an excellent point. I think I might start a page where we can keep inventory of all of our tools and how flexible they would be in the event of an algorithm change. Please add to the list as you see fit. Yosef (talk) 05:05, 23 October 2017 (UTC)

Hm, the 24-hour rule sort of creates a new W30 issue. Only moves it a day! Let's keep in mind that this is not an activity where points scored should count and be flexible by judging when a hashpoint has been reached. But you have to actually reach the hashpoint within a reasonable time after it was published. And after all, the hasher has to live with the fact that (s)he cheated in order to be able to "add a point to heir total". Palmpje (talk) 14:47, 1 November 2017 (UTC)

Agreed Palmpje. Someone updated my PROTEST hash to make it a successful one. I do not think that is appropriate and we should wait for consensus before that is done. - Yosef (talk)


The McKay proposal

I've always thought the way we treat it on this wiki is kind of wrong. Here's what the algorithm says: "That date's (or most recent) dow opening." So here's what I propose:

In order to qualify for being at a hash, the dow opening must be the most recent dow opening at the time you are at the hash (or for a dow opening later on that calendar day if you somehow know that)

This proposal is backwards compatible, in that I believe it'll still work for most everyone in the current rules, for at least good portion of the day, and always gives you at least 24 hours to plan at least one hash.
Examples. I currently live in California, so I follow Pacific Time. This means that for me, the Dow opens at 6:30 AM. Which means that on a Tuesday, once that dow opening is revealed. I have 24 hours to plan up to two hashes:
  • Today's date with the current opening
    • If I choose this, I have to go before midnight, because otherwise, the date will be wrong
  • Tomorrow's date with the current opening
    • If I chose this, I must do it before 6:30 AM tomorrow. (Jim thinks it also has to be after midnight tomorrow)
I actually like sleep so I will rarely choose the latter option, and that's convenient because the tools will work well this way today for most users?
I think it actually follows the rules, because it says "That date's (or most recent) dow opening". According to that rule at 6:29 AM, I have two choices, that day's dow opening, which I can't know yet (unless I'm Bill Gates), or the most recent dow opening, which was yesterday's. At 6:31 I only have one choice, because that day's dow opening is the most recent.
I do admit that for some people they will get their changeover happening at inopportune times, but I guess the biggest "difference" is that people for whom the dow opens in the evening can get up to two hashes a day during reasonable hours, but I don't think it's that big of a deal, and I'm the one being shorted? Am I missing something? McKay (talk) 04:31, 28 December 2017 (UTC)
This sounds like a reasonable approach for me, though it does require updates to our tools to use the "newly available" hashpoint. I added a few words to your description above to touch on a point I think you're in agreement on: Basically, there is only one hashpoint active at any time, but a future one might be known for planning purposes. Jiml (talk) 03:31, 29 December 2017 (UTC)
Yes, changes would be desirable, but they wouldn't be required, unless they wanted to see the additional point? McKay (talk) 19:50, 31 December 2017 (UTC)
I shall say straight off that I don't particularly like this solution. It is removing one point of "discrimination" (some people don't have a valid hash point at certain times) by introducing another (some people now get two hash points per day, others get one). I am in favour of solving the first, but not at the expense of the second.
Who doesn't get two in my new proposal? I think the number is zero, but I may not be thinking of all cases. McKay (talk) 19:50, 31 December 2017 (UTC)
Hash o'clock is 14:30 GMT (in the winter, at least). Australia's Northern Territory is in the GMT+09:30 timezone and does not use daylight savings time, so hash o'clock there coincides with midnight for half the year. There might be others for parts of the year. But in any case, some places (Aus and NZ particularly, but also to a lesser extent the west coast of North America) would have one hashpoint for a very short time during the night, and a second one for the entire rest of the day. Other places (particularly in Europe) would have two hashpoints that change over around lunchtime. To me (in Europe) that seems more confusing than the current "one hashpoint each day" state of things, and would seem to be an avoidable consequence of changing the rules to fix the "no hashpoint for some of the day" problem that this discussion was intending to fix. — Benjw  {talk} 14:54, 1 January 2018 (UTC)
[Edit: I no longer support this suggestion, or probably any solution involving rules depending on timezones, because of later discussion. I leave it here simply for historical completeness. — Benjw  {talk} 15:21, 15 August 2018 (UTC)] My preferred solution would be: "At midnight (local time) at the beginning of each day, a new hashpoint comes into play. Its coordinates are calculated using the Algorithm along with the current date and the most recent Dow opening. This hashpoint remains the current hashpoint for as long as the date remains the same." So a new hashpoint comes into play at midnight local time everywhere. It is calculated using what, at the time, is the most recent Dow opening (thus keeping as far as possible within the spirit of the original idea). This hashpoint lasts for 24 hours everywhere (or 23/25, if daylight savings time changes!). Everyone will be able to calculate this hashpoint before it comes into play (or, at the very least, at the instant it comes into play). Each location on Earth has exactly one current hashpoint at all times. Thoughts? — Benjw  {talk} 21:21, 29 December 2017 (UTC)
While that may be your favorite, it doesn't seem to be relevant to my new proposal, and it also introduces substantially new rules. McKay (talk) 19:50, 31 December 2017 (UTC)
Crox has pointed out the problem with it, below. I'm not sure why it's substantially different and/or not relevant -- it's simply another variation on exactly what data is fed to the algorithm and how long the result is valid for. — Benjw  {talk} 14:54, 1 January 2018 (UTC)
[Generally, I'm not in favour of any change at all, see also my comments above.] This solution appears interesting at a first glance, but that would mean the different implementations would need to integrate timezone databases, complete with DST data etc. Also, there are many graticules that contain areas within different time zones. Take for example 43,131. Half of it is in China (UTC+8), the other half in Russia (here UTC+10). This means in Winter (and only in Winter, neither China nor Russia have DST), hash o'clock happens at 22:30 local time in the Chinese part of the graticule, but at 00:30 local time in the Russian part of the graticule. Which DOW value do you consider to calculate the coordinates, which are valid for the whole graticule? the 30W rule is MUCH easier, and still it takes quite some effort to implement it correctly... Btw, this is precisely why the 30W rule was defined that way nearly 10 years ago, see the discussion here: Talk:Main_Page/Archive_1#Europe_Time_Zones_problem. --Crox (talk) 03:38, 31 December 2017 (UTC)
I'd like to start the hashpoint according to UTC. That way, we don't have to mess with graticules being split between hashpoints. If we can't do that then at least we should be lenient with people who are in inconvenient graticules. (unsigned comment by user:Yosef)
Crox, that's a beautiful example of a problem that I hadn't considered! Well done for finding it. I'll think again. — Benjw  {talk} 09:20, 31 December 2017 (UTC)
I firmly reject this proposal. Timezones are a nightmare for programmers, don't bring them into the algorithm. Crox brought up an excellent specific point. Additionally, hash o'clock is 15:30 for me. This is a time when I could be in the middle of an expedition, and it would be bad if the goal changes then.
I recognize that people living in 180W-30W graticules have a disadvantage over 30W-180E graticule users. I'd accept change, but not in this form. Finally, any change needs to be supported by Randall, not only the community. --Fippe (talk) 13:21, 15 August 2018 (UTC)
Being a programmer who has had to deal with timezones a lot in the past, I completely agree with Fippe on their point about them being a nightmare —the current status quo regarding time of hash receipt is tricky enough, but manageable —(09:30 EST/EDT) is still a single point in time across the whole globe after all so everyone gets their coördinates at the same time, just not at the same wall-clock time. Saxbophone (talk) 13:37, 15 August 2018 (UTC)

Graticules without weekday geohashes

There are several areas in the world that never have weekday geohashes. They are located in the east of the 180th longitude, but west of the date line. Here's a map. I'm not just talking about water here, the land areas exist and some of them are populated considerably:

Hash o'clock in these areas is a few hours after midnight on the next day. This means that geohashes are only reachable on days that the NYSE is not open: Saturdays, Sundays, and Dow Holidays. The W30-Rule does not protect these areas since they are in the western hemisphere.

How do we approach this? I don't know about any geohashers from these areas. The only graticules with pages are Chatham Island and Pitt Island, and they seem to be inactive. Is this a problem that should be solved, or one that can be ignored? --Fippe (talk) 10:51, 17 September 2018 (UTC)

I guess it's a slightly grey area, owing to the inexact wording of the algorithm, but the Dow *does* have an opening price on the desired day, even though the local time in New York is the previous day. You'd use the date in your graticule with the opening price for the Dow at whatever point on your local date the Dow opens. Example: It's Wednesday 2 February in a graticule in the GMT+13 time zone (which I think is 18 hours ahead of New York). From the point of view of that graticule, the Dow would open at 03:30. At that time point, it would be 09:30 on Tuesday 1 February in New York, but that doesn't matter. To calculate our hashpoint, we would use the current date in our timezone (2 February) and the value of that Dow opening.
I think this is acceptable under the current wording for graticules west of -30 longitude: "if there is no opening price for the Dow on the desired day..." because either (a) there isn't an opening price: the Dow opens after the desired day has ended, and we therefore use the previous or most recent trading day -- which we'll obtain at 03:30 when it's announced; or (b) there is an opening price, and it's the one that happens at 03:30 regardless of the difference in dates between New York and our current graticule.
The other way to approach it would be to say that graticules west of the dateline are defined for algorithm purposes as being "east of -30 longitude". Then the rule would be to use the current local date and the most recent Dow opening at midnight at the start of the day, which for our example graticule would be the Dow opening on New York date Monday 31 January.
Either way, it's not a problem which is likely to occur often (it's been ignored for the last ten years), and I'd be happy with any approach to a solution, as long as it was reasonably thought through and didn't take the mick. I think both of the suggestions above are reasonable and would be acceptable locally. — Benjw  {talk} 09:16, 19 September 2018 (UTC)

Older Topics

Organization / automation questions

So, we now have date pages (2008-06-07), date-bound templates for the day's expedition images ({{Expedition Images/2008-06-07}}), categories for the day's meetups (Category:Meetup on 2008-06-07 -- not all of which have been 'created', even though most if not all are in use). We also have the "Recent and Upcoming Coordinates" and "Gallery of Recent Expeditions" sections on the front page. There are likely other daily-maintenance-type things I'm not aware of (archiving? Creation of the supercategories like Category:Meetup in 2008-06?).

I'd be more than willing to work on automating some/all of the above, if people are interested -- I know tjtrumpet2323 mentioned that he doesn't mind doing the manual update of the front-page coordinates, and that it would likely be handled by a template eventually (once the mediawiki daily coords implementation was done) anyway. I've been playing with api.php a bit recently, and most of the automation is reasonably simple. But I don't want to step on any toes (explicitly including rpm's, since I'm not sure how kindly he'll take to people running bots against the wiki).

Additionally: It would be trivial, once images are categorized by meetup date (very few are currently) to randomly swap out the pictures that have been picked for the day's Expedition Images. But this introduces the question of whether a second (editorial, not automatic) category should be created for "best of the day" to use as the pool (assuming the consensus is "automation is good", rather than "keep it editorial, like it already is"), instead of pictures like Image:2008-06-01_37_-121-Tapin-2.JPG.

Thoughts?

--Tapin 20:59, 11 June 2008 (UTC)

I'd like to see a lot more automation done, and was considering writing my own bots to do some of it. But considering my other workload, I'm not sure when that will happen. One thing I'd be worried about is creating pages just to fill in the dates, without actually having content for them. Your comment about editorial content also stands - any bots should be willing to accept imposed content. Zigdon 21:57, 11 June 2008 (UTC)
The main reason pages such as Template:Expeditions/2008-06-12 exist is to allow inclusion on pages such as 2008-06. Now that the date pages pretty much only contained templated-in content, they're practically unnecessary. However, from a template-coding standpoint, Template:Date nav is easier to code when the page titles are simple, like 2008-06-12. Does anyone know if there's a way of transcluding (templating) pages in the Main namespace? (I have more thoughts on this section's topic as a whole, but have to leave for now.) --Tim P 15:40, 12 June 2008 (UTC)
You can transclude anything, not just templates. Use {{:Main Page}} to transclude the main page, for example. Mike.lifeguard 00:26, 13 June 2008 (UTC)
Thank you, Mike.lifeguard. I didn't realise the colon notation extended to transclusion. I think when I create the date pages for the weekend in a few hours' time, I'll just create YYYY-MM-DD pages and not bother with Template:Expeditions/YYYY-MM-DD. I'd be willing to go back through the three weeks of pages and move data around... as well as to clean up the includes... seeing how I did 90% of them to begin with. Any thoughts? --Tim P 06:00, 13 June 2008 (UTC)
This is a year-old question but I've never seen this answer given, and I think it might be a good compromise between automatic selection of unsuitable images and frequent adventurers hogging the front page. When uploading pictures, add something like a Nominated for front page category to your showpiece picture, and the automation randomly displays no more than one such nominated picture from each expedition for any given date. -Robyn 15:57, 12 April 2009 (UTC)

Google Maps API

Per The Register's article, access to the Google Maps API is going to cost money. Is there already a plan for how this site will handle that? Get Randall to beg? Find some sympathetic geohashers who are also Google employees? Both?

--UncleOp 14:00, 27 October 2011 (EDT)

Automated Transclusion Implemented

I did some automating/optimising stuff over the weekend. The Template:Expeditions/YYYY-MM-DD pages are to be completely discontinued from 17 June, as meetups are now included on the date pages themselves (YYYY-MM-DD, e.g., 2008-06-16). I even went back and copied stuff over for continuity's sake. As far as the image gallery templates go, I automated a template/script to show the current (UTC) day and the three prior for use on Main Page. It uses the new syntax {{Expedition Images|YYYY-MM-DD}} which includes Template:Expedition Images/YYYY-MM-DD (note the slash), along with the appropriate header (based on page context) if the template exists, or a "start this gallery"-type message if it doesn't. It also provides a "direct edit" link to the template from the date pages. --Tim P 05:53, 16 June 2008 (UTC)

Thoughts? You may note that I opted not to provide a "direct edit" link in instances where {{Expedition Images|YYYY-MM-DD}} are transcluded on Main Page, more so out of fear of the page's visibility than anything. I suppose that most potential spambots would give up on the write-protected page and not follow any "direct edit" link we'd put right on that page, but you never know. I would be perfectly willing to put such a link back into the template if consensus deems wise (i.e., people agree here) or if convention deems necessary (i.e., people get fed up with hunting for an edit link). My initial fears could be totally ridiculous, and I'm totally willing to admit that. --Tim P 05:53, 16 June 2008 (UTC)
I like it very much, awesome effort sir. The 'add your own photo' is pretty clearly findable on the YYYY-MM-DD pages. If that is not enough, then a comment in the source on the Main_Page directing people appropriately should be the next step IMHO. See how it fares? :) --Nemo 11:12, 16 June 2008 (UTC)
Only current thought now... the automatic 'start the gallery' link means the previous days gallery (with the heklpful comments) don't get copied over... I wonder if people are just more likely to blindly start a gallery now rather than copy the comment hints too? I don't think think content can be automated into there though can it? May not be a problem anyway, wait and see? --Nemo 11:17, 16 June 2008 (UTC)
This isn't a show stopper, but I just discovered a timing point. We here in the east side of the 30W rule have pics for today already uploaded (8:20am local time, 17th June), but it's still 40minutes before UTC rolls over to the 17th and the frontpage gets the 'create a gallery for the 17th' type link. No biggie, it just limits our bragging rights! ;P --Nemo 22:30, 16 June 2008 (UTC)
Because of the limited number of morning-time meetups, I figured that 00:00 UTC was still a reasonable time to switch over because, as Template:Recent Images says, it's "reasonably mid-day for the easternmost time zones," i.e., 12:00 or 13:00 in New Zealand depending on DST. Not to mention, it's immensely easier to program a switch at 00:00 UTC than at any other time on this wiki. Photos uploaded to the designated gallery before 00:00 UTC still get to be at the top of the images section for a full 24 hours, so yeah, it really isn't a big deal. --Tim P 18:33, 21 June 2008 (UTC)
yup. I was just being needlessly pedantic. ;) However, I do have a thought - thuogh don't know if it's possible. At the moment it displays the last 4 days, but in fact it seems more often than not, when I see it the currentday gallery is still waiting for the first image - so we only see three days. Can you check for the existance of the CURRENTDAY gallery - and if it doesn't exist, then also include CURRENTDAY -4 days. That way we get 4 days of actual pictures at all times (which I think works best, imho 3 is a little too small a showcase through the week). The -4days gallery automatically rolls off then not at 00:00UTC, but when the currentday gallery is created... :) --Nemo 00:15, 22 June 2008 (UTC)
DONE and IMPLEMENTED. See Template:Recent Images for specifics. Great idea, Nemo. --Tim P 03:54, 22 June 2008 (UTC)

There is a problem with the pages that show links to the expeditions by month: 2008-08 --Hermann 20:41, 16 August 2008 (UTC)

re-organise the frontpage

I'd like to propose that now that geohashing is a few months mature in the wider internet, that the need to explain what it is in detail on the top of the front page of the wiki is diminished.

My humble opinion is that most people hitting the front wiki now are familiar with geohashing, or if new (less likely after that post-announcement rush), are more likely to be able to find detailed info after an initial introduction.

So how about a frontpage reorganise with this all in mind? Currently, the front page TOC looks like

  1. What is this?
  2. How it works
    1. Official xkcd meetups
    2. Unofficial invitations
  3. Active Graticules
  4. Implementations
  5. Recent and Upcoming Coordinates
  6. Gallery of Recent Expeditions
  7. Known Issues
  8. FAQ
  9. Related Projects

I propose that it be reformatted to something closer to these lines...

  1. What is this?
  2. Who, Where, When and How?
  3. Recent and Upcoming Coordinates
  4. Gallery of Recent Expeditions
  5. FAQ

In this layout, 'how it works', 'official' and 'unofficial', 'active graticules' and 'implementations' would all be summarised to one smaller section of 'who, where, when and how'. Known issues should be linked merely as a FAQ question (maybe the first one). Finally, 'Related Projects' would be a link to, rather than inclusion of, the community portal.

It'd probably be worth mocking up an actual example, but not for me at 1am... :)

Further thoughts? (obviously what I'm proposing is a rather major change to the wiki navigation, so please, nobody make any such changes till there has been a chance for fair objections to be discussed. --Nemo 15:15, 7 July 2008 (UTC)

Personally, I do think that much of the boilerplate can be cut down and/or farmed out to links, e.g., the FAQ (though I haven't done that in my prototype, it could certainly be added). Quite frankly, I think that just about everything static on Main Page should be transcluded anyway, if it's not going to change much. That way, people wouldn't have to deal with the formatting code on any new Main Page.
I'd been thinking of this for a while, and have a Wikipedia-like prototype (with a tad bit of out-of-date content) at User:Tjtrumpet2323/sandbox/Main Page (actually most of the code is taken straight from their Main Page). Please leave comments on my prototype at its talk page, while leaving comments on the general idea of reorganisation here. Thanks! --Tim P 15:49, 7 July 2008 (UTC)
Having only heard positive feedback thusfar, if I hear no further discussion, I intend to replace Main Page with an up-to-date User:Tjtrumpet2323/sandbox/Main Page on Friday 11 July at some time between 13:00 and 16:00 UTC. If you have any suggestions for improvements to the layout of the prototype, please let me know on its talk page. --Tim P 03:27, 9 July 2008 (UTC)
What stopped this happening? Your proposed front page looks awesome, I hope you implement it soon. --Kieran 10:48, 24 December 2008 (UTC)
I think there were problems with the server being slow at the time. I might go back through and try to merge the information from the current Main Page with my sandbox version, and re-propose the change. But I don't think that's really quite necessary anymore. --Tim P 02:42, 21 February 2009 (UTC)

problem with iPhone version

Here in Lisbon, Portugal, the iPhone version always gives the same coordinates in the midle of the ocean:

LAT: 38.557176 LONG: -9.228286

Does this happens to someone else, in some other place?

Yes, this also happens on my iPhone - Scottkuma 14:18, 18 September 2008 (UTC)

I have been using the iPhone app to attempt to geohash over the past week whilst away on holidays with no internet access, but have just discovered that this app almost always yields a completely different set of co-ordinates to the Peeron version online. Can anyone shed any light on this? --CJ 22:32, 1 January 2009 (UTC)

Degrees of Separation

I meet geohashers from my graticule and nearby ones, and they meet geohashers from ones near them in the other direction, and so on. It would be cool if there were a tool to see how many degrees of separation existed between any two geohashers. Just an idea. -Robyn 19:05, 3 October 2008 (UTC)

It would probably be pretty close to actual physical "degrees" of separation between graticules, unless you have a lot of people travelling! --Tim P 04:09, 10 October 2008 (UTC)
I know of geohashers from two North American graticules heading to Germany, a German one gong to Chile and another German one who regularly goes to Finland. Maybe it's about your physical separation from Germany. :-). -Robyn 04:33, 10 October 2008 (UTC)
And one who went to Germany recently :) Go intercontinental geohashers! --Thomcat 13:59, 13 April 2009 (UTC)
If you'll excuse the necro of this subject, as I'm trying to get used to the community I've just joined, this basically sounds like it follows Small World theory (see The Other Wiki, although it's a bit lacking of the diagrams than I'd have hoped would have been there). Localised cliques (largely groupings internal to a single graticule, but with some contact with direct neighbours), but a few long-distance connections between 'hub representatives': i.e. those who have had occasion to travel to other places and opportunity to join in an elsewhere's local groupings. Via the latter, anyone who isn't by circumstance a purely solo geohasher (or yet to break their duck) is likely to need a very low number of links to be connected by a (not necessarily chronological) sequence of physical meetings to just about anyone else who isn't working solo. Especially after a couple of years or more. And I reckon that if nobody has yet gone through and parsed the entire archive of meetlogs to at least track which Wiki-users have met which other Wiki-users, and drawn up some sort analysis or even just a plain linkage map (drawing lines between stated or presumed 'home' locations), somebody has been missing a trick. We could, of course, find groupings, even overlapping worldwide sets of groupings, who have managed to geohash without making any such form of contact-by-proxy between the various sets. If so, we may need to continue a bit longer (or allow for those that have gone inactive for one of many possible reasons), but eventually there should arise a single net containing the majority of us. --Monty 16:54, 28 January 2011 (EST)
There is the Meetup_graph which, while manually updated, performs a similar function. --mykaDragonBlue [- i have no sig -] 17:03, 28 January 2011 (EST)

Geohashing around the world

I am about to go backpacking in Europe for a couple of months and I have been pondering as to how best Geohash around the world.

My first thought is that I will be flying half way around the world and I figure that there must be some chance of flying over a hash point! Can anyone think of a way I could log my journey and check it against the graticules? Or is there another way of doing it?

If you have a GPS that's only a GPS - so, no phone or other device with a sender - the airline will probably allow you to operate it on the plane. You could then check the tracklog against the actual coordinate fractions. But do ask, because the stewards may mistake it for a phone and cause trouble on the way. And don't forget the fractions will change when crossing the 30W line.
Of course, if you don't tell anybody, you might just log the whole flight. It works best with an external antenna (so that you can turn it right face up) sticking out of your front seat pocket, close to the window. see -> http://www.everytrail.com/view_trip.php?trip_id=44569 -- relet 13:12, 9 December 2008 (UTC)

Also, I was wondering if anyone knows if my GPS will work in Europe or if I need to download something else to make it work? It is a Garmin 60.

The only technical differences between an american version and an european version of a Garmin GPS are the maps included (if any) and, with some models, the language support. Your GPS will need some time to recalibrate when first switched on after the flight but that's all of it. There are plenty of people in Germany who use american versions, as until a few months ago Garmin sold them much cheaper in the US than here.

Thank you, and I am look forward to finding random spots overseas! Kate 12:04, 9 December 2008 (UTC)

If you know your plans long enough in advance, don't forget to announce them - there might be a chance for a real meetup :) --Ekorren 12:33, 9 December 2008 (UTC)
Seconded. -- relet 13:12, 9 December 2008 (UTC)
When I fly, I get the coordinates of the day and then just keep updating the number before the decimal point to see if I'm going to hit the next one. You won't be allowed to use your electronic GPS receiver for takeoff and landing, but in cruise, you can see if it will work. It may or may not. (I sit in the front and have a wider view of the sky). If it has a mode to record tracks you could painstakingly go through the data afterwards, but the chance of getting right on a point is pretty small. Unless, that is, you meet the flight crew before hand and manage to sell them on the geohashing concept. Just make sure you're not misinterpreted as trying to hijack the plane. "Take this plane to N23°03'59.29", W82°15'20.45"!" -Robyn 12:42, 9 December 2008 (UTC)
Wow, Cuba! I think I'll be in serious trouble if the flight from Sydney to London ends up there!! Kate 13:24, 9 December 2008 (UTC)
Your GPS will receive satellite signals and calculate position anywhere in the world (it will take a while to figure it out after travelling so far, though) but if it shows roads and points of interest on the screen, and you use those, you may need to download local maps for it.
Edit conflict -- someone else has already answered while I was typing, but I'll add this anyway. -Robyn 12:42, 9 December 2008 (UTC)
The chance of getting a hashpoint in random flight is not that small for Kate. The 10 arc seconds rule for an air geohash leads to a 1:360 chance for every graticule crossed. From Sydney to e.g. London it is 150° longitude and 85° latitude, i.e. the chance of reaching a hashpoint is more than 50% on the flight. (It could be >95% if enough people would support my proposal here, because I've been having the GPS-logger-on-a-plane-idea for a long time. /end advertising). - Danatar 13:17, 9 December 2008 (UTC)

I'm back from over seas, but I found that my GPS did not work at all. I tried it in the UK, in France, Germany, all over Europe, in cities and in the country and it couldn't find any satellites. Perhaps there was an international button I needed to press? It has worked perfectly back in Australia again--Kate 20:10, 5 March 2009 (UTC)

Oh noes! I am quite curious about possible explanations. -- relet 20:15, 5 March 2009 (UTC)
The only explanation I could think of is that it failed to do a cold restart. When travelling for more than a few hundred km with a switched-off GPS, it needs to reinitialize from start like when first switched on. There's a technical reason for that based in the kind of signal the satellites send. In such a case, my old GPS (a first generation Garmin Etrex) first seems to find no satellites (it actually tries to get rid of some supposed measuring error), then, after several minutes of no fix, notices that something doesn't sum up from the saved values and asks whether I moved for a longer distance. If I reply with "yes", it forgets everything and starts reinitialization. Maybe you just didn't wait long enough and switched it off again before it could adapt itself to Europe? --Ekorren 20:44, 5 March 2009 (UTC)
No, good try, but that can't be it- I left it turned on for 2 hours in the outskirts of London one day (and it was 'searching' the whole time. --Kate 21:43, 5 March 2009 (UTC)

Map links

Lately, the map links always seem to come up showing Massachusetts, no matter what place the links were intended to go to. Dtobias 06:03, 19 January 2009 (UTC)

IIRC I heard something about Google changing their API, and no one has fixed the calculator yet. --The ru 08:12, 23 January 2009 (UTC)

Main page restructure

Right now (January 2009) we're rearranging some of the "static" pages, including the main page. It might seem a bit confusing at first, but we think the end result will be an improvement for both new users and regulars. If you disagree with anything we've done, post here, join #geohashing or just change it for the better! --The ru 15:24, 22 January 2009 (UTC)

I agree with the main page rearrange, but I don't think the quotes (except maybe the one about enjoying it pointlessly) and the hall of amazingness belong in How it Works. Maybe a highlights page off the main page? -Robyn 08:47, 23 January 2009 (UTC)
Actually, I'd like to see the quotes (randomly rotating,either auto or manually) on the front page, in the very top section under "welcome to the geohashing wiki" as they really give a feel for the game. Any thoughts? -- UnwiseOwl 01:18, 3 February 2009 (UTC)
I agree. Auto doesn't look like it's going to happen (discussion is on my talk page). It'll at least make people laugh at how insane we all are. --joannac 02:22, 3 February 2009 (UTC)
That's enough for me. Implemented. -- UnwiseOwl 02:44, 3 February 2009 (UTC)

My Vision of the Future

I'm poking around today, putting categories on photos, linking expeditions to their proper graticule and user pages, and creating expedition pages from rough notes on graticule pages. Some people don't want to do all this post expedition, and I don't really blame them. I envision an expedition upload form that does all this automatically. You tell it the date and graticule of the expedition and the names of the participants, you give it a list of pictures to upload and fill in the text of the report, then boom, everything is linked and categorized. You could enter all your expedition text on the upload form, or you could go back and edit the graticule, user or expedition pages the normal way. As you uploaded your photographs there could even be a checkbox to 'nominate this photo for the main page gallery'. If fewer than 4/8/12 photos were so nominated all would display, and if more, they could be chosen randomly, or weighted for users or graticules that hadn't had a photo in the gallery lately.

Is this possible? Is this an incredible amount of work? -Robyn 21:24, 26 February 2009 (UTC)

  • I like your vision! It takes me forever to upload all the things and get all the links right. Then lovely people still have to come along behind me and clean up! --Kate 21:44, 5 March 2009 (UTC)
I think a wiki is not set up for that kind of thing - the whole point of a wiki is that you can edit every little bit of it. Maybe someone can write a front-end page that will generate everything in proper wikicode format, which you can then cope and paste? I'm not sure if wiki code allows such interactivity.
It's a simple enough website to write - I could probably do it if I didn't have a report due soon. --joannac 21:58, 5 March 2009 (UTC)
Oh I didn't want to limit anyone's ability to edit every little thing. It's just a front-end indeed that I wanted. Copy and paste would do one page. -Robyn 22:06, 5 March 2009 (UTC)
You want a template. Like perhaps {{expedition}}. Anthony 21:49, 10 March 2009 (UTC)
Template:Expedition is definitely heading along the path towards that future. It replaces what generic cut and paste text, but the template still doesn't cross reference the expedition, and the template isn't the path of least resistance for the new geohasher who wants to show off his or her expedition without doing all that wiki stuff. Or the old geohasher who wants to upload the stuff and go to bed after a five hour expedition. I'm the one who harps on this and I forgot to link some of my expeditions into their respective graticule pages. It's a lot to do after biking or wading through swamps all day. Also while Template:Expedition is remarkably easy to use, at first glance it appears to be something complicated you have to know what to do with. I'm not sure a new geohasher would really start with it. I've not caught many using it (you can tell when people are using it, because the first save creates weird categories) who aren't experienced geowiki users. -Robyn 22:10, 10 March 2009 (UTC)

I suppose it is technically possible, although I am already in my pyj... er... I mean, it could be done, yes. But getting it all to function reliably (have a remote website upload an image to the wiki, stuff like that) and wrap it in an HTML form that's simple enough not to scare off newbies, but also flexible enough so anyone other than newbies would want to use it... that's going to take a lot of work, and I guess it would still be used only very rarely. Also, graticule and user pages don't have a standardised layout, so the envisioned Geohash Expedition Report Wizard would have to guess where to put in the links. The template isn't very useful either, imo... I just reuse the wikicode from a previous expedition. If newbies can't be bothered to read and follow the excellent expedition writeup guidelines, I think I don't want to read their reports ;-) --dawidi 22:58, 10 March 2009 (UTC)

I thought that it would hurl the links into a standardly named section. On graticule pages and userpages where no one cared they would just stay there, and where people cared they would rearrange them according to their preferences. I might not want to read their reports, but I'd like to have easily findable evidence that they went. -Robyn 23:11, 10 March 2009 (UTC)
It could even be implemented in some kind of {{auto expedition}} Template. What I am thinking of is to extend Template:Expedition with some pointers to the pages where you would like to cross-link your expedition. They would appear as dead red links, until you actually edit them. -- relet 23:19, 10 March 2009 (UTC)

Yeah! Or normal blue/purple links if they exist. That's in line with my vision. -Robyn 23:22, 10 March 2009 (UTC)

I'm so confused...

This is a great idea, but I'm confused. How do people meet up when everyone's coords are different? Is there one specific location for each graticule that is used each time? Also, is there a calculator somewhere I can use?

The fractional part of everyone's coordinates are the same - that means that people in an area of 1 degree latitude x 1 degree longitude can meet up. That's what we call a graticule. There's a map which shows the graticules and the hash for any given date here. Just zoom to your area and click - a pink square should show up with the location for today. It's the same for everyone in this area. HTH, -- relet 09:20, 6 April 2009 (UTC)

New User Comments

Wade says he finds the wiki very confusing. He wants My Home Graticule to be a navigation box link, with the home graticule set in User preferences. It's actually incredibly diffiult for a new user to answer the question, "is anyone doing anything in my city on Saturday?" Try it, knowing nothing, and just clicking on links that look promising. Is there a way to have any expedition for today or a future date with the Expedition planning category to automatially be linked to the current events page? -Robyn 05:34, 23 May 2009 (UTC)

You could link to the Category:Expedition Planning on Current Events. Unfortunately, you can't include categories into the page text itself. -- relet 19:59, 23 May 2009 (UTC)
Unfortunately that category is often dominated by planned but never attended meetups, so would not give a good picture. It's not so bad now, as Joannac just did a cleanout, but definitely wasn't the clean "what's going on in my neighbourhood?" answer he wanted. -Robyn 04:29, 24 May 2009 (UTC)
Actually, I didn't clean out many planning expedition. They're all sitting there pending further discussion. Also, it's not ingrained for people to actually create a page before they go, yet. --joannac 06:39, 24 May 2009 (UTC)
This problem has been addressed with the Current events option in the navigation bar at left. Now planned expeditions all over the world are automatically listed in one place. Comments from newcomers about improving wiki navigation are still welcome. -Robyn 02:11, 1 May 2010 (UTC)

I'd still like to see a home graticule link that is settable in the preferences...my current solution is that I have my home grat link on my user page. I go through there rather than typing Buffalo in the search bar...I'm going to claim it's faster, but I'm probably a bit lazy too. Pedalpusher (talk) 21:58, 23 October 2014 (EDT)

Coordinate History

Just curious if there's a page that lists every official Geohash coordinate since the start (2008-05-21)? If so, it'd be neat if that page could then be templated to a particular graticule, and going further, taking all those points and mapping them to see where every Geohash in your graticule has occurred. I'm pretty sure I could create the list of official coordinates as well as a templated version to add the graticule and corresponding map links, but I wouldn't know how to take all the coordinates and map them into one view of the graticule. Thoughts? --Wenslayer 05:36, 11 June 2009 (UTC)

Argh, sorry, just found Talk:Main Page/Archive 3#Complete list of historical locations including link to Geohashing historical data [amipsychic.net]. --Wenslayer 06:13, 11 June 2009 (UTC)
Check it out: User:Wenslayer/KMLGenerator. --Wenslayer 08:15, 11 June 2009 (UTC)

IRC Chat

Anyone think it would be a good idea to drop this link: Join Geohashing chat now in the main page? Mibbit is an irc chat over http, doesn't require a java applet to be installed etc.

Nooo! I use that link all the time to get to chat and I would be very confused if it all of a sudden I wasn't in Chatzilla. I think most people who are likely to want to use IRC chat wouldn't want their default client overridden. Maybe change the one in Help:Contents. -Robyn 19:30, 11 June 2009 (UTC)
Actually i was thinking of having the link in addition to the existing one, so that people who don't have an irc client can join easily. --Xore 19:55, 11 June 2009 (UTC)
I am on the fence about that. Most people who know what IRC is will either already have their clients set up, or want to use their own. Since it isn't very descriptive about what an "IRC channel" is, it might be better to leave it alone. However, I think we do want the geohashing Main Page to be as user (read non-geek) friendly as possible, so having a link to mibbit might be beneficial. Maybe a compromise: Join #geohashing chat on foonetic now or with your own IRC client. --aperfectring 20:01, 11 June 2009 (UTC)
#geo#ing  :) --Xore 20:07, 11 June 2009 (UTC)
Join #geohashing chat on foonetic with your own IRC client or using mibbit. -- relet 20:16, 11 June 2009 (UTC) (suggesting this order of things)
The order doesn't matter to me, but someone who doesn't know about IRC probably doesn't know what "mibbit" is. Maybe "using your web browser" instead? --aperfectring 20:19, 11 June 2009 (UTC)
test
someone with access to the wiki backend is welcome to replace the timestamp generator with something that will create a smaller random number --Xore 20:43, 11 June 2009 (UTC)
No worries about needing a smaller random number, the guestXXXX nicks aren't really any shorter, if I remember rightly. --aperfectring 20:48, 11 June 2009 (UTC)

Until we get a more geohashing-centric nick system working completely, I have included the generic link on Template:Getting_Started and Help:Contents --aperfectring 23:00, 11 June 2009 (UTC)

How about this? -- relet 08:46, 12 June 2009 (UTC)
I tried it 3 times and got different ones each time, so it looks good to me. Out of curiosity, how many different options are there? --aperfectring 12:21, 12 June 2009 (UTC)
The YAWL wordlist used contains 264097 entries. And they all look good with geo-. Well, mostly. -- relet 12:45, 12 June 2009 (UTC)
Well that might be enough for now, but if we start getting all popular, you might want to think about increasing that. <.< >.> Note: If 500 people click that link, there is an approx. 50% chance that two will have get the same nick, assuming that the selection is sufficiently random, and no type of exclusion list is used. My main concern, though, is if "people" is included in that list. That could prove disastrous for my typical greeting and farewell. --aperfectring 13:09, 12 June 2009 (UTC)

Proposed update to 1st sentences.

Proposal:

On the main page, I'd like to move the sentence "Geohashing is a method for finding an effectively random location nearby and visiting it, i.e. a Spontaneous Adventure Generator" from its current location above the random quote to being the first sentence in the "What is this?" section.

Discussion:

I occasionally direct geohashing n00bs to the wiki as a way of introduction. Right before sending the email, I follow the link as part of my final editing process, to "get the reader's experience." Every single time, I get to the wiki main page, and my eye immediately gravitates to the headline "What is this?" and I begin reading a section that is just a teeny-bit too "jump right in to the technical bits." I think that the sentence that is currently above the quote-banner, "Geohashing is a method for finding an effectively random location nearby and visiting it, i.e. a Spontaneous Adventure Generator" would serve better as the opening sentence to the "What Is This" section.
In my proposal, the front page layout would be changed from:
Main Page
Welcome to the Geohashing Community Wiki. Geohashing is a method for finding an effectively random location nearby and visiting it, i.e. a Spontaneous Adventure Generator. Geohashing was brought to you by the xkcd webcomic.
(Random Quote)
What is this?
Every day, the algorithm generates a new set of coordinates... [etc.]
to:
Main Page
Welcome to the Geohashing Community Wiki. Geohashing was brought to you by the xkcd webcomic.
(Random Quote)
What is this?
Geohashing is a method for finding an effectively random location nearby and visiting it, i.e. a Spontaneous Adventure Generator. Every day, the algorithm generates a new set of coordinates... [etc.]
The next time I'm struck by this oddity, I'll check back and, if there are no objections, I'll make the change. edit: forgot to sign: Ted 17:54, 14 July 2009 (UTC)

I've struggled a little with this as well. Support --Wenslayer 17:26, 14 July 2009 (UTC)

Glad someone else is thinking about the new user. This never struck me, but now that I read it, yeah support. -Robyn 17:58, 14 July 2009 (UTC)

Support definitely. I would also scratch "Community" and "i.e.". Juventas 05:51, 16 July 2009 (UTC)

Done. I think it's much more approachable, now. Thanks for the support. Ted 06:01, 16 July 2009 (UTC)
Damn does that ever look better. Thank you, Ted. -Robyn 06:17, 16 July 2009 (UTC)

Juventas' Server Configuration Wishlist

  • Allow uploading of kml/kmz files. Small, harmless, big potential.
My guess is that the kml file could be interpreted as HTML by the browser, allowing malicious code to be interpreted? We've had this before, can't be bothered searching atm. Will update later. --joannac 06:51, 16 July 2009 (UTC)
Interpreted as XML. Another user who was also interested in this looked into it and figured it was safe. I'm not a XML security expert. Juventas 07:01, 16 July 2009 (UTC)
Right. So now you have to convince the admin :) --joannac 07:13, 16 July 2009 (UTC)
  • Under "My Preferences" > "Watchlist" > "Add pages I...", enable as default. Most of the time I ask a question on a new image talk page, I get no response.
Not doable by me. Also unlikely to be done - users should have to sign up for email spam, not get it by default. --joannac 06:51, 16 July 2009 (UTC)
That would require "E-mail me when a page I'm watching is changed" to be enabled. I thought this was disabled by default. Juventas 07:01, 16 July 2009 (UTC)
It is disabled by default. I don't see the point of making this change then. --joannac 07:13, 16 July 2009 (UTC)
  • Under "My Preferences" > "Search" > enable all as default. The search is useless without it. I experienced much frustration with this as a new user looking for information.
I agree, but see further down. --joannac 06:51, 16 July 2009 (UTC)
  • Install the CAPTCHA thing so the leaders of this wiki can use their time for better things.
Also agree, see further down. --joannac 06:51, 16 July 2009 (UTC)
  • Address the recent intermittent performance problems. I'm guessing we're getting a free ride, but I'd like to hear options.
The wiki/fora is maxing out the CPUs on the server. The sysad is deciding whether to move to a new server, add more boxes, etc. This means that backend changes will be put on hold until he decides. --joannac 06:51, 16 July 2009 (UTC)
  • ...other things I'm forgetting, feel free to jump in.

Thanks to all those who have written bots to manage so many other things. Juventas 06:11, 16 July 2009 (UTC)

That's all server-side and IMO all worthy. For the captcha issue, you can weigh in here. -Robyn 06:20, 16 July 2009 (UTC)
Here's a stop gap measure. Change/improve anything. -Robyn 08:00, 16 July 2009 (UTC)

Offer of hosting

Hello, I'm davidc, geocacher, geohasher. You've doubtless met me on IRC already. Recently the wiki seems really slow - in fact today it was so bad, it was giving MySQL errors about concurrent transactions.

I'd like to offer my assistance. I own Sargasso Networks (www.sargasso.net, I won't link it here) and I have a couple of quad xeon servers dedicated to what I call "community hosting", aka "things I'm interested in and want to support". I would be very happy to host the wiki so it's off the xkcd forum server and has sufficient CPU power and bandwidth. We're a professional ISP with quality bandwidth etc, no Cogent etc blah.

As an aside, I also just registered www.geohashing.org and www.geohashing.org/[whatever] now redirects to wiki.xkcd.org/geohashing/[whatever]. This would provide an easy migration path if you want to move it to another server (since the same redirect can be set up in the reverse direction).

Let me know here, on my talk page, or on IRC. --davidc 22:33, 11 August 2009 (UTC)

Support -- thanks for offering, davidc! --Wenslayer 23:21, 11 August 2009 (UTC)
That's a big offer. Afaik, we generally have only voted on things involving wiki editing. I would think something like a server move would be entirely up to the administrators. My primary concerns would be whether the new hosting would have substantially better performance, and what would happen in the long term (say if davidc was unable/unwilling to continue). Juventas 01:17, 12 August 2009 (UTC)
Yes, it's up to the admins (who I'm not sure I've met or even know about, except joannac). From previous mediawiki installations on our network, I'm sure the new servers are up to the task (each server is 4xXeon-E5430 2.66Ghz, 4GB, RAID1+0 SATA, Gig-E uplinks to our 10-GE backbone) - a trial can be arranged easily enough anyway if desired. As far as long-term, I understand that's always a concern but let me say we've hosted things like Freenode since 2000, and my personal priority is always to ensure continuity, even though we haven't really used Freenode in the last 4-5 years. (As with other arrangements, staff would be given access to our NOC helpdesk). Let me say now also that my desire isn't control or anything, but simply to improve the performce for myself and others. I wouldn't request to be a wiki admin: the existing admins would have full ssh access to the wiki account. --Davidc 01:42, 12 August 2009 (UTC)
So, why is it slow lately? Is the server being bogged down by NWoodruff's giant image files? (Yes, I'm kidding.) Seriously, it seems likely to me that the current issues are solvable. It's not as though geohashing has become immensely more popular in the last few months.
Either way, the generous offer is much appreciated. --starbird 03:52, 12 August 2009 (UTC)
Geohashing may not have been, but bear in mind the server is shared with other things like the xkcd forums. --Davidc 22:42, 15 August 2009 (UTC)

Individual graticule pages seem to be particularly slow to load, compared to other things. Perhaps some of the transcluded stuff like maps and coordinates require complicated server operations? The really annoying thing is that the slowness continues even when you return to such a page with the browser back button; apparently, caching is suppressed. Dtobias 14:09, 1 September 2009 (UTC)

If this particularily affects graticule pages using the so called "quick links" template, it's a known fact that those quick links actually are very slow links. Try removing them from the page. --Ekorren 14:17, 1 September 2009 (UTC)

libwww-perl/5.828

Some bot is running against this wiki, with that user-agent. Anyone running a bot with that user-agent? It's running amok (300k+ hits per day) and apparently is the cause of the recent slow-down. --Davidc 01:16, 16 August 2009 (UTC)

I think it is some windows virus. It is now hitting our servers at our company. I don't think it has anything to do with a Geohasher or Geohashbot. --NWoodruff 12:43, 27 August 2009 (UTC)
I think that's the default user agent string when you access Web pages via Perl scripts using a standard library for this purpose. Dtobias 13:41, 3 September 2009 (UTC)

removing "Community portal" inclusion.

Would anyone object if I remove the inclusion of the site Geo_Hashing:Community_Portal at the end of Main Page? I think it contains a lot of information that does not need to be necessarily on the Main Page, adding to the bulk. -- relet 10:29, 24 September 2009 (UTC)

DNO - Danatar 12:59, 27 September 2009 (UTC)
Looks good. --davidc 10:34, 28 September 2009 (UTC)

Can we provide a landing place for people who have seen a marker in the wild?

My thought is this: i often leave a marker at a geohashing spot, usually with some sort of link to the wiki. I think it would be really cool if we could have a big callout box along the lines of: "Have you seen a geohashing marker? Let us know here!" and take them to a page where we can let them enter details of what they've seen and where. It would be great for us as geohashers to know that our efforts have been noticed, and we could help the visitors find out more about who left the marker. -- sermoa 12:15, 27 September 2009 (UTC)

Inspired by my own idea, i put a callout box on today's expedition, taking people to the talk page where i explained how to add a comment. It worked - Talk:2009-09-27 50 -1 - we got a response! :) -- sermoa 00:09, 28 September 2009 (UTC)

Following our discussion at the hashpoint, I have created Template:Advert and Template:AdvertTalk. You can see them on our expedition and talk pages. I think I might tweak the text just a little though now. --davidc 10:07, 28 September 2009 (UTC)

No need to use Template:AdvertTalk any more. Just use Template:Advert on both the expedition page and on its talk page, and it auto-detects which it's being used on. --davidc 23:25, 17 October 2009 (UTC)
Nice one! Thank you David. --macronencer 22:39, 18 October 2009 (UTC)

Create a page which can be linked to easily as (for instance) www.geohashing.org/marker or www.geohashing.org/I found a marker. This could then be a general landing point advertised on hash markers. This page could have a brief description of hashing, an list of areas the marker might have been (or link to Geo_Hashing:Current_events#Recent Expeditions and it's list of recent hashes) where people could find out about the particular expedition the marker relates to (if there is no direct link), and explain how to add comments. There's other stuff that could be added I guess, as long as we don't overwhelm people. --mykaDragonBlue [- i have no sig -] 23:51, 28 September 2009 (UTC)

I like that idea! Shouldn't be too hard to swing that, just a crash course on the sport. You could use a lot of the same information the Ambassador letters contain, if you wanted to have a template to work off of. --Oracle989 02:49 UTC 2009-10-12
I started something: Marker - please help to elaborate. ;) -- relet 08:28, 19 October 2009 (UTC)
That's a great start, relet! I have a suggestion for another item on that page: I think some landowners might be concerned that this kind of thing will happen to them again (perhaps they've heard of geocaching and are expecting more visitors in the future). Maybe we should have a paragraph explaining that this is unlikely in the near future due to the probabilities involved (unless they own a LOT of land!) --macronencer 11:22, 19 October 2009 (UTC)

Geo Hashing talk:Community Portal

It appears that the convention is to put general discussion on this page, so I'm moving the two discussion points from Geo Hashing talk:Community Portal to this page, and leaving a message suggesting people write here instead. The next two entries were moved from that page. --davidc 23:37, 17 October 2009 (UTC)

Main page image URL

I noticed that the URL on the picture shown on the main page is (accidentally, I assume) wrong - this address sends you to the Boston graticule map instead of the wiki's main page. Maybe someone with access outside of the wiki could change the redirection so it sends you to the wiki instead? And/or we could swap the picture for one with the wiki address, there should be enough of them to choose from. --Ekorren 19:04, 20 November 2008 (UTC)

That's a kind of common mistake. I assume that the map has existed before the wiki did. Therefore xkcd.com/geohashing and www.xkcd.com/geohashing redirect to the map - wiki.xkcd.com/geohashing is the only valid wiki address. I also think that it would be a good idea to have the redirect changed. -- Relet 20:02, 20 November 2008 (UTC)

Translation in French

Hi everyone, french-speaking Belgian geohasher here!

I'd love to help you translating the wiki into Molière's language. I'm not officially an interpreter, but my french is almost perfect (I actually say that just to pretend I am humble, but it IS in fact perfect), and I am good enough with computers to help, even if I'm not used to working with wikis.

Anyway, if you think I can help, please tell me so on my page (See? See? I'm playing with links!)

If you're not sure I'm a dedicated geohasher, you should know that even if I've been geohashing only once so far, I've already posted a nude picture of my formidable, hatted self. That should be enough for anyone I guess.

I should be able to proof-read content-wise. I speak fluently, but I am not a native speaker. And I support translations. -- relet 11:37, 7 July 2009 (UTC)
So, what should I translate, and how? If someone could give me the links, I could work on it soon. pierre 13:49, 7 July 2009 (GMT+1)


Hashpoint from 0001 to 0930

Sorry if this is answered elsewhere, but is there a hashpoint on Monday through Friday: midnight to 0930? I am in the Eastern USA. Thanks! -- LuxMundi 19:51, 5 November 2009 (UTC)

I think the answer to that is no, at your location. I'm in the UK and our local hashes are available for 24 hours because of the W30 rule, but west of W30 folks have to wait for the stock market to open for that day - except at weekends, of course, as the Friday opening balance is used. Hope that helps! --macronencer 20:43, 5 November 2009 (UTC)
I agree that you are correct, but it just seems strange to me that there are basically 2 whole days (47.5 hours) with no hash point (in this time zone). It seems like we should be able to use the previous days hash until 0930, or use the East of 30 coords, call it an "Early Riser's Hash". Today, we had 2 1/2 hours of sunlight, with no hashpoint, but sunset is at 1740, so I don't leave work until after dark. --LuxMundi 21:19, 5 November 2009 (UTC)
Yeah, I guess making hashes for 24 hours after their announcement for everyone would have been the fairer choice. I've never read the original discussion though. -- relet 16:39, 6 November 2009 (UTC)
I'm guessing that the original focus was on the 4pm meetups, and the idea was to leave just enough to time to get to them. As popularity grew, countries around the world joined in, people with 9-5 jobs went for evening hashes, the more adventurous attempted midnight mountaineering, and the capacity of the original idea was stretched to breaking point. I do feel bad about the unfairness. In Europe we really benefit from the W30 rule as there's always a hash to go to at any time (assuming it's reachable). If the rules were changed, I'd favour allowing the use of the previous day's co-ordinates until the new ones became available (for those west of W30) - I think that would be the easiest option as it would avoid complicated modifications to existing co-ordinate calculators. The hash point for a day would still be the hash point for that day calculated the same way as always, but the difference would be one of logistics: just allow extended use beyond midnight, depending on the region. The only trouble with this is knowing exactly at what point the DJIA is announced. If you were on a trip to a hash point at 0930 on the East coast of the USA and have no Internet then you would have a problem :) --macronencer 11:10, 7 November 2009 (UTC)
Being new here, when I figured this out, I thought it was really unfair that there wasn't a hash for a third of the day, but it makes sense because a new day is a new hash/potential adventure. Just sucks that early risers don't have an option. That being said, I don't think the current day's hash should just disappear at midnight. If I'm out camping or out on the town and decide to hit a hash at 1am, even though my phone says it's the next day, I don't consider it 'tomorrow' until I go to sleep. Since this whole concept is based on the Honor System, what if we set up the rule so that as long as you haven't "gone to sleep for the night" and it's before 9am, the previous day's hash is still open to you(the exception would obviously be the weekend/holiday days where there is a new hash ready and waiting). The Expedition page should be written up for that day's hash and times should be noted but not penalized. In other words, Thursday night at 12:37am(Friday morning in reality) I made it to the hash. I would then write up the expedition under (Thursday's) 2014-08-28 42 -78 and just note that I was out with friends and decided to try for the midnight hash but got delayed somewhere. Or I decided to go at 2am for whatever reason but before going to bed. Pedalpusher (talk) 11:29, 27 August 2014 (EDT)

Login CAPTCHA issues

The login CAPTCHA is a big problem for programs that need to login. Specifically, for me, Commonist can no longer login to batch upload images. Presumably other programs will have problems too - hashdroid for example?

I can understand a CAPTCHA on account creation, but I'm not sure why we need one on login - is there seriously a problem with programs brute-forcing passwords that isn't already being handled by the lock-out mechanism? (I don't know the specifics of the lock-out, but I do know I just locked myself out from my regular account for a while).

I note that the XKCD IRC wiki requires a CAPTCHA for account creation but not for login. I assume this is how our wiki used to be too.

I vote the login CAPTCHA is removed urgently! --davidc 20:55, 20 May 2010 (UTC)

Apparently it's only happening for my IP address. I guess I've locked myself out! --davidc 21:03, 20 May 2010 (UTC)
I would still like to see an exemption for Commonist. All too often I'm getting login failures - if I login as davidcx and then login as davidc, for example (neither with a password failure), the simple fact that I've been to the login page from this IP three times in one day seems to be enough to trigger the CAPTCHA. --davidc 23:33, 23 June 2010 (UTC)

HTTPS

Can we get a HTTPS server for the wiki? (It would be nice to have it a bit more secure, if it's not too much trouble to turn that on) -- relet 07:11, 9 July 2010 (UTC)

I second this —particularly as (AFAIK) any user login authentication will be sent in cleartext. Who is the correct person to ask about this regarding implementation of SSL on this Wiki? --Saxbophone (talk) 13:15, 9 June 2018 (UTC)

Can we make the "Discussion" button more visible?

The usual place where people comment on your expedition report is on its discussion page. Everything else is discussed on that page too. I would love to have that discussion blue/red link a little larger, to alert people that there actually have been some comments. Ideally, I'd like to have a largish button in the title bar saying "n Comments/Commentators/Discussion threads" - which could count either the number of users talking on the discussion page, or the number of sections including section zero (which might be easier). -- relet 07:14, 9 July 2010 (UTC)

machine parseable coordinate reference, datepages

Is there a source for daily coordinates that is reliably machine parseable. I'm currently using the datepages, but the format of the html code around the coordinates changes, both based on day of week, and when someone fiddles with it. Ideally this would be a very bare static file for each day, not processed through mediawiki to minimise server load. It should have the east and west coordinates separately, even when they are the same, and also the global coordinates. Alh 08:39, 28 July 2010 (UTC)

There should be several potential sources available, you could take a look into the Implementations page. My own Small Hash Inquiry Tool (aka anthill) offers a special minimum mode which is made to be a minimalistic source for further processing. I admit that I haven't really followed the developments of other people during the past months, so I can't give you an overview. --Ekorren 09:30, 28 July 2010 (UTC)

The usual way is to query one of the DJIA sources and use one of the implementations to calculate all the hashes you need.

The former checks three different sources for the correct DJIA and publishes it when two of them agree on the opening price. -- relet 17:16, 28 July 2010 (UTC)

Ambassador template

Anyone has a ambassador template I can start from or do I have to make a new one from scratch when I translate it? --Vswe 18:27, 11 November 2010 (UTC)

Template:Ambassador_geohash? --Crox 21:37, 11 November 2010 (UTC)
Oh, sorry for being unclear, I meant the images (Media:Ambassador-EN-GB.png for example). And I didn't meant a wiki template, more like a photoshop image or something similar. Couldn't be more unclear with my first sentence though. :P --Vswe 22:31, 11 November 2010 (UTC)
Well the first two pictures occuring in it can be found here and here and for the example graticule with coordinates you should probably take something from Sweden [if I'm guessing correctly that this is the language you want to translate it into?] like the Stockholm graticule - just take a screnshot from peeron would be my suggestion. Is this the kind of information you were looking for? --HiroProtagonist 23:38, 11 November 2010 (UTC)
I was wondering if there was something I could start from or if I have to do it from scratch. Apparently there isn't anything else to start from so I guess I have to make it from nothing. --Vswe 14:28, 12 November 2010 (UTC)

Categorization question

I just looked at Special:UncategorizedPages again and I'm not sure how pages should be categorized about expeditions that didn't take place and nobody ever intended to, for example 2010-05-05 45 -75. As far as I see we have

Is that about right?

Yes, as far as I can see. — Benjw  [talk] 15:42, 12 November 2010 (UTC)

Then what to do with pages that were just created to point out a good spot without any intention of somebody ever going there? I don't think that's "Expedition planning" but "Not reached - Did not attempt" is for actual expeditions... New category? Or should such pages just be deleted? --HiroProtagonist 03:26, 12 November 2010 (UTC)

I think what's happened in the past is that the text has been moved to the graticule page. For example, if the expedition page simply says something like "This is a good spot -- behind the bike sheds at NASA headquarters" but it doesn't look like anyone's tried to go there, you could just add that sentence to the "Hashes considered" section on the graticule page, or similar -- exactly where depends on how the page is organised -- and delete the unused expedition page. With some, it's hard to tell, so maybe leave them a month or two and come back to them later. — Benjw  [talk] 15:42, 12 November 2010 (UTC)

Problem with Google Maps lookup/link, 2010-11-19

The Peeron lookup map was a little slow, so I tried the Google Maps link. Nov 11 for 490 -74 (Newark NJ) was in Middletown NJ, according to this link. When Peeron came up, it gave a different location, close to I-195. The OSM link and Geohash Droid concur with Peeron. Can anyone determine what's wrong with the Google link, and how long it's been out of sync with other calculators? -- Jevanyn 15:18, 19 November 2010 (UTC)

which link did you use? and was it still wrong after Peeron updated? when in doubt, I'd recommend to use Ekorren's Hash Inquiry Tool, since it uses several sources for the DJIA value. --Crox 20:15, 19 November 2010 (UTC)

New user spam

Due to the many new users joining and spamming (the CAPTCHAs don't seem to help), something needs to be done.

Other thoughts/suggestions are appreciated. --joannac 21:53, 14 September 2011 (EDT)

Getting users to confirm account creation after sending them an email is never a bad idea, I think. Don't know whether it's already done either, though, and don't want to create an account just try it out.
Approval by a moderator should only be used as last resort, and only if the number of moderators authorized to approve accounts is large enough that approval is usually done within of minutes. If people are forced to wait for some moderator to return from an expedition, holiday or a phase of general ignorance of duties until they can finish their registration and contribute stuff, they probably won't come back after they are approved.
Also, by which criteria do you want to approve accounts? Some spam accounts have speaking names, other's don't, some legitimate user names don't really look different, and at that time there's nothing else you have to go by. You'll need a very good fortune-teller to tell apart legitimate and spam users before their first contribution. I currently think the risk of losing legitimate users weighs heavier than a few spam pages. --Ekorren 05:53, 15 September 2011 (EDT)
The only real way to rid our website from spam is to make it harder to spam our website than it is to spam other websites. Well, as in return on investment is much lower on our website than others. I would say as little time as a spam page exist on our site that the return on time invested it fairly low. We seem to have several users monitor the recent changes page and are able to delete spam pages within an hour of being setup.
Yes it is time consuming but it does appear to be working as a new user then sees his spam page taken down in minutes, that new user never posts another page to our site. I know there are thousands of spammers out there. But I do believe that the current method that we have appears to be the lessor of all evils. --NWoodruff 09:53, 15 September 2011 (EDT)
The problem is that that method can induce burn-out, which is a more insidious problem. -- Phyzome 14:14, 17 September 2011 (EDT)
The spammers' latest approach seems to be: create a user account (because you need one), create a new spam page, throw away the account. They don't care that the page is down in minutes or days, because they're paid by the edit. Once they've left a link and followed it from our site, they get paid. Removing it later just cleans up afterward. My opinion is, don't raise the bar for new members (how many legit new members are we getting?), unless it's a one-on-one chat with the user to make sure they're not Peggy. Yes, email confirmation will slow down the barbarians, but it's no replacement for the personal approach. -- Jevanyn
From the account creation page: "E-mail address is optional, but is needed for password resets, should you forget your password. You can also choose to let others contact you through your user or talk page without needing to reveal your identity." -> I would recommend we enable e-mail validation as a first measure. --Crox 07:59, 24 September 2011 (EDT)

Personally, I don't think the number of moderators needs to be high enough to allow approvals in minutes. Geohashing ain't exactly an instant gratification sport. Even if it took a couple of days, I'd think it would be okay. I'm afraid, though, that we will not be raising the bar very much. The spammers will just pay a MTurk'er type of setup a little bit to set up their account and then use it for spamming. But it seems like a reasonable next step. Jiml 13:34, 23 September 2011 (EDT)

Problems with peeron map?

I'm getting errors with the peeron map. It gives out an error message that says a new google API key needs to be created. After that it simply says "Your browser doesn't seem to be compatible with google maps." (it is. I have always used peeron maps to get the location of a geohash. Also, I tried three different browsers. I don't think they all are incompatible with google maps ;) ). So, whoever runs irc.peeron.com propably needs to create a new google API key... :/ --Bierhefe 10:53, 21 September 2011 (EDT)

Use carabiner.peeron.com instead and it should be fine. You may also want to check Ekorren's Geohash tool (see also User:Ekorren/Hash_Inquiry_Tool). --Crox 15:14, 21 September 2011 (EDT)

That solution is kinda a problem. We have a lot of links to http://irc.peeron.com in the wiki, and all of those will break with this "fix". Also, we have http://irc.peeron.com/ embedded deep inside the wiki in the map (or graticule ?) template and so the maps on most of the expedition pages don't work. Jiml 15:49, 21 September 2011 (EDT)

Perhaps ask zigdon to do some kind of forwarding? Dunno. Has someone pinged him on irc/emailed him? --joannac 16:19, 21 September 2011 (EDT)
Wait -- there are only like, a bunch of templates we have to change? What's the problem? --joannac 16:25, 21 September 2011 (EDT)
A lot of pages have actual links to http://irc.peeron.com/something?lat=33+long=33 that are part of the text, not from a template. Jiml 21:40, 21 September 2011 (EDT)
I went and changed all the graticules near me. We just need everyone else to do the same. --NWoodruff 09:53, 22 September 2011 (EDT)
Could someone with database access do a global search and replace from irc.peeron.com to carabiner.peeron.com? Many/most pages still contain the old address and the links don't work. Could this be put in a template so if the website moves again, only one template need fixing. Thanks for the excellent site. Sourcerer 08:30, 2 January 2012 (EST)
Better to have a bot do it. -- Jevanyn 09:37, 3 January 2012 (EST)

The Peeron map embedded in the expedition template is currently not displaying the correct coordinates. Is there anyone that has a clue? --Fasanen 08:31, 11 February 2012 (EST)

The Peeron map has said that "market data is not available" since yesterday (2012-04-16). Meaning today and yesterday, the map has not displayed coordinates for any graticule (and I tried all over- america, europe, asia, etc.). I'm not a computer person, so I really don't know what to do. Nor am I a wiki person. I can calculate coordinates on my own, so I'm not too worried, but still, Peeron is buggy. -MayorOfBoxTown 09:52, 17 April 2012 (EDT)

In the meantime, check http://relet.net/geco - it does basically the same thing, just more reliable. -- relet 11:11, 17 April 2012 (EDT)
It's blocked at my work :( MayorOfBoxTown 11:23, 17 April 2012 (EDT)
Huh, why is that? -- relet 12:19, 17 April 2012 (EDT)
Dunno. A lot of things are that shouldn't be and vice-versa. Pandora is, but Tumblr isn't, so I just stopped trying to figure out the logic of things here. -MayorOfBoxTown 15:15, 17 April 2012 (EDT)
FWIW, relet/geco is semiblocked at Hijackals current work, too. I get a page asking me warning about potential dangers, but can click something along the lines of "I know, everything I do will be logged" and get to the dangerous DJIA. This happens to a few privately operated pages, but not to many. The black/grey/whitelist there depends on whether one uses Wifi or wire, and status within the organization, though. In some random way we haven't figured out yet, my supervisor's wired PC isn't allowed on some pages my wireless notebook can access... --Hijackal 22:24, 17 April 2012 (EDT)
Interesting. I was just curious what kind of greylist that server landed on. Might be something co-hosted, or essentially random, but still. Well. Your Internet Is Broken[tm]. -- relet 02:54, 18 April 2012 (EDT)

Abortive responses from server?

I'm a bit fed up, last weekend I spent several hours trying to upload a set of photos, and setting report text (finally suceeded), but the site doesn't respond nicely to me. No (obvious) problems with any other web-site, but I'm editing this in Firefox (currently still working, but I expect it to go bad shortly) and the Internet Explorer 'source' of the page that hasn't loaded terminates at the '<tr' text (indeed, no no closing angle-bracket/greater-than) immediately after the '<table class="infobox"...' tag. On the machine next to this one IE has paused part way through the A HREF for the 'geco' link for Today's Location on the page (the one for my home graticule) that I'm viewing.

Firefox on the other machine is just waiting for wiki.xkcd.com, while this one is currently still working, but I fully expect it to fail, perhaps while posting this. Again, no other website is doing this. So: Browser problems? (But: Multiple browsers) Machine problems? (But: Multiple machines) ISP problems? (But: Not happening to any other websites.) Site problems? (But: Haven't found anyone else complaining)

I've been a bit quiet about this, but it's one reason why I've left a bit of a backlog of 2011 reports not fully (or actually) completed, or at least yet uploaded all pictures I had intended, and managed to let it slide. Any ideas of what to do? --Monty 20:51, 13 January 2012 (EST)

I did some additional checking, during a free moment, once I'd outstayed my apparent browsing limit on the neighbouring machine to this. My home graticule page for Sheffield, UK appears to stick (in IE) at 497th character whehn checking the source (Firefox just stops responding). Page for Blackpool, UK (same URL length, thus assumed same HTTP header overheads) also stops at 497th character, albeit a different exact point in the source, with (among other things) differing lengths of neighbouring graticule names being already part of each truncated source. Both figures include an assumed 1 byte for LF/NL (47 vs 48). I also checked the 'Gibraltar' page and 444 chars+47LFs give 491, but with a URL length difference of 16, so (whether you assume header counts towards 'traffic length' or not) not so neatly the same value, or even would be with multiple mentions of the URL during handshaking, but very close. Not going to preview this, because last time I tried that I got the same server non-response and could procede to post, so going to have to hope I've not left rogue formatting in.--Monty 09:01, 26 January 2012 (EST)
Updated update: Just now finding that Peeron links (via ActiveGeohasher) are complaining about that invalid Google API thingy, I get redirected to the XKCD main page. While I'm still waiting for the first browser tab that I tried to open to load up the Sheffield graticule page. I'm really wanting/needing to make some Wiki updates, but this is a bit annoying... --Monty 23:49, 24 February 2012 (EST)
Well, I'd not much to say, recently (did some expiditing that needs writing up, and even reading the site, or at least something like Peeron, for absolutely every day's possible expeditions), but regret I'd not even been writing anything so never noticed before, but the situation may have changed. I don't know why, but I'm so far (cross fingers!) today still able to post without getting time-outs on pages. So, whatever it was (website, webserver, one ISP or other, local network, personal machines' interaction with the OSI stack, browser updates..?) it might be fixed. Knock on wood, eh? --Monty 13:23, 5 April 2012 (EDT)

Flags represent countries, not languages

See How Should Language Selection be Displayed on the Web?.

In Spain there are four official languages, and Spanish is spoken in more than 20 countries. Toño 10:23, 28 February 2012 (EST)

I agree. But I also think that the most correct solution is not always the most helpful. The point being, if you really stand in front of a wall of text in a completely foreign language, you scan for visual clues first. And when you see a flag you will at least get a version that can probably be understood by someone from that country. I have no idea for a better symbol, unless maybe a big stack of flags that when clicked leads you to an extended selection. I live myself in a country where, when clicking on "your" flag, you have a 50% chance that you do not get to read the language you are speaking... still it's easier than finding the words Nynorsk or Bokmål or Norsk or Norwegian on a wall of text, possibly written in characters that I am not even used to. I'm playing a bit of devil's advocate here. -- relet 12:38, 17 April 2012 (EDT)

This should go without saying, but...

An April Fool's joke that renders the site unusable is really, really, really, really obnoxious. I've lost time, money, and the fun of writing up an expedition over this shit.

If people can't use the website, geohashing ceases to be fun, and it dies. Do you understand that? Whoever is responsible: please undo your joke, congratulate yourself that you've succeeded in pissing someone off, and please, please, please: don't do it again. Michael5000 17:22, 31 March 2012 (EDT)


I have no idea what you're complaining about. The site looks fine to me. If you're having issues you can always figure out the geohash location for yourself. The formula is available in multiple places --Nameless 19:05, 31 March 2012 (EDT)

Yes. I used one of them, and went on a geohashing expedition. Then I thought I would write it up, which is the function of this wiki.

Listen. I LOVE geohashing, really love it. And I love being part of this community. But this joke, ha ha ha, is pretty unnerving: it reminds me that I've plowed hundreds, probably thousands ,of hours into an activity that centers around a website which I have no control over whatsoever. Seeing the site being disabled so cavalierly is... sobering.

Thank you, I suppose, for not jeering more than you did at my concerns and lost time when granting me a workaround. Michael5000 19:47, 31 March 2012 (EDT)

For the records: I'm with you there Michael5000, and have complained as well. I just hope it will not happen again. -- relet 12:30, 17 April 2012 (EDT)
Any chance you could mention what it was that pissed people off that much? I happened to be offline during the time. - Mampfred 17:47, 17 April 2012 (EDT)
The wiki was rotated 180 degrees using a css rotate style, because of something with Australia. Scrolling (and moving the cursor) in edit boxes is pretty broken when up and down are turned. -- relet 18:26, 17 April 2012 (EDT)

For the records: I thought it was funny. If you don't like it, turn your display upside down. If you really don't like it, come back on April 2nd. The wiki is upside down? Well, the server might even be down sometimes. Life goes on. We're gonna be like three little Fonzies here. And what's Fonzie like? ;) - Paintedhell 04:07, 18 April 2012 (EDT)

I didn't say I don't think it was funny. But it didn't work correctly and didn't get fixed. -- relet 04:41, 18 April 2012 (EDT)

Please, allow bigger files (at least 2MB)

Resizing every single photo is quite irritating mkoniecz 01:29, 23 July 2012 (EDT)

The limit was 2MB last time I checked. I agree that it is irritating - we used to have it pretty high, but experienced the server running out of memory when it had to resize too many pictures at the same time. I would support raising the limit if it is maintainable. -- relet 03:03, 23 July 2012 (EDT)
Weird. Upload of file smaller than 2MB failed. So - lets make it 3MB. mkoniecz 03:14, 23 July 2012 (EDT)

Is it possible to extend mapimg tag to include also globalhash location?

It would be nice to have possibility to check for this 1/86400 possibility without checking separate service. mkoniecz 11:06, 23 July 2012 (EDT)

Randomness and The Algorithm

Has anyone done an analysis of the randomness of The Algorithm's decimal parts? (... hence the randomness of the Dow values?)

Just wondering.1PE (Canberra) 02:55, 11 September 2012 (EDT)

I think[citation needed] that it's generally acknowledged that the md5 hashing algorithm produces pseudo-random results. The Dow values aren't pseudo-random at all, although their last few digits might be. As for an analysis of geohash coordinates, the results of a small test are at the bottom of the "The Algorithm" page; I don't know of any others. (Note that globalhashes are biased towards the poles, because of the shape of the Earth.) The data for past coordinates is simply a list of DJ opening values such as can be obtained from your favourite reliable source. — Benjw  {talk} 10:07, 11 September 2012 (EDT)
Yup, there's actually some on the page you linked to. :D -- relet 17:21, 11 September 2012 (EDT)
Hmmm.... pretty red dots, but there must be a listing of the historical Dow openings somewhere. I'll look for that. 1PE (Canberra) 19:38, 11 September 2012 (EDT)
Once you find it, I'd love to see just the points since the start of this some 7½ years ago (east and west, of course). --Thomcat 19:53, 11 September 2012 (EDT)
Although, of course, the original comic wasn't published until May 2008 despite using a 2005 date, so it's only 4½ really. — Benjw  {talk} 23:55, 11 September 2012 (EDT)

Re: What is This?

The descriotion appearing on the main page was recently changed by The Muscovite. (His user name is in Russian, which I can't type right now.) I almost rolled it back outright because of the wording, but once I parsed it mentally, I adjusted the wording a little. It might be useful to have several people write their own "what is geohashing?" descriptions. Also in future, maybe brand-new geohashers shouldn't be allowed to edit the main page without someone reviewing it (not that it can't be adjusted / reverted by anyone at any time). -- Jevanyn (talk) 11:13, 26 February 2013 (EST)

New feature: Recent non-expeditions

I suggest a new front-page feature: "Recent non-expeditions". This would allow enthusiashs to document interesting hashes that are impractical, potentially dangerous, etc. I offer as an example 2013-03-15 -34 149 that is very near an interesting Google Maps feature: An aircraft pictured in flight. I can't justify going to the hash (70km each way) but created the 'planning' page 2013-03-15 -34 149 because there might well have been other geohashers going along the nearby highway who could easily detour 2km and do the hash and 'see' the Boeing 737. 1PE (Canberra) (talk) 00:37, 15 March 2013 (EDT)

Okay, that's almost 2 weeks for comments. You make your mind up.1PE (Canberra) (talk) 10:01, 28 March 2013 (EDT)

Links to carabiner.peeron.com broken

Hi all, with the shift to a new month, I'm seeing that the links to carabiner.peeron.com are not expressing the date correctly. Namely, the day portion is missing the leading zero.

For example, the URL for today from the Frederick, MD page is http://carabiner.peeron.com/xkcd/map/map.html?date=2013-04-6&lat=39&long=-77&zoom=9&abs=-1.

It should be http://carabiner.peeron.com/xkcd/map/map.html?date=2013-04-06&lat=39&long=-77&zoom=9&abs=-1

It's easy enough to realize what's going on once I land on the peeron page but I think it's worth fixing.

Thanks. OfficeLinebacker (talk) 15:32, 6 April 2013 (EDT)OfficeLinebacker

The link from template (the one on the right with all the others) is correct on Frederick,_Maryland: (http://carabiner.peeron.com/xkcd/map/map.html?date=2013-04-06&lat=39&long=-77&zoom=8). The one that had to be fixed is the one in the text of the page - I've just replaced LOCALDAY with LOCALDAY2 and it seems to be good now... (not sure where those are defined) --Crox (talk) 18:44, 6 April 2013 (EDT)

Cheers, Crox! OfficeLinebacker (talk)OfficeLinebacker

Standard graticule page format?

Hi, I'm fairly new here. I was recently going through different graticule pages looking for ideas on how to improve my home graticule's page and I was somewhat surprised to see that there is no standard formatting, or really any common formatting across graticule pages. There are so many different ways each is laid out, not only is it difficult to determine how I should proceed, but some pages are just plain difficult or bothersome to navigate due to the way they're formatted. They contain quite a bit of useful information, so it's kind of a shame that these pages haven't been streamlined yet. If I may be so bold, I'd like to propose we put together some kind of standard format for these pages. It would make things a lot easier to navigate and understand, especially for newcomers like myself. Mystrsyko (talk) 13:55, 30 November 2013 (EST)

Welcome to the greatest game on Earth, Mystersyko. Regarding graticule page format, I think the community would want to hear your specific ideas. Certainly there's room for improvement. But not having a cut-and-dried format has allowed local communities -- which often means a single person, of course -- to set up their home graticule the way they like it, and a universal format that undid their work would probably be frustrating to a lot of people. (As somebody who has pioneered a lot of grats, I consider getting to set up the graticule page part of my reward for getting there first -- with the proviso, of course, that it's a wiki, so if you don't like how I set it up, you can show me how to do it right.) Part of the reason you are confused, I suspect, is that you are from Chicago, which has the weird "shifted graticule" thing going on. I don't understand the logic of the shifted graticule, and frankly it doesn't quite seem cricket to me, but at least one person in Chicago must have liked the idea at some point, and if they are still active you'll probably need to either learn to love it, talk people out of it, or (most likely) just ignore it and focus on the conventional grats. Happy geohashing! Michael5000 (talk) 03:17, 1 December 2013 (EST)
Yeah, I understand the desire and to some extent the need for individuality when setting up a graticule page. I guess my idea is born more out of occasional poor formatting than the differences between formats. Some examples I see are how Aurora, Illinois is basically just a list of expeditions, which isn't terribly interesting and doesn't really give a good idea of how active it is or what character the graticule and it's hashers have. Atlanta, Georgia, has, to me at least, an unneccessarily long list of "Geohashes scouted", which discourages readers from getting as far down as the beautiful tables of expedition dates and the list of local hashers. Chicago, Illinois is nearly half discussion of the mentioned "shifted graticule", which like many things on many wiki pages, seems to be a fairly dated discussion. On the other side of things, I like how Portland, Oregon's list of hashes is limited to the 10 most recent, and further down is a nice little history of the graticule. Newark, New Jersey also has some good formatting ideas with older dates archived on other pages to reduce the clutter, and inactive local hashers archived as well.
I see all of this room for improvement, and all of these great ideas, but no coherency. I know a wiki is inherently a work in progress, and I find traces of that work here and there. I'd like to see the place continue to improve, but being a newbie I can't bring myself to jump in a start changing things around on everyone. I guess to sum up everything I'm trying to say; hi, I'm here to help, lol. :) Mystrsyko (talk) 22:31, 1 December 2013 (EST)

Navigation bar "broken"? Tools list is missing

When updating an expedition, or rather trying to, I realized the Upload File link and other tools (I think the category was "Special pages" are missing completely from the navigation bar on the left. Is this intentional, and how is one to reach it now? Maybe I'm daft, but it sure took me some searching time to find the page. :( Rincewind (talk) 08:07, 14 January 2014 (EST)

It's there for me under the tools section. Maybe a CSS issue, try hard refreshing ... or panicking. - Mampfred (talk) 10:02, 14 January 2014 (EST)
The whole tools section is gone for me (Firefox and IE)...

After checking your reply, it was there on the main page (sans the Upload file entry), after purging the cache it's gone, again. Also, the bar is just unformatted lines of text without the usual box around them. Looks broken to me... Anyone familiar with the site's CSS care to check this? Rincewind (talk)

Erasing a Page or an uploaded photo

If I create wiki page with wrong URL and title: How can I erase it completely? And if I load up the wrong photo: How can I erase that from my uploaded photos? Greetings--Q-Owl (talk) 13:15, 13 May 2014 (EDT)

To really delete a page or an uploaded photo simply edit the page/photo and replace the current text with the delete template, e.g. {{delete|reason}}. At some point, an admin (i.e. Joannac) will come along and delete the page permanently. - Mampfred (talk) 18:58, 13 May 2014 (EDT)
with braces ("geschweifte Klammern") or box brackets ("eckige Klammern")? --Q-Owl (talk) 04:28, 15 May 2014 (EDT)
with braces {{ }} --GeorgDerReisende (talk) 10:08, 15 May 2014 (EDT)
Exactly as I wrote it so braces it is :) - Mampfred (talk) 14:00, 15 May 2014 (EDT)

further Translation

On wiki.xkcd.com/geohashing/Geo_Hashing:Community_Portal are only very few pages to be translated. Which are the next to be translated? --Q-Owl (talk) 06:50, 18 May 2014 (EDT)

Most Active Geohashers

I would like to propose and start a discussion on the creation of a page similar to the Most active graticules page for users/geohashers. I kind of built a small example with expedition reports from January-April over here. Mystrsyko (talk) 11:18, 29 May 2014 (EDT)

Very good idea! --Q-Owl (talk) 17:01, 7 July 2014 (EDT)
It's done! Most active users is now up. Years prior to 2014 will be added as I get through them. Mystrsyko (talk) 22:48, 9 January 2015 (EST)

Graticule Twinning

It's like twin towns. Has anyone tried this? --Sourcerer (talk) 12:02, 1 June 2015 (EDT)

With further thought, A Tale of Two Hashes achievement is quite similar to this idea. --Sourcerer (talk) 09:39, 6 July 2015 (EDT)
The idea is even older than the ToTH achievement (which came up in 2009), see 2008-12-27_51_8... --Crox (talk) 13:19, 19 October 2015 (EDT)

Allow KML file uploads

These open in Google Earth. For example I could make a kml file with pushpins for each of the expeditions in 52, 1 and clickable links to the expedition pages. Creating the simple kml file might be easy to automate for any graticule. Users might also upload kml tracklogs for viewing in Google Earth. --Sourcerer (talk) 09:39, 6 July 2015 (EDT)

I wholeheartedly second this. I've been sharing tracks like this with non-GPS-savvy users for a long time now, and they usually find them very easy to use as they have used Google Earth before. Onicofago (talk) 22:01, 22 October 2015 (EDT)

what3words web and phone apps

The entire globe is divided into 3x3 metre squares, each uniquely identified by three words.

For example "shorten.clock.chew" is a volcanic pool at Rotorua, New Zealand. This is accurate enough for geohashing. I've had hours of fun exploring and looking for fun combinations. So humans.slimy.pines is close to Sidney Opera House. You could summon emergency services to a wilderness accident at bypassed.then.react, pinpointing the victim to a 3x3 metre square. To make this work, the victim and the rescuer both need the app on their phone. 3G access is not needed because the database is small enough to be held on the phone. Of course GPS is needed. I wonder if this tool might inspire some new geohashing games or ribbons. --Sourcerer (talk) 11:55, 25 September 2015 (EDT)

It occurs to me to wonder why we need to identify each 3x3 metre square with a set of words, when we have a similar tool already -- latitude and longitude. What problem exists with using "52.21098, 0.07654" that is solved by instead using "dismember.artichoke.tweedledee"? — Benjw  {talk} 14:09, 25 September 2015 (EDT)
The numeric notation is non memorable. I live at aimlessly.worm.gourmet which at the very least makes me smile. If you put a typo into the numbers, it's valid data but a but wrong location. If you put a typo into what3words, it'll most likely tell you, no such location. --Sourcerer (talk) 10:27, 28 September 2015 (EDT)
Of course latitude and longitude give you a good idea of the location. The three words don't unless you load up the app. --Sourcerer (talk) 02:58, 29 September 2015 (EDT)
I came across this website years ago. I dismissed it because the three-word phrases don't translate. They claim to work in multiple languages, but the location for "little.white.house" is not the same as "poco.blanco.casa". It's basically a random word encoding, and their word database is proprietary. I don't know how widely used it is. -- Jevanyn (talk) 14:09, 30 September 2015 (EDT)
I'll use it to get Amazon drones to deliver beer to my tent! --Sourcerer (talk) 11:29, 31 July 2017 (UTC)

Closest consecutive geohashes?

I noticed that 2016-02-12 Friday's (Lat°43.832 Lon°23.064) and 2016-02-13 Saturday's (Lat°42.713 Lon°26.716) west of 30 are pretty close - in (42,-88) they're about 5.4km apart. Has anyone kept track of the closest daily consecutive geohashes by minute? Petek (talk) 15:22, 12 February 2016 (EST)

5.3 km or about 3 miles. Interesting and quite unusual. I've been watching the coordinates around 52,1 closely for the last 14 months and nothing has got that close. --Sourcerer (talk) 02:42, 13 February 2016 (EST)
The distance between 2013-12-07 53 9 and 2013-12-08 53 9 was 1.7136 km. --GeorgDerReisende (talk) 05:13, 13 February 2016 (EST)
Not consecutive, but these two: 2013-04-07_45_-123 and 2013-03-27_45_-123 were about 100 feet and 10 days apart. Jiml (talk) 14:52, 23 February 2016 (EST)
Consecutive and reached: 2012-11-23 49 8 2012-11-22 49 8. They are about 3 kilometres apart. Just wanted to add them ;) - RecentlyChanged (talk)
For east of -30, 2017-11-16 & 2017-11-17 were ridiculously close together. For more extreme results, calculate the distance in the 89N graticules. Here at 53N, they were about 40 metres apart. -- KarMann (talk) 14:34, 18 November 2017 (UTC)

Coordinate computation mismatch

I just realized, that the coordinate computation seems to mismatch between implementations. I did an expedition on 2018-05-19 and when starting my report, there's a mismatch in the coordinates. The meetup template shows the coordinates as 51.4591310, 6.8416041, whereas other implementations disagree:

  • geohashing.info: 51.06876635, 6.87614349
  • crox: 51.068766° N, 6.876143° E
  • GeoHash Droid screenshot

Anyone having an idea what went wrong here? Did I reach the correct coordinates? -- pah U+110DB.png (talk) 11:27, 21 May 2018 (UTC)

Hello, as far as I can tell, the reason for the mismatch is that peeron does not have the DJIA for that date: http://carabiner.peeron.com/xkcd/map/data/2018/05/19
An implementation that 1. relies only on peeron and 2. does not handle an error/empty value is at risk of producing wrong coordinates.
According to three separate sources (Google, Yahoo and WSJ), the DJIA opening value for 2018-05-18 is 24707.72. This is the info that geo.crox.net uses to calculate the coordinates displayed on the poster, and, as far as I can tell, the info that geohashing.info / GeoHash Droid use as well.
Regards, --Crox (talk) 12:20, 21 May 2018 (UTC)
Update: User_talk:Zigdon#DJIA_opening_value_for_2018-05-18
Thanks for checking and notifying Zigdon about it, Crox! I'll take my expedition as a success then. :-) -- pah U+110DB.png (talk) 12:48, 21 May 2018 (UTC)