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.

Forgotten Dreams of Elves

Although the goal of this blog was to cover more research/technical things, sometimes other things will slip in as well. This is one of those times.

Last night I had a dream about something I hadn't thought about in quite a while: ElfQuest. For quite a number of years, from elementary school (starting in 3rd or 4th grade?) up through high school I was entirely obsessed with this wonderful independent comic book series. A classic work of fantasy, ElfQuest followed a tribe elves who ride wolves living in a primordial earth-like planet with two moons. Sadly (fortunately?) after two and a half decades of independent publishing, DC comics now distributes it in a manga-like paperback format. The best of the series is considered to be the first 3 series (all originally black & white), which were published in a series of 8 colored graphic novels, which is how I was originally introduced to it. I would read all the way through those volumes, excitedly pouring of the pages, and then start over again at the beginning. I lost track exactly how many times I reread those 8 volumes, and along the way I obtained a nearly complete collection of the original comic books they were published in and eagerly awaited the newest issues to read my local comic book store. I loved everything elven, and I excited used my first scanner and later my first laser printer to scan scenes of favorite my characters and post them up on the walls of my room (and they were still there the last time I was home along with my treasured ElfQuest poster). I in fact still carry a keychain that bears an ElfQuest scene (it was a keychain which you could open up and put in your own little picture--the rubber part long since too hard to open to change the picture). This was actually how I fell in love with comics and fantasy originally. And, interestingly, it was actually ElfQuest that drove me to Japanese comics in the first place, looking for a longer, more emotionally involved stories then I could be satisfied with the super hero comics that ruled in America. Ironically, also was that Wendy Pini (the artist/co-creator of ElfQuest with her husband Richard) was partly inspired by manga in the first place; the elves are reminiscent of anime characters, while the humans are closer to those of American comics. Thus, as I had already had a partial sense of the anime aesthetic burned into my eyeballs from my many readings of ElfQuest, it was not that large a jump to Japanese comics.

Waking up this morning, I found that ElfQuest was very much still on my mind, and a visit to the official website reassured me that it was still around. However, I realized that there was a bunch of stuff I had missed when I lost track of ElfQuest in college as I got deeper and deeper into Japanese. Near the end of high school, I had discovered Inuyasha (which I had originally hoped would be like ElfQuest) and then by association, I found Maison Ikkoku, which turned into my new obsession for several key years in college and was undoubtedly one of the reasons I ended up in Japan. Ironically, it was not the fantasy manga that really did it for me, but the a seinen romance series set in Tokyo in the 1980's. Of course, as a high school student, Tokyo was probably almost as exotic to me as the elves on the World of Two Moons.

In any case, I once more lamented the loss of my copy of the first ElfQuest graphic novel, presumably, lent to a friend in high school and never returned. Having invested so much emotion into a book, it was a very painful realization that I didn't know where volume one had gone. I had picked up the first volume of the DC comics reprint, but in black & white and with the page layouts redone for 'manga' size (as ElfQuest could fit in nicely with the booming manga market), it just wasn't quite the same as the oversized graph novels I had read so many times. Looking at the list of items for sale on the official website, I thus found my wondering how the new DC comics reprints fit in with the ones I knew (as they have 14-volumes published now) and ended up on wikipedia. To my surprise, they actually gotten up to a couple volumes near the end covering material after I what I had known. A quick look on Amazon found a hardcover version of volume one in the editions that I had originally read (I had actually owned the paperback of volume 1) being sold used starting for a bit over $10. Needless to say, I ended up ordering a copy out of nostalgia and a need for completeness (how could I not have the first volume of a comic I loved so much?) .

As a side note, my love of wolves (I spent much of high school wearing wolf t-shirts) also came out of ElfQuest, and this is part of the reason that Princess Mononoke is my favorite Miyazaki Hayao film. Long live the elves!

Searching History

Yesterday Google News unveiled archive search on the official google blog. There's something fairly cool about being able to search the last 200 of so years of news. Unfortunately, many of the articles only give you a preview and a link to buy them, but some of the sources are free, like Time magazine. For example, a search for Arthur Waley gave me a review of part 4 of his 6-part translations of the Tale of Genji. An interesting quote in the article that reveals sentiments of the period is "Translator Waley learned both Japanese and the still more difficult Chinese from native teachers in London." I've never particularly thought of Chinese as being much more or less difficult than Japanese. Another fun quote about Waley is "He has never been east of Suez, and yet he is a recognized authority on literature and art of the Far East." Although, I knew he had never actually been to Japan or China, I still found it amusing.

The archive search gives you nice options for filtering dates and publications, and so I could find several articles about computers from 1889, when 'computer' was a job position for a human. It would be nice to be able to search for 'free publications' and I did find what I assume was an error with the word database showing up in an act supposedly from 1776 (and in the contect of a DNA database no less). ;) The next reference of the word 'database' is 1984 (which is more like it). I sent them a feedback email about it; we'll see if anything happens.

Car Repairs

A few weeks back the wipers on my car stopped working. I don't mean that the rubber came off the wiper blades and they were uneffective, but rather that they stopped moving altogether. This is bad when you live in a climate where it rains. Fortunately, we do have a second car and I walk to school most of the time (when I'm not running late and my wife is nice enough to give me a ride...), so it wasn't extremely pressing. Anyway, it's a 1991 Honda Civic that I got from my parents as an undergraduate granduation present, and it's also the car that I first learned to drive on. At this point, it's blue book price is only $2500, so imagine my surprise when I go in to get the wipers fixed and they tell me they want to make about $1800 of repairs on it: broken wiper rods, shifter cable, hood release cable, 'bad battery', and then they were suggesting that I replease the timing belt on top of that. Well, I had known about the wipers, it had been getting fairly difficult to shift between forward & reverse (dad had suspected the transmission, which it fortunately was not), the hood had required two people to open it the last couple times, and the battery had died a couple times over the winter (...after the lights had been left on). Anyway, so many of those things were at least somewhat reasonable. In any case, after a couple weeks of agonizing and looking over old repair receits (my parents had religously kept them all), I finally took the car in and got the wipers and the shifter cable repaired today. The battery I can replace myself for half the price (and it's still works well enough to start the car), and it turns out it's only been 15k miles since my parents replaced the timing belt (to replace every 60k miles...), and I don't see a problem with it taking two people to open the hood. I must say that it's really nice to have wipers that work again and it's so easy to shift gears now. Between that and the free car wash, my old car has a nice, shiny feeling now. :)