For a project I am working on I would like to intersect fire station response districts with income data to determine the median income per response district. However the borders of the layers obviously do not line up. What is the best method to go about manipulating the data to have the output show the median income based on the response districts?

I am using ArcMap 10.2.2 for this analysis. I have a polygon shapefile with median income information and a polygon shapefile of fire stations first in response areas.

  • 1
    Welcome! I suggest you a add some more information about your tools (QGIS/ArcGIS or other) and your data sets (shapefiles or other). The projections of your source data might be an issue as well, so I would suggest you also elaborate on this issue. The last question is really a different question. Elaborate some and you will get more attention to your question. – ragnvald Feb 25 '15 at 22:16
  • How badly do the not line up? Statistics do some funny things in intersections; If the median income is X in a polygon it's still X even when it's cut in half, all you need to work out is how to weight the statistics of the districts based on shape.area when calculating the mean within that area, this may be better done in Excel as a pivot table, you can open the dbf of the shape but DON'T SAVE THE DBF file with Excel - it will break the shapefile. – Michael Stimson Feb 25 '15 at 23:25
  • They are pretty far off with fire station districts sometimes covering multiple pieces of different income level polygons. Example: 75% of Fire Station 1's district may overlay a polygon whose median value is $X, then 12.5% overlays an area where median income is $Y and 12.5% overlays median income is $Z. I want to see if there is some way to weight these or manipulate these where the output shows one total for Fire Station 1's district. Ratio policy comes to mind, but since it is not number of people making said income but rather just the median value, I don't know if that is correct. – Bryan Feb 25 '15 at 23:31
  • You are correct that Ratio Policy isn't what you want to use. You've got a constant value throughout the shape (aka, normalized value meaning it's already taken area into account), so apportionment, or dividing that value up by area, doesn't make sense. As you say, if you had population then you'd want to split that value up by area (lacking any distribution info and so assuming uniform distribution). – Chris W Feb 25 '15 at 23:54

I'm sure this is a duplicate of something but it's easier to just type it out right now. Since you have a constant value for median income, you just need the percent of a fire response area that is each income to arrive at an average median income.

Make sure you have an area attribute in your two files that is separate from the automatically tracked one (if there is such - won't be in a shapefile) that is calculated on the entire shape.

Intersect your fire response area and income polygons. The result should be a set of polygons with the income levels cut up and identified by response area. Create a new field in that table to hold the percentage of total area. And if there isn't one, you need a new area field for the new, cut up shapes. Field calc that new field to divide the total area of the fire response zone (should be an attribute for each row) by the area of that actual piece.

Now create another new field and field calc it to be area percentage times median income. Finally, use Summary Statistics with fire response zone id as a CASE field and your percentage median field as a statistics field with a sum type. Finally, open that table and then add a final field to divide that sum by the frequency field. That should be the median income for the zone. You'll have to join that table back to the fire response zones (or use Join Field) based on ID to get the attribute on the shape.

  • Happy to help. If the numbers don't look right, let me know - in my rush to get it typed out I may have messed up the math. The whole averaging a sum of percentages thing isn't sitting right for some reason. It sounds wrong to me but it tracks right. – Chris W Feb 25 '15 at 23:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.