9.3.1 What location information should we store?
When I mentioned locations, you were probably wondering what I meant. Well, we
could store a variety of different types of locations. With 1 byte, we could store countrylevel
information for the world. With 2 bytes, we could store region/state-level information.
With 3 bytes, we could store regional postal codes for almost every country. And
with 4 bytes, we could store latitude/longitude information down to within about 2
meters or 6 feet.
Which level of precision to use will depend on our given use case. For the sake of
simplicity, we’ll start with just 2 bytes for region/state-level information for countries
around the world. As a starter, listing 9.13 shows some base data for ISO3 country
codes around the world, as well as state/province information for the United States
I introduce these tables of data initially so that if/when we’d like to add additional state,
region, territory, or province information for countries we’re interested in, the format
and method for doing so should be obvious. Looking at the data tables, we initially define
them as strings. But these strings are converted into lists by being split on whitespace by
our call to the split() method on strings without any arguments. Now that we have some
initial data, how are we going to store this information on a per-user basis?
Let’s say that we’ve determined that user 139960061 lives in California, U.S., and
we want to store this information for that user. To store the information, we first need
to pack the data into 2 bytes by first discovering the code for the United States, which
we can calculate by finding the index of the United States’ ISO3 country code in our
COUNTRIES list. Similarly, if we have state information for a user, and we also have state
information in our tables, we can calculate the code for the state by finding its index
in the table. The next listing shows the function for turning country/state information
into a 2-byte code.
Location code calculation isn’t that interesting or difficult; it’s primarily a matter of
finding offsets in lookup tables, and then dealing with “not found” data. Next, let’s
talk about actually storing our packed location data.