Difficult to Develop Data: HUD Difficult to Develop Areas

Warning: This is a really wonky post that gets into some of the behind-the-scenes stuff that goes into our data. If you’re interested in some of the more esoteric problems we face, or if you’re a developer who uses LIHTC in Difficult to Develop Areas, read on.

Sometimes, data is simple to process. The BLS provides unemployment at the county level, and we display it at the county level. Simple.

Sometimes, it’s more complicated. For years, HUD’s Difficult to Develop Areas (DDAs) dataset was one of the easiest we processed. It was just a list of counties. This year, the data got a lot more complicated, and as such, a lot more interesting.

The Federal Guidelines menu has a lot of indicators that are arcane to anyone who doesn’t use them. DDAs are mainly interesting to people applying for the Low Income Housing Tax Credit (LIHTC), but they might be interesting to the general public as well. They show areas where the costs of construction, land, and utilities are disproportionately high compared to the Area Median Income. Places like vacation resort towns, where the land is super expensive, but the people who actually live there are service-sector employees who aren’t earning what the people vacationing there are. They’re important to LIHTC projects because they allow LIHTC projects to have higher construction costs than are normally allowable (more information on page 12 of this document).

While in previous years, DDAs were just select counties across the country, this year, HUD introduced Small Difficult Development Areas (SDDAs) in addition to the county DDAs. SDDAs are at the Zip Code Tabulation Area (ZCTA) geography, which you’ll hear a lot more about in upcoming posts. ZCTAs are like Zip Codes, except instead of being determined by the US Postal Service, they’re determined by the Census Bureau.

To make things even more complicated, some SDDAs are in ZCTAs that cross county or county subdivision boundaries, and they’re only valid in part of the ZCTA. This is because Area Median Income is determined by metropolitan area, and ZCTAs can cross metropolitan boundaries.

So already, we’ve got a problem: Some data is at the ZCTA level, some is at the county level, ZCTAs don’t fit simply into counties, and some ZCTAs are split into pieces by the county or county subdivision. We could show each geography on a separate map, but that would be super frustrating to users who just want to know about the DDA status in a particular place. We could disregard these new SDDAs, but then we’d be missing a whole segment of qualifying areas.

The solution turned out to be surprisingly elegant. We made a new geography combining ZCTAs with County Subdivisions. If you click on the map, you’ll get a geography with a name like “36792 (Jemison CCD)”, where Jemison CCD is the name of a County Subdivision. If you click right next to it, you’ll get “36792 (Centreville-Brent CCD)”. Only the segment in Jemison is a DDA, so the map looks a little funny:

As for the old county-level DDAs, they show up fine, since county subdivisions are (obviously) a subset of counties. Here’s the DDA for Cleburne County, Alabama:

Click on it, and you’ll still see a ZCTA-County Subdivision combination:

One nice feature you’ll still have access to is the ability to use this data in 3-Layer Maps. If you have a bunch of properties loaded through the Data Loader, and you want to find which ones are in a DDA, you can load the points and the DDAs in 3-Layer Maps, and download the points in DDAs.

For LIHTC users, it should be noted that because of this change, 2016 DDAs take effect on July 1, 2016 (and not January 1, 2016, as would have otherwise been expected). Plenty more information is available from HUD).

Hopefully for you, using DDA data is simple, and you don’t have to know any of this. But I hope it’s interesting to see the decisions that go into making it simple.