Implementations/Web services

From Geohashing
Revision as of 07:47, 10 April 2012 by imported>Relet

RSS/ATOM

geohash.info

This implementation IS FULLY 30W-compliant.

Subscribe to a feed that updates as soon as each day's meetup is calculable for your graticule:

http://www.geohash.info/srv/feed.php?lat=LAT&lon=LON

If you visit the URL with no parameters, you will be prompted for your graticule coordinates.

  • Dow data comes from the peeron service
  • To view source, drop the parameters and change the extension to .phps -- this currently works for all PHP files in geohash.info/srv/
Quirks
  • The script estimates your timezone based upon your longitude, and uses -04:30 as the timezone of the Dow. Therefore, the update times may be off by as much as an hour or two. Shouldn't be an issue, since they'll be around midnight for most people.
  • For non-30W users, the feed will be empty between midnight and 9:30 AM -- this should be acceptable, since most feed readers keep entries that have dropped off the end of the feed. (This behavior may be changed in the future.)

GeoRSS feed

This implementation IS NOT 30W-compliant.

You can subscribe to a feed (in GeoRSS format) that will give you updates on a daily basis[citation needed]. Updates include the "best guess" address of the location as well as the specific latitude/longitude coordinates.

http://atlas.freshlogicstudios.com/Features/Experiments/Xkcd/Xkcd.ashx?Latitude=38&Longitude=-91

For example, here's the GeoRSS geohash for St. Louis.

This GeoRSS feed is used to power the Atlas geohash implementation.

Atom feed

This implementation IS FULLY 30W-compliant.

You can subscribe to a feed that will give you updates on a daily basis:

http://staticfree.info/geohash/atom/LAT,LON

For example, here's the Atom Geohash for Boston.

Just put your coordinates in, subscribe and you'll be ready to go!

Source is available from subversion: https://staticfree.info/svn/ghfeed/

Bugs
  • I noticed yesterday that before the stock exchange data becomes available, the atom feed creates a kind of 'intemediary' geohash using todays date and yesterday's data. This might be intentional, but personally I find that undesirable on weekdays. Could it be modified to show yesterday's date and geohash until data is available? Nicktaylor 14:04, 23 May 2008 (UTC)
    • It's definitely broken. -- Phyzome 11:37, 28 May 2008 (UTC)
      • This implementation was written before the 30W rule. As it turns out, the intermediate hash falls back on the previous Dow while using the current date from 00:00 (local) to 09:30 ET, which happens to be the desired 30W behavior. However, this is not helpful west of 30W. An inverse problem occurs after 09:30 USET east of 30W, until 24:00 local. See detailed discussion at Talk:Implementations#Atom feed 30W-compliance. --Tim P 15:45, 29 May 2008 (UTC)

Text Messaging (email) service

This implementation IS FULLY 30W-compliant.

If your cell phone supports text messaging to an email address, you can get geohash updates on your phone by sending a formatted text to srv@geohash.info

Formatting

YYYY-MM-DD Lat Lon Example:

2008-02-18 42 -83

Alternatively, it defaults to the current date (EST for now) and you can just enter Latitude and Longitude

42 -83

Bugs

  • The -0 Issue is still very much an issue.
  • This used to display the degree symbol after coordinate elements, but due to poor cell phone support of this character, which resulted in messages cutting off after the first Latitude, I have removed it.
  • This is also not a terribly robust solution, but a better (stronger, faster) implementation is in the making.
  • Not necessarily a bug, but a desirable feature: it would be nice to be able to omit the '-' character when specifying the date (it just happens to require many keystrokes to type - on my phone)


Text Messaging service (SMS)

This implementation IS FULLY 30W-compliant.

Text "GH [date]" to +41774378210, eg:

gh 20091110

A few seconds later you should get an sms response similar to the following:

Relevant DJIA for 2009-11-10 is 10223.01(W) / 10020.62(E). Decimal parts are: 0.02335 0.228005(W) / 0.854495 0.149983(E).

Occasionally you may see a result of <n/a> when information is unavailable. For example, if you are looking at a date where coordinates are only available east of w30, you may see something like:

Relevant DJIA for 2009-11-10 is <n/a>(W) / 10020.62(E). Decimal parts are: <n/a>(W) / 0.854495 0.149983(E).

Not case-sensitive, so "Gh", "gh" etc. are all fine. Don't forget the space between "gh" and the date. The script is also flexible on the date format as long as it's in the Y-m-d order.

The service uses the DJIA source that I maintain.

I recommend testing it once before you are away from home and really need it. Also, don't hesitate to tell me if you don't get an sms back or if you feel that something else is not working properly...

See also SMS DJIA service; suggestions, comments and other feedback to User:Crox.