On the Road Again: Using JMP Workflow to Identify U.S. Commuting Zones (2026-US-30MP-2876)

Hello, everyone. My name is Caleb King. I am a senior developer here at JMP in the DOE and Reliability Group. Today, I'll be talking to you about a topic that is not about design of experiments or reliability. It actually is a little side hobby, mine, on identifying labor markets and what we're calling commuting zones here in the US.

If you were at JMP Discovery, I believe 2 years ago, I actually gave a little bit of this talk as part of the plenary session. I've still been working at it. I've actually I've learned a lot of new things since then, and so I've been given an opportunity, thanks to JMP, to present on that additional work here. I'm going to show you how I used, or in my terminology, hacked JMP workflow to help me identify US commuting zones here in the US.

First, let's start with a bit of background information. I'll start where I started in my plenary talk, which is talking about metropolitan statistical areas, or more specifically, the appropriate term is core-based statistical areas. What are core-based statistical areas or CBSAs? They are something that are defined by the Office of Management and Budget, OMB. This is government stuff, a lot of acronyms, just so you're prepared.

There are two types of CBSAs. There's the MSAs, metropolitan statistical areas. These are the ones most everybody's familiar with. When you hear terms like metropolitan area, that's usually what they're getting at. There's also a smaller version called micropolitan statistical areas or μSAs. These are defined based on population. They identify the sort of large population center or population centers, and then they try and identify these other outlying areas that are connected to that.

Before we get into the details of how they do that, here's a map showing you all of the MSAs and μSAs. The MSAs are in dark green, μSAs are in a lighter green shade. You can definitely see a lot of them, so you're basically looking at where the biggest cities are. Got the big megalopolis here on the East Coast. In fact, there are some cases where they combine MSAs together to make what they call combined statistical areas, very creative naming, also called CSAs.

Now, how do they define these specifically? We saw a general definition, but how do they actually make these? Again, it's all about population. First, they identify what is a core population area with at least 50,000 people or core population areas. Those will be used to define MSAs. Now, the area that we're looking at are counties. These are the basic units that they use to define MSAs.

If you're going to identify one or more counties that have a total population of at least 50,000, that would then be used to make an MSA. If you can't do that, but you can find a couple of counties that have a combined population of at least 10,000 people, well, now you've got the starting of a μSA, a micropolitan statistical area.

They have a procedure for identifying those nucleus counties. Once they've done that, then they're going to use commuting data as the way to define the relationship between these counties. In this case, it's very straightforward. If I have a certain minimum percentage threshold of commuters coming from one county into the core county, then those are now connected as part of an MSA or a μSA. That's how MSAs are generally defined.

Now, let's revisit that map. You might notice there are a lot of counties that aren't counted in either an MSA or μSA. They're going to be maybe more rural or just they don't meet that population threshold. Well, as it turns out, there was a researcher back in the 1970s or so who saw this and was like, "No, I don't think that's really fair. We have a lot of rural counties that are getting excluded just because they don't have enough people. What can I do? What can I create to actually provide more coverage across the entire United States?" He came up with this idea called a commuting zone.

As you see in this description here, it's used by a few government organizations: in this case, the US Department of Agriculture looks like they use it. But in the very definition, they do point out that weakness of the CBSAs. It's primarily focusing on urban, suburban markets or labor market areas. It is excluding the rural ones. He wanted something that was more comprehensive.

Here's a map of what that looks like. Here are the 2020 commuting zones, the most recent computation of these. As you can see, they do cover the entire US. They do use counties again as the building block, but it is definitely much more comprehensive. Now, how do they define commuting zones? Well, this is actually a little more interesting than MSAs because it actually does look at it as a commuting network. What they do is they use a hierarchical clustering algorithm to create clusters, those commuting zones, on this network.

First of all, they have to define a flow metric. What they do here is, let's say I'm in one county, and I'm looking at the flow metric between me and another county, well, how many people commute from me to that county? How many commute from that county to me? Let's add them up, divide them by the smallest total number of commuters between us, and then we'll subtract that from one. What that does is induce a distance metric.

If we don't have a lot of people commuting between us, this value will be large, will be close to one, meaning we're very far apart. Whereas if I have a lot of people commuting between me, then this metric will be small, but the distance will be smaller. We use that to then define our hierarchical clustering. Now we need to determine where do we cut the branches? Where do we determine our clusters?

