I released a small php script for easily handling geodata in couchdb via php a while ago, check it out here.  I also put together a short tutorial on how to integrate this script in your CakePHP application.  The article is available here on the CakePHP Bakery.

Recently, I’ve been working on a project that requires a lot of geocoding.  Google provides a free service that takes any string as an input and returns a bunch of JSON encoded data if that string matches a physical location.  Check it out here.

Unfortunately, Google’s geocoding service is limited to 15k requests per day per IP.  Sounds like a lot, but for certain applications this limit can be reached very quickly.

What’s a good solution in these cases?  Why, how about use my favorite up-and-coming database, CouchDB, to store a repository of geo-data mined from Google?  Why use CouchDB?  As previously mentioned, google natively return JSON data for geocoding requests.  Perfect.  CouchDB just happens to store documents natively in JSON!

The following is a rough and tumble library I put together called GeoCouch that you can use to easily handle geocoded data in CouchDB.  This lib has a narrow scope right now – the requirements are:

1. PHP 5+
2. CouchDB
3. A Google API Key (get one here)

Usage

Using the GeoCouch is dead simple.
Grab the file here.

conf parameters!
	 */
	$GeoCouch = new GeoCouch();

	/*
	 * The all-in-one method.
	 * This geocodes the string and writes it to CouchDB
	 * The second parameter is any other fields other
	 * than the Google data that you want to save along
	 * with this document.
	 *
	 * NOTE: if this address already exists in CouchDB
	 * a new revision is created.
	 *
	 * Returns the CouchDB response, i.e.:
	 * {"ok" : true, "rev":"3825793742", "id" : "dallas-tx" }
	 */
	$GeoCouch->save('Dallas, TX', array('custom_field' => 'value')); 

	/*
	 * Simply geo coding.
	 * Does not write to CouchDB.
	 * Returns an Google Geocoded Object.
	 */
	$geoObj = $GeoCouch->geoCode('Dallas, TX');

	/*
	 * Write some Geo JSON to CouchDB.
	 * First parameter is a unique name for the data
	 * Second parameter is the JSON - in
	 * this case the json_encoded $geoObj from above.
	 */
	$GeoCouch->put('Dallas, TX', json_encode($geoObj));

	/*
	 * Get some existing geo data
	 */
	$geoObj = $GeoCouch->get('Dallas, TX');
?>

I call this my erlang playground instance.  Here’s what’s installed:

1. Ubuntu Server Hardy 8.0.4
2. Apache 2 listening to port 80
3. Erlang R12B-3
4. CouchDB 0.8 listening to port 5984
5. Yaws v1.76 listening to port 8080
6. MochiWeb Library

The instance ID is ami-12ae4a7b and I’ve made it public so feel free to use it to your hearts content!

I plan to add to this instance whenever I find time.  I definitely want to get SSL socket communication going using this tutorial.  I’m also interested in Kevin’s virtuerl project over a hypotheticalabs for quick and easy VM management because the whole reason I’m going through the trouble of doing this on EC2 is I think development on any erlang system should start and end with multiple physical machines.

Kore Nordmann recently shared his wrapper for working with CouchDB in PHP, PHPillow.  Check it out if you’re a php-er like me.

cmlenz just posted a wiki page documenting the upcoming changes to CouchDB that aren’t backwards compatible.

Just had a funny thought since CouchDB and Erlang have been on my mind so much lately. Everyone’s familiar with the LAMP and WISC stacks, right? (Linux, Apache, MySQL, PHP and Windows, IIS, SQLServer, C# from those of you who aren’t)

Could the next big stack to hit mainstream be LYCE – Linux, Yaws, CouchDB, and Erlang?

Given that scalability is such a huge issue right now, and Elastic/Cloud computing is almost certainly the next big infrastructure movement, I certainly think at least Erlang and CouchDB will go mainstream.

Another variant could be LYSE – Linux, Yaws, SimpleDB, and Erlang.

One Apache project I find very interesting right now is CouchDB. From the site:

Apache CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. Among other features, it provides robust, incremental replication with bi-directional conflict detection and resolution, and is queryable and indexable using a table-oriented view engine with JavaScript acting as the default view definition language.

Why is it interesting?

Schema-free – as a web app developer, I can relate to anyone who has had frustration or is fed up with managing and maintaining schemas. CouchDB offers a document-based system where each document in the database is loosely related. This means no more schemas to update and manage – simply throw new data into the database. How do I retrieve data that is related to each other? That’s a topic for another conversation, but this’ll get you started. Scroll to the section titled, ‘Views’.

RESTful HTTP/JSON API – JSON is quickly becoming a powerhouse as a data-transfer mechanism. Combined with the principles of REST and accessed through HTTP, querying a CouchDB will be familiar to anyone who’s worked with data-driven applications in Adobe’s Flex technology. At Figaro Interactive, that’s pretty much all we do, so CouchDB fits right into our workflow!

There are more reasons why I’m excitedly watching the CouchDB project, but I’ll save them for a later post. I just wanted to drop a quick line and increase awareness of this pretty cool project.