I use ArcMap, where I have two layers:

  • Buildings as polygons. Each polygon has a number of people living in it as an attribute.
  • Polygons dividing the city into "districts". I drew these "districts" myself, so they sometimes cross buildings (which is fine).

I need to calculate the number of people living in each district. I used a spatial join using the buildings as the source and the districts as the target. I set up a merge rule as "Sum" for the number of people.

When I looked at the outcome layer, the total number of people in this layer are higher then in the total number of people in the initial building layer. I think this is because the number of people in buildings that are crossed by "district" boundaries were calculated twice in the summary.

How I can correctly set up the spatial join so that the number of people in the districts are the same as the number of people in the buildings? Ideally, if the majority of a building area fall into polygon, the people should be count as living in this polygon.

  • 1
    Follow up. Have you experimented with different "Match Options". Instead of 'intersect' try 'closest' or 'have_their_centre_in". I think trying to do it by greatest area will be difficult so unless you NEED to I would try work arounds. Could you change the boundaries of your districts to go around buildings (not through - unlikely if this is a full city sized dataset)?
    – DMusketeer
    Commented Sep 21, 2015 at 15:45
  • @DMusketeer Thank you, this is indeed a follow up of the previous question. Unfortunately, I cannot change the boundaries of the districts - there will be always some buildings that are crossed by the boundaries of the districts. I have tried "'have_their_centre_in" and it yielded lower number of people that the try value. I have tried few more match options, but this did not work either... I will try "closest" now... Thanks a lot for your help!
    – Yule
    Commented Sep 21, 2015 at 15:53
  • @DMusketeer and yes, this is a full city-size map...
    – Yule
    Commented Sep 21, 2015 at 15:57
  • @DMusketeer I have tried "closest"but it did not work.
    – Yule
    Commented Sep 21, 2015 at 16:42
  • Use geoprocessing intersect. Assign # of person i each building bit prorata to it's original area. Summarise using district id. Alternatively compute building cenetres into points and apply soatial join
    – FelixIP
    Commented Sep 21, 2015 at 19:07

2 Answers 2


FelixIP's first method is what you need to do if you want to evenly distribute the population of a building that crosses districts.

Start with two feature classes 'Buildings' and 'Districts'

  • Add a field to 'Buildings' and calculate the area.
  • Go to Geoprocessing > Intersect. Select 'Buildings' and 'Regions' as input. Output is 'Proportioned_Buildings'. Join all attributes.
  • Add a field to 'Proportioned_Buildings' and calculate the area. This will be less than for 'Buildings' on those that cross district boundaries.
  • Add a field to 'Proportioned_Buildings' and calculate "population" * ("Proportioned_Buildings Area" / "Buildings Area"). Hopefully you can see that we are multiplying the population of the building by the proportion of that building in that district.

  • Get the centroids 'Proportioned_Buildings' with attributes (none can be on a boundary by definition of the intersect done previously).

  • Select spatial join and set 'Regions' as target and 'Proportioned_Buildings_Centroid' as join. 1:1, Intersect, and remember to set the merge rule to sum on the proportioned population field (not the original population field).

  • The total population in this final layer should match your original total population in the buildings layer (give or take the precision of floating point numbers).
  • Thank you very much for this detailed explanation. This solution did work out! I have now districts with correct numbers of people living in each region. The sum of all people is correct as well! Thanks again, I very much appreciate your help!
    – Yule
    Commented Sep 27, 2015 at 18:13

In such scenarios, when polygon districts intersect polygon layers with attributes, I typically recommend to use the polygon (building) centroid. As another commenter indicated this ensures that each destination feature will fall into exactly one join polygon (district) and your summary totals will balance. Depending on the geographic extent and number of features, each district ought "win" as many split buildings as it "loses", ceteris paribus.

  • Thank you for the answer! I did the methods of centroids as FelixIP and you suggested. However, I suspect that if centroids fall to boarders of district polygons the number of people belongs to that centroids count two times.
    – Yule
    Commented Sep 23, 2015 at 14:51
  • Seems unlikely that many centroids would be exactly on the boundary? Can you isolate them using select by location and 'touch the boundary of the source layer'?
    – DMusketeer
    Commented Sep 25, 2015 at 14:49
  • Does the sum of the 'Proportioned_Buildings' field equal the sum of the sum of the original building populations? If not, you need to see what is going on with intersection step (repair geom, matching coord systems and resolution/tolerance). If the sums do indeed match, you could simply perform Summary Statistics - help.arcgis.com/EN/arcgisdesktop/10.0/help/index.html#//… on the field containing the district name and include 'Proportioned_Buildings' (MAX) as a statistics field. This will yield a table of populations (sum of the Proportioned_Buildings field) by district. Commented Sep 25, 2015 at 16:19
  • @DMusketeer Thanks! There were quite a few centroids on boundaries because the map is huge. Your answer worked!
    – Yule
    Commented Sep 27, 2015 at 18:14
  • @BrentEdwards Thanks! The sum of population was not the same in individual buildings and in districts. Yes, I could have done a geometry repairing. The answer suggested by DMusketeer worked for me.
    – Yule
    Commented Sep 27, 2015 at 18:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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