They use a metric called cluster containment as the primary tool to define that. Cluster containment is basically what percentage of commuters stay within the zone. Ideally, you'd like 100%. That means you've done a really good job capturing a very good commuter zone. But, unfortunately, not everything's that nice. Usually, there's a bit of leakage, as we'll call it. A few commuters like to go other places outside of the zone. That's to be expected, so long as a big majority of them stay within the commuting zone.

We want to make sure we define a threshold that does that. Now, one way you could do that is just have really big commuting zones. That will definitely ensure that everybody stays within, but then you lose a lot of resolution with that. It's a balancing act. How do I pick a value that balances size with containment? That's what they did to pick their value.

Now, I do like this approach because it is a little bit more algorithmically defined than just a simple threshold. It does take into account the network behavior. But they still have a bit of an issue with both of these in that they use counties as their units of choice. Why do I have a problem with that? Out East, counties are nice and small. They actually are a pretty good unit to work with. But the further west you go, counties get really big.

Now, counties are defined for political reasons, government political reasons. They weren't necessarily defined with statistics in mind per se. Let me illustrate an example. Let's go to California. I've highlighted three combined statistical areas. I'm going to zoom in, though, on this one county. This is San Bernardino County. This is the largest county by area in the Lower 48. The only place where you'll find counties or county equivalents larger is Alaska. Here in the US, this is the Lower 48. This is the biggest county.

This is the San Bernardino metropolitan statistical area, this whole county. Where's San Bernardino? I'm sure you may have already found it, but if not, it's down here in the corner. What people might think of when they think of metropolitan statistical area is, "Oh, yeah, there's a centrally-located place, and everybody's commuting to that." Well, it doesn't always have to be centrally located. That's fine. But there's this general idea of people commute to this place.

I don't know about you, but I don't know if anybody way over here is going to drive all the way over to San Bernardino. They could. There's nothing saying they can't. But it's more likely that they might go to, let's say, Lake Havasu City in Arizona. They might prefer to commute there because they're closer. So that's the downside of these large counties, is they don't adequately capture that true commuter behavior. I don't expect a lot of people maybe over here near Mojave Desert to come all the way to San Bernardino.

That's the problem with using counties. Then the question is, can we do better? What if we use a different geographical unit? I decided to explore this, and this is what I talked about in my plenary talk, is maybe we can use a different geography. There's many to choose from. In fact, you can break down counties into even smaller geographic units as this graphic illustrates.

Census tracts are one or two levels below just the county. The smallest unit are blocks. Now, we could say, "Let's use blocks. That is the smallest. That would give us the most fine detail." The problem with that is that blocks, when you're looking at commuter networks on blocks, you're looking at only one or two people going from one block to another, so it's really essentially overfitting, if you will. There's not a lot… You're going to capture too much behavior going on.

The idea is we can maybe aggregate up a little bit to capture more generic or general commuting trends. I actually played around with, after I gave that talk, looking at census tracts or census block groups. It turns out that I was actually getting very similar results with whichever one I used. Now, in general, there's something called the areal problem that you encounter when dealing with this type of behavior.

What it basically says is the area unit that you use, if you change that, you're going to get different results. It's actually quite surprising then that I used two different geographical units of two different resolutions and got similar behaviors. Ultimately, I just decided to stick with census tracts. There's not as many, I'm getting roughly similar results, it's a little bit easier to work with in this case.

The other question that I had is, "Well, can we use something a little different than hierarchical clustering?" Nothing wrong with hierarchical clustering by any means. It's actually better than just saying, "Here's a threshold." But there's still a bit of hands-on behavior that you need. You need to determine where do you make the cut across the branches of your hierarchical tree in order to make the clusters. Can we do something that's a little bit more hands-off, or it doesn't require as much knobs to turn?

Every algorithm is going to have some knobs that you're going to have to turn. It's more of, "Do we have good default settings that we could use or do we need less knobs?" That's the motivation here. In order to do this, we're, of course, going to need loads of data. Here we go. Here's a nice website, the LODES website. This stands for LEHD Origin-Destination Employment Statistics. I forget what LEHD stands for. I think it's Longitudinal Employment and a H and a D. I apologize.

But basically what it does is it contains commuting data, and it has it at the block level. They get this information from employment records primarily, which is a pretty reliable source. Now, this dataset, there are two sets of files per state. There's a main file which says, "These are all the commuting behavior within just the state." But we're also interested about cross-state commuting. We're not just going to focus specifically on within states, we want to capture that cross-state behavior as well. We also need to look at the auxiliary files, which says, "These are census blocks outside of the state that commute into the state." Every state has this.

