|If only Anthony Weiner twitted this photo instead....|
The reason there's no blog to tell about it is because there's not much to tell. It's like a lot of those updates I often do without taking Atlas Quest down at all and nobody ever notices.... Changes happen, but you either can't see them, or they're so minor, you'd often not notice them.
But when I actually take Atlas Quest down and people know I'm up to something, there's that curiosity--what is Ryan up to? What is he changing? Something is clearly happening.... but what?
This particular update is the next stepping stone on the long road to a new and improved geocoder experience which I've blogged about before. This time, I rolled out the geocoder updates to event listings. If you add or edit an event listing, you'll notice that the "location" page of the listing has changed quite a bit, and--IMHO--is a lot less fussy about supporting locations that cannot be geocoded or if multiple matches are found. It even displays a cute little Google map of the location that was geocoded so you can confirm that that's exactly the location you were talking about.
The update itself was relatively quick and painless.... the reason I took AQ down for the better part of an hour was to convert the "old locations" into the "new locations." The conversion process isn't perfect, and I set up AQ to automatically do the conversions as well as can be expected, then had it send me a list of conversions that weren't "perfect." Anything where the old location didn't quite match the new location. Such as an old location of "3036 SW 3rd Ave, Seattle, WA, US" suddenly turning into "3, 3036, Beijing, Beijing Shi, China." I see something like that and I think, "Hmm.... something bad happened in that translation....." Then I'd laugh at my unintended pun before figuring out what went wrong. =)
About 3% of the conversions had problems. There are about 2,000 events now listed on AQ, so about 75 had issues I had to fix by hand. Japan and China listings were unusually common among those!
In truth, I wasn't especially worried about locations that were in the past. So if that event from five years ago is now listed as having took place in China, who cares anymore? =) But still, I looked through all of those old entries and fixed them because they were test cases that failed! I needed to figure out why these entries had failed and figure out if there was some way I could fix things so when someone is trying to list a new event, that doesn't happen again.
It's amazing what you can learn from things that don't work properly. =) I found several tweaks I could make to my own code that helped matters along a bit better, and if I tried running the conversions today, there would still be some failures--but almost universally cosmetic ones.
A cosmetic "failure" would be something like the old location being "Montana de Oro SP" while the new location maps to "Montana de Oro State Park." Technically, the location is correct and spot on and "fixing" this problem wasn't necessary. But still, it wasn't an "exact" match and my code isn't smart enough to realize that they were two different ways of saying the same thing, so it would report to me the "non-perfect" conversion.
It's important I get this right, because eventually, I want to roll out these same changes to boxes. There are currently over 100,000 traditional letterboxes listed on Atlas Quest, and about 65,000 of them are listed as "active." When the locations for these boxes are updated, I need to make sure they don't end up in China! And while I could go through 2,000 event locations in one night correcting errors, going through 100,000+ letterbox listings is a mammoth undertaking that could take eons. I will need perfect conversions with a high success rate. Even with a 1% failure rate, I'd still have to manually fix over a thousand listings.
And while fixing the listings, it also allowed me to use the real code for editing locations on the live website. It let me check that the maps were displaying correctly, and it let me check that it handled things properly when no exact matches could be found, or when more than one matching location was found. I was able to do a lot of testing during the process of fixing problems! =)
It was a grand old time, let me tell you. ;o)
In related news, everything that comes with the new geocoders also works with events now. For instance, you can now run a linear search or rectangle search on events. Additionally, if you pull up an event listing, you can now tag it with a "custom location." Imagine an event that's a mystery location--once you've figured out the location, you can specify it in your custom location, and it'll show up in event searches at your specified location. (Nobody else can see your custom locations, though, so it won't be a spoiler for others.) And the new geocoders are much improved over the old one. Thousands of more parks and places are now supported than ever before.
Lots of good stuff going on! =) But unless you're an organizer for an event, you won't really notice most of them at the moment.....