The first pass of scoring is complete, sort of. The map of all the selected tracts is below, and it’s apparent that the strategy of selecting just those tracts that have bus stops is insufficient, there are a number of census tracts inside the TriMet service boundary that have no bus stops. So I need to do a bit more work on that.
But I’m more interested in the fact that the map is pretty “flat”. There aren’t a lot of variations from tract to tract (there is of course the expected increase in scores as you move toward the center of the region). I’m wondering if a census tract is too large a unit, if it “evens out” differences in service levels across too big a geographic area.
One commenter suggested using census block groups, the next smaller unit (about 3 or 4 per tract). I’m going to look at that because the ACS data will have some information at that level.
So look for another map, hopefully by next week. I’d welcome other thoughts or suggestions. And I’ll get a tabular data set of points up once I’ve filled in the holes in my map.
9 responses to “What’s the Right Scale for Our Equity Analysis?”
In my work, I always start with the census block and then work upward. Even if you don’t have data for every census-block, you can use what you have to make an [stated] assumption about the rest of the block group, so it’s a win-win. The downside is, I don’t think ACS comes disaggregated by census block unless you have the special password.
Census tracts are a really challenging thing to work with. It is true that by increasing the space you’re filling, you’re also causing your aggregates to regress towards the mean. You haven’t posted a lot of details about what your methodology, but the question I wonder is why you’re using tracts at all. You were building a grid already, and this is a classic example of what should be raster-based analysis, not a vector one.
You’ll notice that that’s how the Equity Atlas was done, as is the Transit Score put out by the Walk Score people: http://wiki.walkscore.org/transit-score
Relatedly, I know you’re unsatisfied with the result of the Transit Score and want to find something “right”, but but that seems to going about it backwards. You develop the methodology, then generate the data. If you feel that the transit score too heavily favors rail, then make an argument for why that is so (use data!) and adjust the coefficients, or make your own algorithm. But don’t put the result before the methodology.
I think it’s entirely fair to make sure we don’t pick a methodology to demonstrate our hypothesis :-)
In general I think the more granular the data the better. Since the goal is to correlate transit score with demographics, the best case is the smallest unit for which demographic data is available.
I suspect we’ll be able to get some data at the block group level, but richer data at the tract level.
So the answer is we’ll do both, so everybody can see what the results look like.
And a raster display is clearly best, which is why I’m looking for a good heatmap tool. But I can’t do demographics at a raster level, I have to aggregate over some area…
Just a quick thought: although ACS will have data at the block group level, the margin of error for that data will be much larger relative to the estimated population numbers than it will be for the census tracts. This may particularly affect any analysis that segments already small estimated populations by income, ethnicity, race, gender, age etc… So, although census tracts aren’t great for granularity, you wouldn’t want to use block groups unless the margins of error are fairly narrow.
Don’t bother with some specialized heat map tool, just use gvSIG. http://oadigital.net/software/gvsigoade
I can think of a few ways to deal with correlating your tract data to your raster data.
The simplest and arguably best is that you can calculate the score, then take the median score for the tract/block group as being representative. (You can also specify quantiles, which is quite nice.)
Alternatively, you could partition the tract up using the grid of the raster. You could “allocate” population within the tract geographically by doing something like using road density as a proxy for residential density, you would just have to normalize the road density so that sums to 1 within the tract.
I could probably think of a couple more if I weren’t supposed to be working.
Block group data is definitely better than tract, but you could also use block level data, and then pull down rates from block groups for certain things… I don’t see much reason at all to go with tract. Too big.
The bigger issue is, the data is now ten years old, but new data isn’t due for another two years!
Right, but the ACS data is out in December (five year averages). The question is how much ACS data will be available at the block group level and what is the margin of error?
Whew!
Uh, is there a key for this map so I can get some clue as to what this is all about?
I haven’t figured out how to lay a key on top of it, but blue/dark means lower transit score. As the colors get hotter/lighter you get higher transit scores.