Now, this is what I used in my plenary talk initially. This is future Caleb, though, coming back and saying, "I've learned some things now. As it turns out, this database actually prides itself on being pretty comprehensive to the point of including long-distance commutes." Not just really long, "I'm crossing a state boundary." I'm crossing multiple state boundaries. I'm crossing multiple states.

Now, there are some places like, say, Delaware, where if you're commuting from Delaware to DC, they're close. That makes sense. But, no, we're talking about commuting like New York to Florida type commuting behavior, which really stretches the definition of, what do you mean by commuting? Maybe you might have someone who lives in New York, and they work under contract, and so they're on a contract job down in Florida. Maybe they include that. It's a little weird.

For my purposes, I didn't want a lot of that. I want more localized commuting. I actually wanted to define local labor market areas. Having information like that could pollute the data, and I'd have to work to exclude that anyways. It's very few, far between, but it is a bit of a hassle to deal with. I ended up using the database that the folks who did the commuting zones did, which is the Census Transportation Planning Products, CTPP.

They take their data primarily from what's called the American Community Survey, an annual survey that's sent out to people all across the US. As part of that information, they ask about, "Where do you commute?" There's some overlap between this and the LODES database. There's, of course, some areas where they don't cover each other. But I decided to stick with this because there's not as much long-distance commuting that they capture.

I know where I'm going to get my data. How do I compile this data? Well, I could do the entire United States. There's only like 80,000 census tracts compared to millions of census blocks. But, again, I'm looking at a commuter network with over 80,000 nodes. I don't know about you, but I feel like that would be a lot on my poor computer here if I were to try and run an algorithm on the entire US at once. The folks who did the commuting zones, they started back in the '70s. Their computer power wasn't all that big either. They ended up dividing it into different regions, and I decided to do the same. I wanted to be nice to my laptop.

What I did is I divided it into five different regions. There's NE-MA: New England, Mid-Atlantic; MA-SO: Mid-Atlantic, South; MA-MW: Mid-Atlantic, Midwest. There's Center, this line with a bit of buffer on each side; the West, these states with a center line as the buffer; and then Pacific: Alaska and Hawaii. I didn't find any data on Puerto Rico. I guess I should have looked hard enough, so I didn't exclude it just because I wanted to ignore it. Absolutely not. I do want to do that. That's still to be done.

Now, again, these aren't distinctive zones. I want overlap because it could happen, again, that there are folks in a different region that commute to another region. I want to make sure I capture that behavior here. It will mean when we compile the data, that we just need to be careful how we compile it together. We can't just do a simple concatenation.

That's how I decided to divide up the work. How do we now generate the clusters? What algorithm am I going to use? Well, unfortunately, as of the making of this presentation, JMP still doesn't have capability to do network analysis yet. Yes, I have hope. But R does, and JMP has a way to interface with R, which is great. In R, there's an igraph package that contains a lot of stuff for dealing with graphs and networks. I am particularly interested in community detection, which is a fancy way of saying clustering on a network.

Now, I've listed here some example algorithms that we could use. I've color-coded this blue one because it actually is different from the others. I'll go into detail on the next slide here. Most algorithms use something called modularity as the basis for the clustering. Think of modularity a little bit like a chi-squared statistic from a contingency table test, if you're familiar with those. It basically is, "I see an observed count in the table, and there's what I would expect based on certain assumptions I make."

Same basic idea here, except I'm looking at the actual number of edges with a node versus what I would expect under just a completely random network. The idea being that if I have more edges than I would have expected, that could be a sign of some clustering happening. Now, this is a pretty decent metric to use. There are some downsides, though. One of them being what's called a resolution limit, where if you have a large network like I do, you can miss smaller communities just because of the resolution. Now, there are ways to overcome this, but it is going to require a bit more dialing of knobs to get things right. Again, I want to try and minimize the number of knobs I need to dial.

There's this other algorithm called InfoMap, which uses something called network flow, which is interesting because I'm looking at commuter flow across a network. This seems like it might be more appropriate. In fact, what it does is it is imagining people flowing across the network, the little units flowing across the network, where the weight of an edge gives you a sense of how much flow is happening.

