Wednesday, July 13, 2011

Today's serial installment about the Great Update I did last night will be about counties. When I first created Atlas Quest, I made an enormous blunder: I didn't include information about counties with each location. I chose not to do this because it seemed like a quaintly American thing and I was trying to create a website that could support locations from around the globe--most of which has no concept of counties. And anyhow, who cares about counties? I was more concerned about cities. That, and the state it was in, was enough to narrow down the correct city, right?

Wrong.... way wrong. Turns out, there are huge number of small podunks and small towns or even parts of towns that have the same name in the same state, and it wasn't long before the first reports of towns being in the "incorrect" location started coming in. However, they were typically small enough that I would manually change the location to the "correct" place and just not support the town in the "wrong" place. It's not an ideal solution--only admins could move towns, so if you found this problem, you had to go through us. And, more often than not, people didn't even realize that boxes they listed sometimes ended up mapping to the wrong part of a state.

Additionally, especially for people who live in large states, it would have been handy to be able to list a mystery box as being "somewhere in XYZ county" instead of "somewhere in ABC state." For a small state such as Rhode Island where any mystery box in the state is practically walking distance, not a big deal. For a large state such as California or Texas, a mystery box on the completely other side of the state may be a no-go.

And because of this massive design flaw introduced before AQ even opened for business, both of these problems lingered.

About a year after AQ went live, I tried to fix this problem after the fact. I worked on it for a couple of weeks, trying to fit counties between cities and states, and it was frustrating. And finally, it collapsed in a heap of failure. The way the database was structured, I just couldn't make it work, and I wasn't willing to commit to significant changes in the database to make it work--that probably would have taken me months to implement--assuming it even worked in the first place. I failed. Atlas Quest hobbled along, blissfully ignorant about counties.

Then I decided to support custom locations on boxes. Early on, while investigating certain aspects of what I'd need to implement, I noticed a problem with the geocoder AQ was using. (A geocoder, for those not familiar with technical terms, is a system that can translate an address into latitudue and longitude coordinates--critical for AQ to accurately map locations.) The geocoder AQ was using had been deprecated. Which means that it worked--for now, but Google might stop support of it at any time and that would leave AQ high and dry. I needed to replace the geocoder, ASAP.

That first geocoder I used was a huge learning experience for me, and if I had to rebuild a new geocoder, I could certainly do a much better job of it than my time around. The biggest issue was being overly reliant on just one external geocoder. What if Google suddenly stopped supporting the one I used? What if they changed their rules, or started charging for access beyond what I could afford? What I really needed was support for several geocoders--a minimum of two external geocoders, but the more the better. If one geocoder couldn't figure out the location you were trying to use, maybe a different one would? I could chain multiple geocoders together for a "super geocoder" capable of encoding locations that neither of them alone could do.

At this point, I was going slightly astray from my main goal of custom locations on boxes, but custom locations are only as good as the geocoders they are built from, and I was determined to make sure the new one would be awesome compared to the geocoder of the past.

When I looked at the geocoder Yahoo makes available, I found it included a piece of information I never had before: the radius of the location. For the first time, I had a source of information about the size of a location. There's a big difference between the size of a city such as Seattle and the size of a state such as California, and I immediately knew I could make very good use of such information to generate better search results.

And as they say, in for a penny, in for a pound. I was already going to completely rewrite the geocoders, I may as well start recording information about the size of the locations and the county that locations are in. Let's do this RIGHT! =)

It was time to take another whack at solving the "county problem." (Among others, but this blog entry will focus on the counties.) I toiled away for weeks, creating several geocoders, chaining them together, and associating counties with locations and storing information about the size of each location. And finally, I was done. It was working.

And now AQ supports counties.

When you list a new letterbox, you'll usually type in the city and state for your location, and most of the time, AQ will correctly figure out the county. If, however, you notice that the box seems to map to the wrong part of the state, edit your box and check the location. AQ will display what county it's using for your location, and if it's incorrect, you can fix it.

Additionally, you can now list mystery boxes that are "somewhere in XYZ county." For instance, you could list a mystery box as being in "King County, WA" or "Washington County, OR."

I noticed a lot of people added this information as the "address" of their mystery box, and I had AQ go through and automatically convert them into county-wide mystery boxes. It might not be a bad idea to double check the locations of the mystery boxes you planted to make sure AQ got this right. If you were clear and only wrote something like "King County" or "Washington County," there shouldn't have been trouble for the geocoders. If you tried typing something like "King or Pierce County," typed the name of the county incorrectly, or something like "Eastern King County"--something less than completely straight-forward, the geocoder was much more likely to choke on it and do something you may not have wanted.

Now a little about how to search for county-wide mystery boxes. If you visit the Advanced Search page, you won't find "Area Search" as a search type option anymore. The reason is simple: It's not needed anymore. To search for boxes in a county, just type the county name. King County, WA, for instance. This returns all boxes within the county--mysteries or otherwise. What if you just want the mystery boxes in King County? Before clicking that search button, click the "Mystery Boxes" attribute first to get this list.

When you run an area search like this, the "distance" option is ignored. All boxes are within the boundaries of King County. (As an aside, if you set the "distance" to zero, you can run an area search for all boxes within a city or even a specific park within a city. It forces all searches into becoming an area search.)

Now let's head on over to the Simple Searches page. I wanted to keep a simple version of an area search available, and you'll find that "state" part of an area search has been renamed into "region." If you look at the drop-down list, you'll see why--it includes all of the states and counties that you can run an area search for from the selected country. Before you go rushing off to run a search for your county, I should point out that the list does not include every county in the United States--it only includes counties if there's at least one letterbox listed as being within that county. For counties that have no boxes in them, you won't see them in the drop-down list. And that's okay--there's nothing to search for there anyhow. =) As soon as someone adds a box to the county (mystery or not, it doesn't matter), the county will start showing.

I also made another slight improvement that almost nobody will notice--but if you live outside of the United States, you'll love this one. =) When you open the Simple Search page, AQ defaults the country to the one you have listed in your profile. If you live in Canada, the area search will default to Canada. If you live in New Zealand, the area search will default to New Zealand. However, the only place AQ tracks your location is from what you type in your profile, so you'll need to fill out the location on your profile for this to work. (You don't even have to specify a specific city, county, or state--just listing the country is enough to make it work.)

So that's your lesson for today. =) Tomorrow, I'll be back with more details about the Big Update.

5 comments:

This is going to be so totally awesome when traveling to an unknown area so you don't get home and find there were boxes you missed because you are unfamiliar with the locale!!!!! Thank you Green One!!!!

Hmm.... I'll have to look into that "Washington, DC," problem. If you just type "Washington" it makes sense that you'll get a lot of Washington state boxes, but if you type "Washington DC," you should be getting DC boxes. (Or even just typing "DC" would probably work well enough--DC isn't a very large area!)

I admit, I didn't use Washington, DC, in any of my testing scenarios. It never even occurred to me! But I will take a look at it. =)