We built basically the exact same library at foursquare (though it's in Scala not Java). Would anyone be interested in using it if we open sourced it? We probably should.
Yes, it would be great if you open-sourced the library! I'd suggest promoting it as an alternative to SimpleGeo's service that provided this lookup, since that will be shut down at the end of March. See https://support.urbanairship.com/customer/portal/articles/31...
Definitely, we were planning to develop exactly the same system in our social network http://ollaa.com (uses foursquare venues db). I believe that has become a common need for global soical apps. We'd love to see you are open sourcing it, otherwise we will definitely not pay $2,000 for this.
Can't imagine it will cost you less to develop in house in terms of salaried engineering hours, and you probably won't get close to AskGeo in terms of performance. A fast spatial index is non trivial. Classic case of not properly valuing the cost of internal engineering resources.
I'd love to see this open sourced! It'd make a wonderful companion to the great open mapping work being done my Open Street Map and is exactly the kind of thing a community can build on and refine for the good of all.
I am the developer. Regarding price, we decided to start charging because the serving costs were non trvial and I had been getting a lot of email requests for support that were taking up my time. Then Google App Engine prices went up too.
We didn't expect many paying subscribers and that is how it turned out, but we have enough to make it worth leaving the site up and running.
For low volume users we are thinking of offering a pay-go pricing option AWS style, with a low per-query price.
But this is not our main project now (WeatherSpark.com is) so I don't know when we'll get around to making changes.
I don't understand why this has to be queried against a server. Time zones don't change that much. Why can't this just be a standalone library download?
Check out http://www.timeanddate.com. The last few years seems to avg 30-50 changes a year and there have been 11 updates so far this year. Time zones are a lot more dynamic than people think.
Think mobile devices. The user often doesn't know what is correct (eg how many Americans would know about Arizona) and there is a fair amount of data behind the calculations of where you actually are. On a laptop with good net connections you could download that database. Other devices are more constrained.
I have an Android tablet that is wifi only and hence cannot get time details from cell towers. I use this app which corrects the time via NTP, and updates the timezone information automatically by querying geonames.
Depends on the scale of your application. If it's truely global, then timezones change often. I think Russia tends to change it's timezones every 5 years or so
Actually, the Russian time zone change only changes the rules of those time zoned, not the geographical extent of them. Since we just return a tz id, users can just use an updated tz database (any up-to-date Linux system has this) to get the gmt offset at a particular time.
Russia is even worse than that. One year they "cancel winter time", essentially moving to daylight saving time for the whole year. And now parliament is discussing reversing that.
I've been using AskGeo for about 10 months and am very happy with it. Does exactly what I need. I am surprised to see it's now $200/year.
What I signed up AskGeo said:
Is this free?
Yes, for now. We built this for internal use and this site doesn't cost
us much, so we don't intend to charge unless usage takes off. If we do
charge, it will be to cover costs, not because we think we're going to
make it big selling access to a lat/lon to time zone API. So for now it
is free and it is likely to remain so for a long while.
The pricing change has not been communicated to existing users, I was not aware of it until this story had been posted. I'm not sure if they get grandfathered or not. I'm doing about 1 request a day, $200 seems expensive.
They seem to be too busy with another project to implement another payment system[1] but maybe you can email them and directly offer a smaller amount of money for a commercial license since your usage is so limited.
You could implement your own using the shapefiles from http://efele.net/maps/tz/world/. They have derived the shape files from fip10s data which itself is derived from VMAP0 data.
We created a rough implementation similar to this at postmates using this information but didn't find it worthy of open sourcing.
Looks useful - something that my company could use at any rate. We're currently a customer of geonames's commercial web service.
I have a few recommendations for the developer:
First, the GMail account restriction sounds odd. But I'm guessing you can sign up with any Google account? Lots of people have Google accounts, but don't use GMail... If you can sign up with a Google account (like you often can with app-engine apps), I'd suggest calling it a Google account, not a GMail account.
Second, I think the one-price-for-all-commercial-use is off-putting. I've already seen a light user talking about the price being expensive for 1 request a day, which perhaps it is, and you suggested that commercial users with low usage requirements should contact you. Generally speaking I think you want to be making custom deals for the heavy users, not the light ones. If you want to cater for the light commercial users, you might do better to offer an off-the-shelf package that will appeal to them (whilst being too restrictive for the customers that want heavier usage).
I think heavy users would often a) be willing to pay more than $200 a year (which is under $17 a month i.e. very little), and b) be concerned about the fixed price because you wouldn't be able to sustain heavy usage at that low price and so the chances are that you'd want to cut them off for making too many requests. That's a lose lose situation, when it could easily be a win win (them as a happy heavy customer and you getting more money).
I suspect some sort of rate-limit-based subscription pricing or credit-based pay-as-you-go system may be the way forward. If you used a service like FastSpring you could be taking subscription payments very quickly. (I recommend FastSpring because we're using them and I think they're great.)
I don't want to imply that I know what pricing would make most sense for you - I don't - but I'm pretty confident that the current pricing is a long way from optimal.
Thanks for your thoughts. Agree with almost all your points. This just is a tiny side project and we've not gotten around to fine tuning the offering.
And if the 4sq guy's boss lets him spend time to open-source their attempt at this, I don't expect we will. Would be a shame. I'd bet that AskGeo is way higher performance, handles all the corner cases, and would win in a commercial market. But if the 4sq management wants to spend their investor's dollars giving away engineering resources then I suppose our sales will drop off significantly even if our product is better. Hard to compete with a price tag of zero.
I am the developer. As noted on the page: Unlike GeoNames, look-ups are based on an actual map of the world, rather than "closest point of interest", which ensures accuracy and that you actually get a result for all locations.
We also have a very fast spatial index rather than a slow SQL-GIS solution, and last time I checked, they have usage volume restrictions that are pretty limiting.
We looked into using them before building our own solution.
Are you implying that web page design skills and icon choices are a good predictor of a coder's ability to write a blazing fast spatial index? This library solves a hard problem very well. The web design is as it is because we threw the web site together fast to help other people solve this problem, not to win design awards. The market is not big enough to warrant further polish.
Amusingly, I had to implement this not 2 days ago. Since we're using MaxMind's GeoIP lookup anyway, it was just a case of using the auto-generated com.maxmind.geoip.timeZone class.
Edit: Not quite lat / long to Time Zone, though, more IP -> Location -> Time Zone.
On the server and your DB you should always store UTC, and your server app should avoid localization if possible, and move all Date-to-String conversion to the client. Then all this timezone nonsense completely disappears.
Not everyone is a web developer :). There are tons of sources of geo-tagged data where the time zone is useful. For exsmple, we built it to annotate a database of weather stations with the correct tz ids.