The idea is I want to describe the flow in this network, but I want to use as little information as possible. Maybe I can group nodes together to describe common areas of flow, and do so in such a way that I don't require a lot of information then to describe the network. An example might be, let's say I took a trip up to New England and I wanted to tell you about my trip.

Well, I could give you a super detailed itinerary of every single place we went. You might be interested in that, but that's a lot of information. Or I could summarize it a bit and say, "We went to Boston for a few days, then we went up to Acadia National Park, went over to Concord in New Hampshire for a little bit, in northern New Hampshire." I could cluster things a little bit that way. Or I could cluster it all the way and just say, "Yeah, we went to Massachusetts, Maine, and New Hampshire and a couple of other states." Well, of course, one has too much information. One has not enough information. Somewhere in the middle is a nice balance. That's the idea behind InfoMap. Where's that nice balance in information?

I know what algorithm I'm using. I know where I'm getting the data. I've mentioned JMP workflow. It's about time you actually see it. Now, I'd love to walk you through the entire workflow and run it for you, but it does take a bit of time to run because of especially how much data it's dealing with. Again, there's a lot of tracts in these regions. What I'll do is… I've generated some slides and some example tables on those slides to help you get a sense of what I'm doing in the workflow.

But here's what it looks like. These first two steps here basically lay out some foundational stuff. I edit a field in this file for the region. I tell it NE-MA, MA-MW, and such. It's got some associative arrays that I've defined there that help identify what states go in the region, what are the neighbors of each state, FIPS codes, and things like that that are needed later. This other one just defines a function that gives the REST API call to CTPP.

This next step, then I go out, grab the data, I compile it, put it all together. Then I'm going to have a few steps here. This is actually preparing it. I'm going to create a simplified table to send to R to do the community detection. That's this step. I send it to R. It does the detection. I get it back. I append it to the table. Then I've got some post-processing steps that I do to help strengthen the community zones that I'm looking at here.

Then, finally, I'm going to save everything out. I'm going to go back out to R and use some of its capability to save these as shapefiles, which then I can use a GIS software to help visualize and save stuff for JMP to work with. That's the overall flow. Again, this will be saved as a file on the page where this talk is located. You can go in and look at the detailed steps if you'd like. I'll try to add some comments to help explain theirs too.

But let's walk through what this might look like. I end up with a table. Let's say I'm looking at the NE-MA region, New England and Mid-Atlantic. I've run, I've got the data, I pulled it into JMP. Here we go. Here are all the edges, over 900,000 edges with each with a different number of commuters. This is the raw data.

The next step I'm going to do is I want to make that simplified table. I go in, I'm going to summarize based on the tract. That helps me identify unique tracts, and I'm just going to take the table row as the row ID. I'm going to give it some simple IDs to identify it. I'm also going to compute percentage commuters. If I were to sum over this particular tract, which goes from 1 to about row 25, if I added up all of these, that would sum to 1. The weighting is with respect to where my origin is, not my destination. If I sum over all the edges going out from me, that will add up to 1. That's how I define percentage commuters.

From this, I'm basically going to take these last four rows here. I'm just going to get rid of the tract stuff and give it a simplified table to send to R. What's interesting is, again, in R, it has no idea that this is geographic data. All it's been given is, "Hey, here's a network with some weights. Can you cluster this for me?" It's very surprising then that the clusters I get make geographic sense. You wouldn't necessarily expect that given what it's given, but, apparently, it works. That's great.

This is what I feed R. R goes, does the clustering, and I append it back. Now here's what my table looks like. I've got my clusters. Now, at this point, I could be done. I could say, "I've done my clustering. Let's start to compile stuff and go forward." But I actually want to make sure that I have good cluster containment. Remember that metric.

With InfoMap, it's not really concerned with cluster containment. It's just describing the flow. What could happen is I could have a commuter zone that is identified where actually most of the commuters go outside that zone. It's identified in one zone where it sees some patterns, but a lot of people tend to go out, maybe because it's really spread out or something.

I want to make sure that my zones have high cluster containment. I'm going to do some post-processing here. The first step is I'm going to do it at the cluster level. What I'm going to do is I'm going to summarize things. Actually, excuse me, before I get to that step, I almost skipped this step, I'm going to save the original clusterings for reference, and I'm going to create a working column here.

I'm going to do this because I'm going to be updating this column. I want something that references, "Here's what it was, I'm going to change this." It's a working way to work as a reference for me to work off of and reference things as I update this table. Whereas these last two columns, I'm permanently saving those. This is what R gave me. This is for reference, for historical reference.

