Talk:Implementations

Topics 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.

Atom feed 30W-compliance

I just added the atom feed and it seems to be 30W-compliant

After some thought, I suppose it would be somewhat compliant. However, in some cases it's too compliant, or compliant in the wrong ways. After 00:00 local time, it automatically switches to the next day, but keeps the old Dow value and rehashes. East of 30W that behavior is desired, since you want to use the previous day's Dow anyway. West of 30W, however, it means we get an "intermediate" hash that's invalid for us. This much has always been a problem with the implementation. Then, sometime after 09:30 ET (I don't know precisely when), it detects the new Dow value and updates the hash... but it does it both west of 30W where it is needed, and east of 30W where it is undesired. In that case, you would get some other "intermediate" using the current Dow with the current day, which isn't what you want. That's a new problem the 30W Rule created.

In summary, it seems to produce invalid hashes between 00:00 (local) and ~09:30 EDT (UTC-4) west of 30W, and between ~09:30 EDT (UTC-4) and 24:00 (local) east of 30W. That is, it's invalid from 00:00-~06:30 in US Pacific Daylight Time (UTC-7), from ~14:30-24:00 British Summer Time (UTC+1) or from ~21:30-24:00 Australia Western Standard Time (UTC+8). I'm not even sure I know what would happen with the feed in New Zealand, where 09:30 USEDT = 01:30 NZST the next day. It'll be even worse come late October/early November, when Australia/NZ switch into DSTand the US switch out... the gap will become 2 hours wider over a couple weeks' time. And of course, these problems are mitigated over weekends, when you have several identical Dow values in a row. Someone should check this out before the weekend, as I'll be busy until Friday 19:00 UTC. If anyone does, and has thoughts, hit me up on my talk page.

Sincerely, your friendly local (global?) 30W-compliance "expert"... --Tim P 15:34, 29 May 2008 (UTC)

I have just updated the feed so it should be 30W compliant. Let me know if it's still a problem. --Xxv 18:03, 30 May 2008 (UTC)

Shell script implementation

Could someone check how well this works on OS X? Another user said they had some problems but never followed up with details. I think they ship with bash and wget. However, they may have an ash as /bin/sh, like most other modern operating systems (except the one *I* hack on... sigh.).

I have taken the other script, which had duplicated the previous version of the code except for the while loop that actually printed the final output, and changed it so that it simply calls the actual implementation. It would be impractical to have to edit two identical portions of code every time when the algorithm part can just be factored out. If this fails on your setup, please comment.

There is a bug where wget-only sites will have to look at "fetch: not found" every time, but anything else would have messed up the columns :) The order of alternatives can easily be swapped to try wget first, though (or install libwww-perl!). The problem with curl is that it does not exit with a failure status when the data is 404. OpenBSD's date... just doesn't have the ability to say "yesterday", as far as I can tell. Maybe I'm missing something obvious. -- Decklin

iPhone Implementation

Last night I finished a rough implementation of this to the iPhone 2.0 Beta SDK. Right now it uses your current location and date and then does the math, then gives you a map with the destination address along with directions to there from where you are at. This will be even more useful if the next 3G iPhone come with GPS, until then it uses it's less accurate cellular and wifi location tools to locate you. I plan on adding a way to select your date and your desired graticule as well. Eventually I'll also investigate filtering of the results in watery areas. I can't distribute it currently, but as soon as I can I'll make it available. -- Shakedown

Flickr?

So, there're likely a bunch of media-sharing sites out there that allow users to tag content; and some subset of those will have geohashing users. I've added a link to Flickr's RSS feed for "photos tagged geohashing" to this page, but I'm not entirely convinced it belongs here. Please feel free to move (or simply remove, I supose) it. --Tapin 03:07, 2 June 2008 (UTC)

Suggested alternatives support added to the official implementation

I just added (with User:Cwolves doing most of the work) support for suggesting alternative meeting points, if the official point is difficult/impossible/illegal to get to. I know there are still a few bugs in the voting buttons, but I'll be working to fix them. Any issues should be reported here or in [#geohashing]. Zigdon 21:24, 8 June 2008 (UTC)

Display meetups for adjacent graticules

Has anyone ever suggested having the official implementation display all the meetups in the eight graticules adjacent to the one selected? This would be another handy way to easily spot possible alternative meetup spots, especially if the graticule has members concentrated on the edge between two or more graticules (like New Orleans, for example).