overlay - Apportioning Neighborhood Information to Census Tracts using ArcGIS Desktop?

I have a shapefile of census tracts and another shapefile of "neighborhoods" with values that I need to have joined to the census tracts. I know I need to apportion the area of the neighborhood shapefile to the census tracts (the neighborhoods are larger than the census tracts and I ultimately need the data by census tract) and then allocate the number of properties that paid property taxes in the neighborhoods to the census tracts proportionately. Hopefully I don't have that backwards.

Any suggestions?

Answer

What you're trying to do is known as apportionment. This takes a numerical attribute value of a feature and divides it in some way between pieces that feature is split into. There are a number of different solutions. In fact, there's a specific tool for it in the Business Analyst extension, but you probably don't have that. Esri has also published a presentation outlining three different apportionment methods using core functionality (ie, no extensions required). There's also an Esri Blog entry on splitting polygons, and while it uses lines and polygons rather than polygons and polygons as you have, the principle is the same.

The basic solution is you're going to want to use Make Feature Layer on the polygons you want to apportion and be sure to set a Use Ratio Policy on any fields you want to apportion. This allows the use of Split (and Merge) Policies when running Overlay tools like Identity or Intersect. Once you've enabled that, when you run the desired overlay tool using the feature layer as an input, it will divide the field value between the created pieces based on their area ratios. The blog post linked above gives a much more thorough and step-by-step explanation.

Note you can apportion different ways, and what's described above is by area. This may or may not work well for what you're trying to do depending on boundaries. For example if you divide up a county into parts and apportion them equally by area, that's not a very accurate population distribution since you know population is going to be concentrated in and around cities, not evenly dispersed across the entire county.

I should point out you may have several steps here. If your neighborhoods are bigger than census tracts, you may first need to apportion your tracts and then dissolve that result (aggregate) with sum statistics to get a single value for your neighborhoods. Without a clear picture of your data, it's hard to say exactly what your workflow will be.

---

I don't really have a convenient dataset to test this out with, so it may not work exactly as advertised.

I understand you have neighborhoods with a numeric attribute field that is paid tax count. You want that count divided up among tracts, which are typically but not always smaller than neighborhoods. This means a tract may need to pull from multiple neighborhoods to get a total.

Again, be aware this method apportions by area - if you have a concentration of small properties in one corner of a neighborhood and the rest are large but it's being split evenly to two tracts, both tracts will get an equal count.

1. Run Make Feature Layer on your neighborhoods polygons. Be sure to check the Use Ratio Policy box for your paid tax count field.


2. Now using an Overlay tool, cut the resulting feature layer (input) up with tracts. If you have and Advanced/Info license you can use Identity. If not, I suggest Union. This should result in a new feature class with your neighborhoods cut into pieces that match however they overlap with tracts. You'll have a bunch of attributes, but the two you care about are the tract name/ID and the paid tax count which should be apportioned to the pieces. All other attributes can be deleted (unless there's more you care about). Word of warning: if the boundaries of your neighborhoods and tracts criss-cross a lot (particularly if the lines are supposed to be coincident [right on top of each other sharing vertices] but aren't), you're going to end up with a lot of sliver polygons. Likely with some ridiculous decimal point values for counts. These will go away with the next step, but a) could result in increased processing time or potentially crashes if there are a huge number of them, and b) may give some fuzzy rounding math in your final result such that the sum of the parts is greater or less than the whole.


3. Now run Dissolve on the previous step's output using tract name as the dissolve field and choosing the paid tax count as a statistics field with a sum type. I'd scroll down and make sure 'create multipart' is not checked. This should combine all of the polys belonging to the same tract into one shape with a sum total paid tax count from all the parts.


4. Optional but suggested integrity check: Open the attribute table of the dissolve output and using summarize/count or some other such method ensure that every tract has a single record. By not allowing multipart features you ensure that if for some reason the geometry didn't flow like it should you'll get two records for a tract - meaning what should be a single number is split in two, and you'll want to investigate these records if any. Had you allowed multipart, there'd just be a single record and you could somehow have a single tract as two disconnected areas.


5. Now you should be able to do a simple join between your original tract feature class and your dissolve output, using tract name as the join field. Be warned that if you do have more than one record per tract in the dissolve output, the join will work but only return the first found record (with no warnings stating this), creating an error in your data.