http://norman.walsh.name/2008/03/31/moreMapping 11 34 2008-03-31T13:44:35-04:00 Norman Walsh 2008 Norman Walsh Mapping photographs is one of those fun little projects that grows everytime I think about it. ABQIAAAAO1qAaQsvBqLxt1nDHmVdXRS4k_Slk4HpyYNJokS65uiFGyHI9RQnDJVG7YhIt2uKxaEup9yE1lDNtA Over the weekend, I realized there were three things I really wanted to add to my mapping hacks: Map all the photos on a given map, not just those with in 0.1 degrees of latitude/longitude from the center. As you zoom out, you should be able to see more images. Provide more control over the number of images mapped. Just because there are 600 images on the map doesn't mean you really want your browser to add 600 markers all at once. Figure out what places are most interesting, from a mapped photographs perspective. And Dave's comment gave me another idea: Handle multiple photographs with the same latitude and longitude. This turns out to be more common than I would have expected because, I think, Flickr makes it easy to tag a batch of photos. SMOP. Fixing the first two items was just a simple matter of programming. Along the way, I also improved the color coding so that its more consistent. My photos are still the only ones that get red pins. The third was harder, but I can now produce a map and a list of places. The line just below the map gives you more control over the markers. The following list of places includes everywhere that has at least one photograph. (This list will change over time as new geotagged photographs are added to Flickr.) If you click on places in that list, the center of the map will move, showing you a selection of photographs near that place. The actual number of photographs shown depends on the zoom factor of the map. Mapping a point on the earth to its closest landmark must be a well solved problem. I can imagine a variety of hierarchical data structures that would provide fast, accurate answers. In my case, all of the computations are done “off line”. I don't have very significant performance constraints, so I went for the simplest thing that would work. The simplest thing, brute force, really won't work. Calculating great circle distances is computationally expensive, relatively speaking, and comparing each known point to all 84,000+ points in the list isn't practical. (I got the list by taking the GeoNames data and extracting all cities with a population greater than 1000.) To make the searching practical, I divide the world into a grid of squares, each two degrees of longitude by two degrees of latitude. Into each square, I place all the cities with a latitude and longitude that falls within that square or within one degree of latitude or longitude in each direction. (So a 4x4 square centered on the 2x2 square.) This extra “sloppiness” solves the boundary problem well enough, at least, for my purposes. Given a random coordinate, I can quickly find the relevant square. I then do a brute-force search of all the cities in that square. If there aren't any cities in the starting square, I search outward, building a larger and larger square until I find one big enough to contain at least one city. Then it's just a simple matter of collation. Just for fun, I'll see if I can make a simple web service out if this bit of code.