Let's start with this idea of mismatched clusters. What I've done here is I've summarized up to the cluster level network essentially. That's what I've done. I've summarized by each cluster, W cluster. Again, this is the origin, destination, where it is. What I want to see is something like this first row. Here, almost 79% of the commuters stay within the zone. That's great. But that doesn't always happen.

For example, here I've identified a cluster, 58, where the majority want to go to cluster 47. Well, if that's the case, I call that a mismatch. What I'm going to do is I'm going to reassign everyone in cluster 58 to cluster 47. That way, people are going where they want to go. I don't want people to feel like they're constrained outside of that. No, I want to capture where people actually want to go.

That's how I handle the mismatch clusters. What I do is I basically make a little table like this where the mismatch cluster is, "Let me update, reassign you with this cluster," and then I'll rebuild this table using a while loop and make sure, "Hey, so long as there's stuff coming out, let's do this update. Let's keep doing this." Most of the time it doesn't take more than one or two runs, loops through the while loop to do that. That's what's happening in that step.

The next step, same idea, but now it's at the tract level. Basically, the idea is for a tract, it exists, it's been assigned one cluster, and it has commuters going somewhere else. The idea is that, well, I want most of the people who are commuting from this tract, I want them to be going to tracts within the same cluster. That's what I'm checking here. It exists here. I want this, something like this, where the largest percentage of commuters are within the cluster.

But, again, that's not always the case. For example, for this tract, it's been assigned cluster 37, but the majority of its commuters are going to cluster 35. Now, in this case, it's not a majority in the sense that greater than 50%. It doesn't have to be. It just has to be the highest percentage. What can sometimes happen is there's a little bit more dilution, if you will. The remaining percentage commuters are much smaller.

I'm just looking at the maximum saying, "Well, the maximum percentage should stay within your cluster." We have some mismatched tracts. It's just the same idea. Let me reassign all of these tracts and then recompute this and, again, keep checking to see, "Are there still people mismatched?" Again, it usually takes one or two runs to do this. It's the same basic while loop as I used previously, just at the tract level.

Now you think after this, "I should be done. Everybody's going where they want to go." You'd almost be correct. But, again, what could potentially happen is… Here I've got my cluster containment. I get, basically, a cluster level network I've summarized everyone to. Now I want to, again, check, is that max percentage commuter, is that greater than at least 50%? That's my threshold for cluster containment. It's a bare majority, essentially.

Here, I've computed some other columns, cumulative percentage and top destination. This top destination basically says, "If you're the first row in your cluster group, you get a one. If you're less than or equal to 50% or not crossing that, then you also get a one." Ideally, I want to see something like this where I just get a one because I'm the first thing. I have already exceeded 50%, I'm good.

But there could be cases where that cluster containment is still less than 50%. I'm just looking at the percentage maximum. What it's saying is there's a lot of leakage happening. What I'd want to do is I make a table like this where, okay, we're all the top destinations. If I see one where I've got duplicates on the H cluster, that means I haven't achieved my threshold yet.

In this case, I actually happened to. All my previous post-processing worked, so I achieved my bare minimum of at least 50%. But it could be lower. In that case, what I want to do is I want to sort who has the smallest cluster containment, and then I'm going to reassign you to who's your next biggest destination percentage. I'm going to merge you into that. I'm going to reassign you there, and we're going to rebuild this. Again, who's the next smallest? I'm going to slowly work my way up until everybody has at least a minimum cluster containment of 50%.

I'm basically going to merge people together until all the clusters I see contain at least 50% cluster containment. In this case, when I ran it, the first two was enough. I didn't have to do any extra post-processing. Not always the same. So I've done a lot of post-processing. I'm good now after these three. Then here is my final table, what it looks like for this region. It's basically a network at the tract level. Where am I coming from? Where am I going? How many people are doing it? Here's some simple IDs. I save them. I don't have to keep them, but I did. What was my cluster after my post-processing? What was I originally?

Now, after I got this table for each region, I've got to carefully concatenate them together. I do that by first I've got to look at the map of the region. Sometimes I end up with what are called artifacts. They're like little tracts that are isolated islands away from where they've been assigned. I usually will then reassign those to their neighbors because I don't want little artifact tracts going around. That doesn't really chime with the idea of a commuter zone.

