Geocoding with Google Maps and the mysterious "bewar"

As part of my current line of research on semantic photo annotation suggestion (i.e. trying to make it easy to do semantic classifications on Risukun.com), I started to revisit some prototype code I had kicking around for doing geo-annotations of photos via a Google Maps mashup. The API makes it very easy to throw an interactive map on your own page and write some javascript/ajax to make it interactive. In my case, it just simply allows you to specify the latitude & longitude of either an individual photo or a location concept (setting the location of an album will result in the location concept being inherited by all photos in the album) by clicking on the map. If the visitor is not the content owner, then the map simply shows the location if available. The zoom level is also saved so that at reasonable idea of the location's size can be inferred. The Google Maps API also provides a function to do a location search by address, place name, etc.

Since I have way too many photos to go back and do obsessive geo-annotation, I decided to compromise by just specifying the geo-coordinates for each location concept in my "Places" hierarchy. This got me down to only 162 places to geo-tag by hand, with about 7,600 photos associated with those locations. Clearly, I need to go back and do some more location tagging, but that'll be enough to do some initial experiments.

Now, getting back to Google Maps. The first thing I noticed was that the Japanese support had gotten much better since I had played with my prototype code last fall, from the Japanese place names being available to the support for Japanese cities and addresses using kanji. Very nice. :) However, I also quickly discovered that many searches for common landmarks, areas, etc. that work well on maps.google.com, like "Chinatown, San Francisco", "Coit Tower, San Francisco", etc., just fail on the Google Maps API version (I think I'm using V2 from the URL). This has resulting in my doing Google searches in a separate window (with regular Google providing a map most of the time above the web page results), and then requiring me to find the location by hand using the map on my own site. In addition, these locations often show up with labels on the current release version of Google Maps, but are nowhere to be found using the API. Even which streets are highlighted as being 'major streets' is different between the two. I guess they really want you to pay for the 'business' version of their maps service.

One final thing for thought that I wonder if anyway else as noticed. For kicks, I edited a Google Maps URL to go to latitude=0, longitude=0. In case you didn't know/remember, this is just a section of ocean off the western coast of Africa. However, if you zoom in anywhere between the 3rd & 7th closest zoom levels, there is a strange text label that appears: "bewar". Zoom in all the way and you get nothing but blue, zoom out enough and it disappears. Not the full word "beware" and not capitalized like a place name... just kind of... strange. Google searching only seems to find a city in India "Bewar" and numerous misspellings of "beware". Is this a bug? A strange easter egg? I wasn't able to find much about this. Perhaps some else knows about this?

Flickr finally adds (folder) depth

This morning, I noticed a new entry on Flickr's blog saying that they have added 'Collections', i.e. sets of sets. Although I haven't played with it yet (it requires paying for Flickr Pro... which I probably won't do any time soon as I have my own server and software that hosts my pictures), they say that it supports 5 levels of nested collections (I suppose this is reasonable, although it seems a bit arbitrary). This has to be the single most blatantly missing feature that would be required by any power user. At this point, I have my collection of approximately 37,000 digital photos is organized using over 2,100 folders. If I don't have multiple levels of folder organization, it's basically rendered useless for browsing.

In the process of playing with Flickr today, I discovered that the Geo-tagging map search supports Japanese place names (I did a search for 京都), but the map resolution for Japan (both satellite and roads) is so poor that it's basically useless for tagging much below the city level. Google Maps is clearly ahead of Yahoo Maps in this regard. I also discovered that Flickr supports unicode search, but mostly treats Japanese text as a single word, so a group search for "源氏" would not return a group containing "源氏物語" in the title. Didn't do an extensive test, so I don't know if they are at least breaking words at Kana/Kanji boundaries or not.

What other development system could get away with this?

Last semester, I did a class project where I compared a couple of approximate matrix decomposition methods for their ability to restore removed photo annotations. Since I already had an experimental frame created for this purpose in Matlab, I decided to continue developing implementations of the additional methods I was interested in comparing in Matlab as well. One of the methods I wanted to compare was Mor Naaman's neighboring time context, which of course requires date comparisons (rank annotations by the number of photos associated with them among pictures taken with X seconds of a candidate photo). This should be a simple built-in function call and, although somewhat annoying to deal with due to complexities of the Gregorian calendar, has been done in many other languages/frameworks (Java, C#, etc.). Looking around the Matlab documentation, I find the following 'Limitations' section of the etime() function:

"As currently implemented, the etime function fails across month and year boundaries. Since etime is an M-file, you can modify the code to work across these boundaries if needed."

What the heck? Not only is it not implemented correctly, they laugh in your face and just tell you to do it yourself. Further investigation reveals a copy of the docs with a 1994 copyright date containing a similar cop out! They've been sitting on this fix for 13 years! Searching around the web, I failed to find someone who had bothered to do this and share the library. "Great," I say to myself and proceed to add the value of C#'s DateTime.GetFileTime()'s function (which returns a long with the number of 100 nanoseconds since 1601). Granted, I only have second resolution on my photos anyway. Having look through Matlab's data types previously,
I know it has int64's, so there should be no problem. That is until I actually try to run it and I get the following error:

"Function 'minus' is not defined for values of class 'int64'."

What??? Further reading of the docs reveal the following:

"Note The arithmetic operators do not support operations on the data types int64 or uint64. Except for the unary operators +A and A.', the arithmetic operators do not support operations on complex arrays of any integer data type."

Who the heck doesn't bother to implement long arithmetic? In version 7.2 of a product? That is sold for hundreds of dollars? And why do they even support loading data into int64's if you can't do anything with them once they are loaded? To be fair, I found some docs from version 6 that had just announced the support for int64 comparison operators. Wonderful.

Fortunately, for my implementation, I realized that I was only using 12 digits of precision for my data's time values... so I just had to stick my 'long' data into a double and that was good enough to get my experiment working (although making me feel dirty in the process). I do have to wonder what the engineers at MathWorks are actually doing, if they haven't bothered implementing such basic things.

Photo Organization

As almost anyone who knows me is aware of, during a year of study abroad in Japan as an undergraduate (2002-2003 school year), I essentially become a photo blogger, going from about 500 pictures a semester to 2000+ pictures a semester. At this rate, the website I had created to share these pictures soon took on an urgent need to be able to organize, find, and browse these pictures effectively. The RisuPicWeb software that I've been developing to organize my pictures since 2002 was forced to become database-driven by 2004 when I started graduate school in order to support even basic search. The first database version was created as a graduate database class project, and I have continued to bend class projects to connect in to my personal photo management interests (as well as necessities) throughout my graduate education (I believe I'm up to about 7 picture-related class projects).

When you take a few hundred pictures a year, you can manage them (say at the file level) largely by creating a series of albums for the handful of important events. This is what software like Apple's iPhoto and Google's Picasa software handle well. At some point, however, you just have too many pictures per year and programs like iPhoto start to become unwieldly. At some point, multiple levels of folders seems to become almost essentially to handle it, especially for the browsing use case. Also, for me, half the fun of photos is being able to share them with people, and rich client applications indexing a local photo repository seem to fall short in this regard. Granted programs like Picasa now have integration with online posting, but, in my mind, I would have 99% of my photos online anyway. A rich client, however, would be a good substitute for an FTP program (which is what is currently used to upload pictures to my own system) to make it easier to use for casual users. Ideally, it would be able to sync with your local file store, so you can have complete backups of all your photos on multiple machines (i.e. desktop, laptop, web server) and I could post pictures from any machine and have them replicated. Perhaps at some level, I just want my photos in CVS/SVN.