People are passionate about where they live. At Etsy we need to keep track of lots of different locations, such as buyers' billing and shipping addresses and sellers' shop locations. As Etsy continues to expand internationally we wanted to provide better localization and translations for our location place names. We determined that the best way to effect this change was to move from using a closed location API provider to internal services backed by the open GeoNames data set.

The post details some of the steps in the process including the mapping of the current data to the new structure (the script is available on github). They talk about how they mapped their old data over (trial and error sometimes) and the creation of a database of "GeoNameIDs" for each customer in their records. They've also implemented a Lucene/Solr search for improved searching and auto-suggestion based on the user's location.

Location-aware applications rely on being able to locate where you are, and this is what geolocation is all about. After all, once the application knows your location, it can go on to find the nearest store, guide you through the appropriate route to a destination, or target relevant advertisements to you. Geolocation, then, is simply the mechanism for identifying your geographical location.

He mentions two challenges associated with geolocation - finding where someone is and describing the location. With Geonames, he shows how to call the service's "findNearbyPlaceName" method to find the closest "place" to a given latitude/longitude combination. Included is a bit of sample PHP to connect to the service and Javascript to request the user's current location.

Geographical information integration is rapidly becoming an integral part of many websites. People use geographic data for a wide variety of applications. From location based content targeting, censoring information by geographic areas to analyzing website traffic by region. It is surprising how much free geographic information is available on the web. GeoNames is one such service.

The database is released under a Creative Commons license, so it's available to all and getting the libraries installed to use it is a single "pear install" command away. He includes code showing how to make a sample search for cities, countries and "neighbors" as well as just performing a generic search off the data. He also throws in a method for accessing the information via jQuery (an ajax call)

I was recently tasked with building an application that relied heavily on accurate time zone conversions. I, like many people I soon found out, thought there were just a handful of timezones and the usual select list would suffice. The deeper I looked into the problem, the deeper it got: the list above only shows a few time offsets from UTC, but it doesn't tell me, beyond a shadow of a doubt, exactly what time it is where the user is situated, nor can I rely on that time for calculations in the future. The fact is, here are a LOT of timezones in the world.

He came across the DateTimeZone class PHP has to offer and was happy to see it met his needs. Unfortunately, users weren't always sure what timezone they were in, so he came up with a system combining Google's Maps API and GeoNames.org. He includes the code for both the PHP and Javascript sides (the Javascript requires Mootools, but it could be easily adapted to any other Javascript libraries).

I recently came by this site WorldTimeEngine where users can search the local time of any place using the name, street address or just latitude and longitude. Since that time I was thinking how easily you can make your own. As long there are some good people over there (For Geocoding API) - its a not a big deal, you know?

His script pulls the location of the place (latitude/longitude) from the Yahoo! geocoding API and passes that back into the geonames web service to get the local time. The result is an array with the lat/long, address you submitted and the time output in a standard string.