#clustr

Clustr is a new app that’s designed to show you where your social media friends are located while keeping their identities anonymous.  When you log in, Clustr shows you on a map where groups of friends are hanging out.  Tapping on a cluster will show you which venue has the most activity. This can be at a bar or a club or any spot that’s really hopping.

An embarrassingly long time ago we released the first public version of the Flickr Shapefiles. What does this have to do with Captain America and a cat? Nothing, really. Anyway, we haven't completely forgotten about shapefiles and have finally gotten around to generating a new batch (read about Alpha Shapes to find out how it's done). When Aaron did the first run we had somewhere around ninety million (90M) geotagged photos. Today we have over one hundred and ninety million (190M) and that number is growing rapidly. Of course lots of those will fall within the boundaries of the existing shapes and won't give us any new information, but some of them will improve the boundaries of old shapes, and others will help create new shapes where there weren't any before. Version 1 of the dataset had shapes for around one hundred and eighty thousand (180K) WOE IDs, and now we have shapes for roughly two hundred and seventy thousand (270K) WOE IDs. Woo. The dataset is available for download today, available for use under the Creative Commons Zero Waiver:

http://www.flickr.com/services/shapefiles/2.0/

Little Johnny JSON

Originally we provided the full dataset in our own home-grown XML format because, well, it seemed like a good idea. For version two we're releasing the shapes in GeoJSON format. We think this is a Good Thing because unlike our  old XML format, at least one other person in the world already knows how to read and write GeoJSON. For example, Our friends over at Stamen Design and SimpleGeo have created a ridiculously easy-to-use JavaScript library called Polymaps which of course reads GeoJSON out of the box. With a few lines of JavaScript you can render the Flickr shapefiles and start using them without all that pesky XML parsing stuff: Or if GeoJSON doesn't suit you you can use a free tool like ogr2ogr to convert it to something that does.

Layers

(photo by doug88888)

The GeoJSON format allows grouping of features (and their related geometries) into FeatureCollection objects. A FeatureCollection seems to be roughly equivalent to a layer in a typical GIS, or a placetype in WhereOnEarth-speak. To make the dataset a little easier to manage we decided to break the shapes up into FeatureCollections based on placetype; one each for continents, countries, regions (states), counties, localities (cities), and neighbourhoods. Each of these is its own GeoJSON file in the dataset. Here's an example of what one of our GeoJSON objects looks like:

