I’ve been recently thinking about some of my goals for my own family web site and why they are not yet completed.

• I like the Blog format for sharing my photos as they get context and a story. Sort of like an online slide show, but better.
• I do have a photo gallery for the times when I want to post a lot of photos and there is too much for a blog. It doesn’t get a lot of use but it has its place. It is run by a very simple gallery script called mg2
• I am totally into GeoTagging my photographs. My ultimate goal has been to be able to show my photos on a map but I have never produced an efficient system for doing that. I have created enough individual pieces to convince myself that it is not difficult but bringing them together takes time that I don’t ever have.

The ultimate goal of all this is to be able to access my photographs in useful and interesting ways. Ways that add context or a story instead of just a bunch of photographs in a gallery. GeoTagging adds information and context to the photos but, by itself, isn’t much use unless it can be visualized correctly. In the end it is all about how that information helps me create a more interesting presence.

There have already been a few applications of online galleries that include maps to view geotagged images. WWMX is the first I always reference as it was way ahead of its time. It was an entirely proprietary system and difficult to use, but it had all the elements. Zoto was one of the first I heard of that merged Google Maps with photo galleries. Recently Flickr has joined the game and produced exactly what I want (with Yahoo maps).

All the commercial photo gallery sites, and even the free gallery applications, are broken up into at least two main parts. The database on the server to keep track of all the information about the photographs and the user interface to visualize that information. The problem that I have with the available applications is that they all do both halves of the work and are completely incompatible. Every photo gallery application that I can find online each have their own way of storing the information about the images (location, file name, interface structure, etc.). Some use a file on the server, some use the directory structure, and some use a MySQL database.

What I want is one system to organize the photos that I have on my site, all over my site. Not just another photo gallery or photoblog or WordPress plugin, but an underlying system to keep track of everything. I want to separate the database from the distribution; the backend from the frontend. This seems rather logical, is an obvious software engineering practice and, as I said, almost everybody does this already. The difference is that I want to separate the two parts even more. I want to consider just one part of that, the database, and ignore the user interface for the moment.

What I want to build (or steal from somewhere) is a photo organization database and API for accessing that information. No user interface, no front-end, just the information storage. I want it to be extensible so that new information can be added. I want it flexible enough that it can be used by any sort of photo front-end. Something that can be plugged into a blog or gallery or map or some unique presentation system that has not yet been developed.

In a way, the file system on the web server already does this. It stores information about the image files and even helps in organizing them. It has an API that can be used to access information about the files. Unfortunately it only stores the name, date and a few other insignificant items. Ultimately, some more information can be saved in the file (particularly JPEG files with EXIF headers) but even that has limits, not to mention the performance overhead.

Step one – Build an enhanced meta information database
Something that can be used like a generic file system but can store much more information about a file and an efficient way to access that information. The schema for the database is important as it must be extensible for future updates, though upgrading the database in the future should be easy enough. Initially it would contain the location (server and URL), some meta information like width, height, Geocoded location, and some keywords. This would include a server (PHP) API to access that information.

Step two – Populate the database
Fortunately the image files on my server are all in file form on the host operating system. The new database can be populated from the existing database (the file system). A crawler should be written that can crawl a web site or the host file system and catalog every photograph. The actual location of the files in that file system is irrelevant. Think of this like Google Desktop for your server.

Step three – Update it as new files are added
Until every server application (gallery, blog, etc.) is using this API to maintain file details any new files added to the server will need to be added to this database. Rather than crawl the system regularly, a simple API to add the file to the DB should be created that can be used by all the existing upload or editing tools to indicate that there is a new file. Something so simple as to only need the name of the file. It should be very easy to insert a single PHP function call in the appropriate places for a few applications like mg2 and WordPress.

Step four – Convert existing applications to use this API
The ultimate goal of this is to, of course, have a user interface. Even better would be for all different interfaces to use this API to access the data. All the server applications from photo gallery to blog should use the one system. One at a time, either through plugins or larger modifications, this DB could be used to store some of the meta information required by the application. Rewriting the image database in MG2 comes to mind.

Step five – Write new applications using this API
If all we did was convert other image libraries to use this API then it would seem like a waste with minimal benefit. A new WordPress plugin that allows you to select photos from this database in the post editor would be a good start. A map based photo gallery is an obvious application that I want with a focus on geographic location of the images.

There are other things that can be done with this system too, but the ones above are a good start. Creating a system that can be used by a photo gallery, a Blog plugin, and a map based album is all that I want for now, and is my primary focus. These are the applications that I will be considering while designing the database and API. Comments are welcome and more details will follow as I flesh this out.