Then once I've done that, I also need to check and make sure, hey, when comparing two regions, if there's overlap between those, if there's overlapping zones, are they consistent? If they are, that's great. I can just pick one from one region, exclude it for the other, and concatenate them together. I did a lot of work both in JMP and in this free GIS software, QGIS, to make sure everything compiles nicely.

I also used the QGIS software to create shapefiles specifically for the commuter zones, basically aggregate up to a commuter zone. I also created something called commuter regions. Basically, there are some cases where for commuter zones, they had a certain percentage, say 10%, going from their zone to another zone. I said, "You know what? We'll do the same idea as a combined statistical area. I'm going to call them commuter regions and combine them just to see how they combine together." That's what I did here.

That's all the work I did to make the final result. I could stop here because that was the talk. It's JMP workflow making commuter zones. I told you how I did that. You know what? Let me actually explore the results. There's some a lot of fun stuff here that we can look at. Let's go over to JMP. Here, I got it in JMP 19. Here are all the commuter zones. Here's the data. Now, it is at the tract level. I've got a lot of geographic information here. This is just pulled in from the shapefile stuff. A lot of the information is over here. There's the population.

Here are the zones. What I did is I painfully went through all 1,100 or so of my zones and tried to name it according to top destinations or regional stuff as follows. That was a bit of work, a lot more than I should have done. But, hey, we have a nice table to work with. Let's look at a map of the zones. Here they all are. Again, there's 1,100 or so. Don't worry. I did do it for Alaska and Hawaii. I have separate maps. They're hiding over here in the corner over here. But this is what it looks like for the Lower 48.

Now, if you're not aware, in JMP, there's this cool tool called a hover graphlet, where you can hover over something and show up a smaller graphlet showing some additional information. Here, I'm going to look at where are their top commuting destinations. Let's pick a region. How about this one? I'm going to give it a few seconds to hover over. It's got to pull some stuff together. Oh, here we go. I'm going to click that, zoom it out for us, give it a few minutes. This is the Research Triangle. This is where JMP is located.

What I'm showing you here is in the red, this is showing you the locations of if I were to rank destinations by number of commuters, and I were to cut it off at the top 50, where are the top 50%? Here it makes sense: Raleigh, Cary, and Durham. Those are the top half. That's where the top 50% of commuters go. The blue says, "Well, if I do the next 40%, where do they go?" If you look at the blue and the red, that's where 90% of commuters are going in this area. You get a sense of where people are going.

Sometimes it's pretty concentrated here. It might be a little more spread out, but we can get a sense of where people are commuting from. Let's find another one. I'm going to look at this light blue region here. Let's see if that pops up here. There we go. That is where I live. This is the Roanoke-Salem commuting zone. As you can see here, this is basically Roanoke-Salem, both of the cities. That's where most people commute. 90%, a lot of people can commute maybe to Rocky Mount, commute there or commute from there. It's interesting to see where people are going.

That's one way we can use these commuting zones to see where do people commute to, the top places that they're going. But there are other metrics that we can compute from this. We use these sometimes to identify labor zones. One thing we can look at is, what are the top industries by each commuting zone? I actually have that here. I've created a table in another table.

I'm going to pull up a map. It's going to look very similar, but now when I hover over things, let's hover over right here, here I've got a bar plot showing you the top industry. I'm using what's called the NAICS codes for industries. The biggest one that you usually see is what's called social. This is basically anything that's done to support society. Medical is provided in here, a couple social services as well. That tends to be the highest one. Here the next highest is professional. This is the Research Triangle. Research, technology, a lot of professional labor there.

Let's explore some other ones. How about this guy? You can probably guess what this one is. This is Las Vegas. In this case, the top industry is recreation, entertainment. Las Vegas, entertainment capital of the US. That makes sense. Let's try some other ones. I'm going to hover over this guy. San Jose, Silicon Valley. Notice that the top is professional. I'm going to find one more if I can see it.

There's this little pink region here. Fayetteville, North Carolina. Oh, come on. There we go. Here, again, social is the top. What's the next one? Military. Fort Bragg, I believe, is there, unless I completely screwed up the name. But there is a military fort nearby. You can get a sense of what are the top industries. There might be some. I think I can find maybe one more. No. Recreation. There's a couple of others where recreation could mean national parks and such.