{ "type": "FeatureCollection", "name": "Flickr Shapes Public Dataset 2.0 - Regions", "features": [ { "type": "Feature", "id": 2344541, "properties": { "woe_id": 2344541, "place_id": "Cxf0SmObApi9R9T8", "place_type": "region", "place_type_id": 8, "label": "Barbuda, AG, Antigua and Barbuda", }, "geometry": { "type": "MultiPolygon", "created": 1292444482, "alpha": 0.03, "points": 118, "edges": 17, "is_donuthole": 0, "link": { "href": "http://farm6.static.flickr.com/5209/shapefiles/2344541_20101215_724c4cae47.tar.gz", }, "bbox": [-62.314453125,17.086019515991,-61.690979003906,17.93692779541], "coordinates": [ [ [[-61.739044,17.587740], [-61.735268,17.546171], [-61.690979,17.426649], [-61.765137,17.413546] ... etc

A file is a single FeatureCollection object which holds an array of Features, which each hold a Geometry which is a MultiPolygon, which holds an array of Polygons which in turn each consist of an array of LinearRings. Got it?

You've Been Superseded

We've also included a separate file/layer called flickr_shapes_superseded.geojson. This is a FeatureCollection that consists of all the WOE IDs that have been "superseded". Occasionally (too often?) a WOE ID needs to be retired and replaced with a new one. We keep up to date with these and are always reverse-geocoding against the latest WOE IDs. However, there are plenty of old photos (and Flickr shapes) that have been assigned to one of these old IDs, and we have shapes for them (currently a little more than nine thousand). A simple solution might be to just re-assign these photos to the new WOE IDs (when a WOE ID is retired its replacement is specified), or even just re-run the reverse-geocoding process. This may not be what the owner of the photo wants; it might come out with a different result than they had at first (which they may have been perfectly happy with), if the size and location of the WOE rectangle changed (which it probably did). So it's a problem without a clear solution. And since we have data for these old WOE IDs we've included their associated shapes in the dataset. In most cases there will be shapes corresponding to the new WOE IDs that will over time become more and more accurate as more photos get uploaded and end up being assigned to the new WOE IDs. But you can have the old ones too.

WTF

photo by dp

The name sort of says it all, really, but here's the short version:

We are releasing all of the Flickr shapefiles as a single download, available for use under the Creative Commons Zero Waiver. That's fancy-talk for "public domain".

The long version is:

To the extent possible under law, Flickr has waived all copyright and related or neighboring rights to the “Flickr Shapefiles Public Dataset, Version 1.0”. This work is published from the United States. While you are under no obligation to do so, wherever possible it would be extra-super-duper-awesome if you would attribute flickr.com when using the dataset. Thanks!

We are doing this for a few reasons.

We want people (developers, researchers and anyone else who wants to play) to find new and interesting ways to use the shapefiles and we recognize that, in many cases, this means having access to the entire dataset.

We want people to feel both comfortable and confident using this data in their projects and so we opted for a public domain license so no one would have to spend their time wondering about the issue of licensing. We also think the work that the Creative Commons crew is doing is valuable and important and so we chose to release the shapefiles under the CC0 waiver as a show of support.

We want people to create their own shapefiles and to share them so that other people (including us!) can find interesting ways to use them. We're pretty sure there's something to this "shapefile stuff" even if we can't always put our finger on it so if publishing the dataset will encourage others to do the same then we're happy to do so.

photo by mbkepp

The dataset itself is pretty straightforward. It is a single 549MB XML file uncompressed (84MB when zipped). The data model is a simple, pared-down version of what you can already get via the Flickr API with an emphasis on the shape data.

Everything lives under a single root places element. For example:

<place woe_id="26" place_id="BvYpo7abBw" place_type="locality" place_type_id="7" label="Arvida, Quebec, Canada"> <shape created="1226804891" alpha="0.00015" points="45" edges="15" is_donuthole="0"> <polylines bbox="48.399932861328,-71.214576721191,48.444801330566,-71.157333374023"> <polyline> <!-- points go here--> </polyline> </polylines> <shapefile url="http://farm4.static.flickr.com/3203/shapefiles/26_20081116_082a565562.tar.gz" /> </shape> <!-- and so on --> </place>

Aside from the quirkiness of the shapes themselves, it is worth remembering that some of them may just be wrong. We work pretty hard to prevent Undue Wronginess ™ from occurring but we've seen it happen in the past and so it would be, well, wrong not to acknowledge the possibility. On the other hand we don't think we would have gotten this far if it wasn't mostly right but if you see something that looks weird, please let us know

The dataset is available for download, today, from:

http://www.flickr.com/services/shapefiles/1.0/

The other exciting piece of news is that the Yahoo! GeoPlanet team has also released a public dataset of all their WOE IDs that include parent IDs, adjacent IDs and aliases (that's just more fancy-talk for "different names for the same place") under the Creative Commons Attribution License.

Which is pretty awesome, really.

They've also released the GeoPlanet Placemaker API. You feed it a big old chunk of free-form text and then "the service identifies places mentioned in text, disambiguates those places, and returns unique identifiers (WOEIDs) for each, as well as information about how many times the place was found in the text, and where in the text it was found."

Again, Moar Awesome.

And a bit dorky. It's true. The data, all by itself, won't tell a story. It needs people and history to make that possible but as you poke around all this stuff don't forget the value of having a big giant, and now open, database of unique identifiers and what is possible when you use them as a bridge between other things. Without WOE IDs we wouldn't have been able to generate the shapefiles or do the Places project or provide a way to search for photos by place, rather than location.

Enjoy!

Oh, and those "unidentified" outliers, in New York City, that I mentioned in the last post about the donut hole shapefiles: The Bronx Zoo, Coney Island and Shea Stadium. Of course!

photo by selflesh

Back in January, I wrote a blog post about some experimental work that I'd been doing with the shapefile data we derive from geotagged photos. I was investigating the idea of generating shapefiles for a given location using not the photos associated with that place but, instead, from the photos associated with the children of that place. For example, London:

The larger pink shape is what we (Flickr) think of as the "city" of London. The smaller white shapes are its neighbourhoods. The red shapes represent an entirely new shapefile that we created by collecting all the points for those neighbourhoods and running them through Clustr, the tool we use to generate shapes.

For lack of any better name I called these shapes "donut holes" because, well, because that's what they look like. The larger shape is a pretty accurate reflection of the greater metropolitain area of London, the place that has grown and evolved over the years out of the city center that most people would recognize in the smaller red shape. Our goal with the shapefiles has always been to use them to better reverse-geocode people's geotagged photos so these sorts of variations on a theme can better help us understand where a place is.

Like New York City. No one gets New York right including us try as we might (though, in fairness, it's gotten better recently (no, really)) and even I am hard pressed to explain the giant pink blob, below, that is supposed to be New York City. On the other hand, the red donut hole shape even though (perhaps, because) it spills in to New Jersey a bit is actually a pretty good reflection of the way people move through the city as a whole.

It could play New York on TV, I think.

I'm not sure how to explain the outliers yet, either, other than to say the shapefiles for city-derived donut holes may contain up to 3 polygons (or "records" in proper Shapefile-speak) compared to a single polygon for plain-old city shapes so if nothing else it's an indicator of where people are taking photos.

If the shapefiles themselves are uncharted territory, the donut holes are the fuzzy horizon even further off in the distance. We're not really sure where this will take us but we're pretty sure there's something to it all so we're eager to share it with people and see what they can make of it too.

(This is probably still my favourite shapefile ever.)

Starting today, the donut hole shapes are available for developers to use with their developer magic via the Flickr API.

At the moment we are only rendering donut hole shapefiles for cities and countries. I suppose it might make sense to do the same for continents but we probably won't render states (or provinces) simply because there is too much empty unphotographed space between the cities to make it very interesting.

There are also relatively few donut holes compared to the corpus of all the available shapefiles so rather than create an entirely new API method we've included them in the flickr.places.getShapeHistory API method which returns all the shapefiles ever created for a place. Each shape element now contains an is_donuthole attribute. Here's what it looks like for London:

<shapes total="6" woe_id="44418" place_id=".2P4je.dBZgMyQ" place_type="locality" place_type_id="7"> <shape created="1241477118" alpha="9.765625E-05" count_points="275464" count_edges="333" is_donuthole="1"> <!-- shape data goes here... --> </shape> <!-- and so on -> </shapes>

Meanwhile, the places.getInfo API method has been updated to included a has_donuthole attribute, to help people decide whether it's worth calling the getShapeHistory method or not. Again, using London as the example:

<place place_id=".2P4je.dBZgMyQ" woeid="44418" latitude="51.506" longitude="-0.127" place_url="/United+Kingdom/England/London" place_type="locality" place_type_id="7" timezone="Europe/London" name="London, England, United Kingdom" has_shapedata="1"> <shapedata created="1239037710" alpha="0.00029296875" count_points="406594" count_edges="231" has_donuthole="1" is_donuthole="0"> <!-- and so on --> </place>

Finally, here's another picture by Shannon Rankin mostly just because I like her work so much. Enjoy!

photo by Shawn Allen

At the Emerging Technology conference this year Stamen Design's Michal Migurski and Shawn Allen led an afternoon workshop called "Maps from Scratch: Online Maps from the Ground Up" where people made digital maps from, well... scratch.

If you've never heard of Stamen they've been doing some of the most exciting work around the idea of "custom cartography" including: Cabspotting, Oakland Crimespotting and Old Oakland Maps, work for the London Olympics, and designing custom map tiles for CloudMade. (Stamen also built the recently launched Flickr Clock :-)

All of this is interesting in its own right; proof that there is still a lot of room in which to imagine maps beyond so-called red-dot fever. All of this is extra interesting in light of Apple's recent announcement to allow developers to define their own map tiles in the next iPhone OS release. All of this super-duper interesting because it is work produced by a team of less than 10 people.

The tools, and increasingly the data, to build the maps we want are bubbling up and becoming easier and more accessible to more people every day. Easier, anyway.

"One of the things that made this tutorial especially interesting for us was our use of Amazon's EC2 service, the "Elastic Compute Cloud" that provides billed-by-the-hour virtual servers with speedy internet connections and a wide variety of operating system and configuration options. Each participant received a login to a freshly-made EC2 instance (a single server) with code and lesson data already in-place. We walked through the five stages of the tutorial with the group coding along and making their own maps, starting from incomplete initial files and progressing through added layers of complexity.

"Probably the biggest hassle with open source geospatial software is getting the full stack installed and set up, so we've gone ahead and made the AMI (Amazon Machine Image, a template for a virtual server) available publicly for anyone to use, along with notes on the process we used to create it."

— Michal Migurski

The Maps From Scratch (MFS) AMI may not be a Leveraged Turn Key Synergistic Do-What-I-Mean Solutions Platform but, really, anything that dulls the hassle and cost of setting up specialized software is a great big step in the right direction. I mention all of this because Clustr, the command-line application we use to derive shapefiles from geotagged photos, has recently been added to the list of tools bundled with the MFS AMI.

Specifically: ami-4d769124.

We're super excited about this because it means that Clustr is that much easier for people to use. We expressly chose to make Clustr an open-source project to share some of the tools we've developed with the community but it has also always had a relatively high barrier to entry. Building and configuring a Unix machine is often more that most people are interested in, let alone compiling big and complicated maths libraries from scratch. Clustr on EC2 is not a magic pony factory but hopefully it will make the application a little friendlier.

Creating and configuring an EC2 account is too involved for this post but there are lots of good resources out there, starting with Amazon's own documentation. When I'm stuck I usually refer back to Paul Stamatiou's How To: Getting Started with Amazon EC2.

Assuming that you familiar using Unix command line tools, let's also assume that you have gotten all your ducks in a row and are ready to fire up the MFS AMI:

your-computer> ec2-run-instances ami-4d769124 -k example-keypair your-computer> ec2-describe-instances

At which point, you'll see something like this:

INSTANCE i-xxxxxxxx ami-4d769124 ec2-xxxxx.amazonaws.com blah blah blah

i-xxxxxxxx is the unique identifier of your current EC2 session. You will need this to tell Amazon to shut down the server and stop billing you for its use.

ec2-xxxxx.amazonaws.com is the address of your EC2 server on the Internets.

Once you have that information, you can start using Clustr. First, log in and create a new folder where you'll save your shapefile:

your-computer> ssh -i example-rsa-key [email protected] ec2-xxxxx.amazonaws.com> mkdir /root/clustr-test

The MFS AMI comes complete with a series of sample "points" files to render. We'll start with the list of all the geotagged photos uploaded to Flickr on March 24:

ec2-xxxxx.amazonaws.com> /usr/bin/clustr -v -a 0.001 \ /root/clustr/start/points-2009-03-24.txt \ /root/clustr-test/clustr-test.shp

By default Clustr generates a series of files named clustr (dot shp, dot dbf and dot shx because shapefiles are funny that way) in the current working directory. You can specify an alternate name by passing a fully qualified path as the last argument to Clustr. When run in verbose mode (that's the -v flag) you'll see something like this:

Reading points from input. Got 44410 points for tag '20090324'. 799 component(s) found for alpha value 0.001. - 23 vertices, area: 86.7491, perimeter: 71.9647 - 32 vertices, area: 1171.51, perimeter: 41.3095 - 8 vertices, area: 18.5112, perimeter: 0.529504 - 12 vertices, area: 1484.81, perimeter: 10.8544 ... Writing 505 polygons to shapefile.

Yay!

ec2-xxxxx.amazonaws.com> ls -la /root/clustr-test total 172 drwxr-xr-x 2 root root 4096 2009-04-07 03:14 . drwxr-xr-x 5 root root 4096 2009-04-07 02:22 .. -rw-r--r-- 1 root root 52208 2009-04-07 03:14 clustr-test.dbf -rw-r--r-- 1 root root 97388 2009-04-07 03:14 clustr-test.shp -rw-r--r-- 1 root root 4140 2009-04-07 03:14 clustr-test.shx

Now copy the shapefiles back to your computer and terminate your EC2 instance (or you might be surprised when you get your next billing statement from Amazon).

ec2-xxxxx.amazonaws.com> scp -r /root/clustr-test \ you@your-computer:/path/to/your/desktop/ ec2-xxxxx.amazonaws.com> exit your-computer> ec2-terminate-instances i-xxxxxxxxx

I created this image (using the open source QGIS application) for all those points by running Clustr multiple times with alpha numbers ranging from 0.05 to 603:

Here's another version rendered using the nik2img application and a custom style sheet, both included with the MFS distribution:

Here's one of all the geotagged photos tagged "route66" (with alpha numbers ranging from 0.001 to 0.5):

Apologies and big sloppy kisses to Stamen's own Mappr (first released in 2005).

Or tagged "caltrain", the commuter train that runs between San Francisco and San Jose:

Meanwhile, Matt Biddulph at Dopplr has been generating a series of visualizations depicting the shape of where to eat, stay and explore for the cities in their Places database. This is what London looks like:

Or: "London dopplr places, filtered to only places my social network has been to, clustrd".

One of the things I like the most about Clustr is that it will generate shape(file)s for any old list of geographic coordinates. Now that most of the hassle of setting up Clustr has been (mostly) removed, the only question left is: What do you want to render?

"They do not detail locations in space but histories of movement that constitute space."

— Rob Kitchin, Chris Perkins

If you're like me you're probably thinking something like "Wouldn't it be nice if I could just POST a points file to a webservice running on the AMI and have it return a compressed shapefile?" It sure would so I wrote a quick and dirty version (not included in the MFS AMI; you'll need to do that yourself) in PHP but if there are any Apache hackers in the house who want to make a zippy C version that would be even Moar Awesome ™.

If you don't want to use the MFS AMI and would rather just install Clustr on your own machine instance, here are the steps I went through to get it work on a Debian 5.0 (Lenny) AMI; presumably the steps are basically the same for any Linux flavoured operating system:

$> apt-get update $> apt-get install libcgal-dev $> apt-get install libgdal1-dev $> apt-get install subversion $> svn co http://code.flickr.com/svn/trunk/clustr/ $> cd clustr $> make $> cp clustr /usr/bin/ $> clustr -h clustr 0.2 - construct polygons from tagged points written by Schuyler Erle (c) 2007-2008 Yahoo!, Inc. Usage: clustr [-a <n>] [-p] [-v] <input> <output> -h, -? this help message -v be verbose (default: off) -a <n> set alpha value (default: use "optimal" value) -p output points to shapefile, instead of polygons If <input> is missing or given as "-", stdin is used. If <output> is missing, output is written to clustr.shp. Input file should be formatted as: <tag> <lon> <lat>\n Tags must not contain spaces.

Just like that!

We have a lot of geotagged photos

Almost ninety million, as I write this, and the numbers keep growing especially as nearly every new smart phone released to market has not only a camera but also the ability to capture location information with it.

For every geotagged photo we store up to six Where On Earth (WOE) IDs. These are unique numeric identifiers that correspond to the hierarchy of places where a photo was taken: the neighbourhood, the town, the county, and so on up to the continent. This process is usually referred to as reverse-geocoding.

Over time this got us wondering: If we plotted all the geotagged photos associated with a particular WOE ID, would we have enough data to generate a mostly accurate contour of that place? Not a perfect representation, perhaps, but something more fine-grained than a bounding box. It turns out we can.

So, starting today there are 150,000 (and counting) WOE IDs with proper (-ish) shape data, available via the Flickr API. What kind of shapes, you ask?

Continents:

  Countries:

  States and cities:

  Even neighbourhoods:

  Each one of those illustrations represents the boundaries of a particular place whose outline was generated using nothing but the latitudes and longitudes of the geotagged photos associated with that location's WOE ID. No GIS information was harmed in the creation of these shapes.

How cool is that?!

How does it work?

The short version is: Scary and complicated maths. The longer version is: We are generating alpha shapes using the set of unique latitudes and longitudes associated with a WOE ID. The long version, to quote Tran Kai Frank Da and Mariette Yvinec, is:

"Imagine a huge mass of ice-cream making up the space ... and containing the points as hard chocolate pieces. Using one of those sphere-formed ice-cream spoons we carve out all parts of the ice-cream block we can reach without bumping into chocolate pieces, thereby even carving out holes in the inside (eg. parts not reachable by simply moving the spoon from the outside). We will eventually end up with a (not necessarily convex) object bounded by caps, arcs and points. If we now straighten all round faces to triangles and line segments, we have an intuitive description of what is called the alpha shape..."

(There are also some useful illustrations of what that all means on Francois Belair's Everything You Always Wanted to Know About Alpha Shapes But Were Afraid to Ask website.)

The community of authority and the authority of community

This is the important part: Many, if not most, of these shapes will look a little weird. Possibly even "wrong". This is both okay and to be expected for a few reasons, at least.

Sometimes we just don't have enough geotagged photos in a spot to make it is possible to create a shapefile. Even if we do have enough points to create a shape there aren't enough to create a shape that you'd recognize as the place where you live. We chose to publish those shapes anyway because it shows both what we know and don't about a place and to encourage users to help us fix mistakes.

If the shape of the neighbourhood is incomplete or looks weird why not consider organizing a photowalk around its edges and when you get home add them to the map. The next time we generate a new shapefile for that neighbourhood it should look more like the place you recognize!

We did a bad job reverse geocoding photos for a particular spot and they've ended up associated with the wrong place. We've learned quite a lot about how to do a better job of it in the last two years but there is a limit to how much human awareness and subtlety we can codify. Sometimes, the data we have to try and work out what's going on is just bad or out of date.

Ultimately, that's why we added the tools to help users correct their geotagged photos so that we can adjust things to their understanding of the world and begin to map facts on the ground rather than from on high.

We are not very sophisticated yet in how we assign the size of the alpha variable when we generate shapes. As far as we can tell no one else has done this sort of thing so like reverse-geocoding we are learning as we go. For example, with the exception of continents and countries we boil all other places down to a single contiguous shape. We do this by slowly cranking up the size of the ice cream scoop which in turn can lead to a loss of fidelity.

Does the shape of Florida, or of Italy, include the waters that lie between the mainland and the surrounding islands? It's not usually the way we imagine the territory that a place occupies but I think it probably does. On the other hand, including the ocean between California and Hawaii as part of the United States would be kind of dumb.

Are any of these the correct decisions? We're not sure yet.

A concrete example to illustrate the point. Here are two versions of the island of Montreal, each generated from the same set of coordinates. The version on the left used an alpha number (an ice cream spoon) large enough to ensure that only a single shape was created compared with the version on the right that allowed for two shapes.

  What's going on, then? All those photos taken in St. Jean-sur-Richelieu (20 minutes south of Montreal) were added to the map back when we first added geotagging to the site and the information about the province of Quebec was not as detailed as what we have now. Ultimately, we decided to include the version on the left because as Matt Jones recently said:

"The long here that Flickr represents back to me is becoming only more fascinating and precious as geolocation starts to help me understand how I identify and relate to place. The fact that Flickr's mapping is now starting to relate location to me the best it can in human place terms is fascinating - they do a great job, but where it falls down it falls down gracefully, inviting corrections and perhaps starting conversation."

As with any visualization of aggregate data there are likely to be areas of contention. One of the reasons we're excited to make this stuff available is that much of it simply isn't available anywhere else and the users and the developer community who make up Flickr have a gift for building magic on top of the API so we're doubly-excited to see what people do with it.

That said please remember that this it is an aggregate view of things and should be treated more like the the zeitgeist of a place and not as capital-C confirmed facts on the ground or our taking sides in any conflicts (real, imagined or otherwise) between friends and neighbours.

These are not maps you should use to guide your spaceship back to Earth but they're probably good enough to explore the possibilities.

Clustr

Meanwhile, back in the nuts-and-bolts department: The actual alpha shapes are generated by a program called Clustr, written for us by the fantabulous Schuyler Erle.

Clustr is a command-line application written in C++ that takes as its arguments the path to a file containing a list of points (the hard chocolate pieces) and an alpha parameter (the ice cream spoon) and generates a shapefile describing the contour (the alpha shape) of that list. Anecdotally, we've seen Clustr plow through a file with four million unique coordinates (representing the continental United States, Alaska and Hawaii) in under three minutes on some pretty modest hardware.

The shapedata for a WOE ID is available via the Flickr API using the flickr.places.getInfo method.

Not all places have shape data yet so the root <place> element contains a has_shapedata attribute for checking at a glance. Otherwise you can test for the presence of a <shapedata> element. It will look like this:

<place place_id="4hLQygSaBJ92" woeid="3534" latitude="45.512" longitude="-73.554" place_url="/Canada/Quebec/Montreal" place_type="locality" name="Montreal, Quebec, Canada" has_shapedata="1"> <!-- all the usual places hierarchy elements --> <shapedata created="1223513357" alpha="0.012359619140625" count_points="34778" count_edges="52"> <polylines> <polyline> 45.427627563477,-73.589645385742 45.428966522217,-73.587898254395, etc... </polyline> </polylines> </shapedata> </place>

Sometime next week, we will also include links to a real live ESRI shapefile, the well-known and mostly-loved lingua franca of the GIS community, for each WOE ID. They were supposed to be included with this release but because of a last minute glitch they need to be prettied up a little first. We think that the inclusion of the polylines will be enough to keep people busy until then. Shapefiles will be included, in the API, as a link to a compressed file you can download separately. For example:

Update: The first round of (ESRI) shapefiles have been reprocessed and are now available via the API. Shapefiles are included as a link to a compressed file you can download separately. For example:

<urls> <shapefile> http://farm4.static.flickr.com/9999/shapefiles/3534_20081020_S33KR3TSHAPE.tar.gz </shapefile> </urls>

Our plan is to generate new renderings on a relatively constant basis, something like every month or two, though we haven't firmed up any of those details yet. We'll post about them here or on the API mailing list as things are worked out.

But wait, there's more!

Along with the shape data the source code for Clustr is available in the Flickr Code repository and through our trac install, distributed under the GPL (version 2).

Clustr has two major dependencies not included with the source that you will need to install yourself in order to use. They are the Computational Geometry Algorithms Library (CGAL) and the Geospatial Data Abstraction Library (GDAL). Both are relatively straightforward to install on Linux and BSD flavoured operating systems; Windows and OS X are still a bit of a chore.

You probably won't be able to download Clustr and simply plug it in to your awesome web-application today but I am hopeful that in time the community will develop higher level language (Perl, Python, Ruby, you name it...) bindings to make it easier and faster to write tools that build on the work we've done so far.

photo by Julian Bleecker

By the way, there is a still a known-known bug in Clustr rendering interior rings (the donut holes where there are no geotagged photos) in shapefiles. Specifically, they holes are rendered as actual polyline records. You can see an example of the problem in the screenshot of the shapefile for North America, above. We hope to have a proper patch in place by the time we make the ESRI files available next week. As it is since the problem only manifests itself for countries and continents it seemed like a reasonable thing for a version 0.1 release.

Update: Clustr 0.2, with a fix for errant interior rings, has been checked in to the code.flickr.com SVN repository.

Finally, these are early days and this is very much a developer's release so we look forward to your feedback and also hope you will be understanding as we learn our way around the gotchas and quirks that will no doubt pop up.

In other geostuffs

In other geostuffs, we have enabled Open Street Maps tiles for two more cities: Baghdad and Kabul and George has written a fantastic post highlighting some of the photos we've found in both cities so go and have a look.

Map data CCBYSA 2008 OpenStreetMap.org contributors