We can identify labor market areas. That's fun. How about some other stuff? Let's talk about some extremes. For example, you can think of smallest and largest commuter zones. How about by land area? What's the smallest and largest by land area? I've got these to show hover labels as well. What's the smallest? Western Islands of Hawaii. They don't even show up here. They're tiny small islands off Hawaii, three square miles, essentially. What's the next smallest one? Let's see. Block Island, the little island off Rhode Island, is the next smallest. In fact, a lot of these are islands. I believe this one is Nantucket. Then we've got Staten Island, is the next one. A lot of islands on the small end.

What are the biggest ones? You can probably guess. The biggest one is North Slope. Now, I apologize. This is something a little wonky with the graphs. This should be down here. It's the top part of Alaska. In this case, over 85,000 square miles. Alaska's going to have a lot of big ones. If I look at the next two here, it shows up. Come on now. There you go. Basically, a lot of big places in Alaska. Like I said, a lot of big areas in Alaska. But that's land area. That might interest some people.

But we think of these as population centers. Where are the biggest populations? Let's look at that. What's the smallest population? Let me come down here. Who has the smallest population? It is, if I can hover, McMullen County in Texas with a whopping 623 people in that area. The next smallest one is Loving County in Texas is there, Block Island in Rhode Island. Those have a lot of small people.

I'm going to zoom in here. Who do we think the big players are? Who's going to be the most populous? I'll give you a few seconds to guess. It is Los Angeles with over nine million people. Next biggest, that would be Chicago with eight and a half million, followed closely by New York with eight million. Rounding up the top five, we've got Dallas-Fort Worth, 7.3 million, and then Houston with 6.8 million. There's your big guys.

But you might come back and say, "Yeah, I get it. Big populations. But, no, the small ones had a lot of small areas in them. You've got to account for area." You're absolutely right. We should look at population density. This is the last thing we'll look at for this talk. Now, when you talk about population density, the common metric is people per square mile.

I don't know about you, but I sometimes have a hard time imaging or visualizing a square mile. I heard from some folks that blocks out West, you can do four square blocks, and that's about a square mile, so that's nice. But back East, we apparently don't care about standards like that. We don't have nice measurements like that. I have a hard time understanding what's a square mile, how do you fit people in that?

What I'm going to do is I'm going to reverse it. I'm going to look at square footage per person. Basically, the idea is I live out in this particular zone, how much square feet of land can I have around me to represent density in that way? I'm going to compare it to known quantities. Here, what's the smallest one? Staten Island. Everybody there, if you broke everything down, gave everybody their own piece of land, they'd have roughly 3,200 square feet: a decent-sized house, essentially.

If we move up a little bit, so we've got a couple of smaller areas as well. Orange County, effectively, in California. Here, who's this? If you live in… Let's see what it's going to pull up. You can do it. Savannah, Georgia. If people here, they have enough space that they could have their own Manhattan city block if they wanted. Or you could live in one of the places here. Let's see what pulls up here in the middle. Everyone living in this place would have enough space, Vinita, Oklahoma, apparently, to have their own Amazon fulfillment center. You could fulfill your own Amazon orders if you wanted.

Or how about here? If you lived in this zone, you have basically enough space. Presidio, Texas, there's enough people living here where they could have their own major airport terminal worth of space. Or say, how about up here as we keep going? Who's going to show up here? If you live in Tanana Valley, Alaska. Up in Alaska, there's so few people around there that everybody has the equivalent of three Central Parks stacked together of space. But the fun ones are up here. This guy, if you live in Eastern Yukon Valley, Alaska, you can have enough space that you have your own half a capital. Take half of DC, whatever half you like, that's all yours now.

But there's one place, one zone, where you could have enough land that you can make your own country, specifically the nation of Andorra between France and Spain. What is this wondrous place, you might ask? That is Isle Royale National Park. There's one or two probably park rangers who are just having the time of their life with all the land they could ever possibly want in that place.

There's the example, there's some exploration of this. There's, of course, a lot of other things we can look at. I've got maps that look at industry distribution. I'll just play around with some of these as we wrap up here. But, yeah, there's so much to explore with this. I hope through this talk that I've shown you ways that you can use JMP to explore interesting things, side little hobbies, and such. I've had a great time looking into this data. A lot of this I'm going to make available to you on the page, so go in, explore. This is going to be great. With that, I'll wrap things up. Thank you very much.

Thank you, Caleb. That was awesome. I am going to stop that recording. Hopefully, they cut out me at the end.