In the image below you can see two shapefiles: NYC building footprints (outlined), and underneath a PLUTO shapefile rendered with a categorized blue gradient using the "Floor Number" column. The Building Footprint dataset does not have floor number info and the PLUTO dataset doesn't have buildings, just lots.

How can I use QGIS to get the number of floors data from the PLUTO shapefile into the Building Footprints table without having to do it manually, building by building?


  • 1
    The first thing I see is that one building is in two polygons, what do you want to happen there? Normally I would make centroids of the buildings, intersect with PLUTO and then join back to the polygons - but that doesn't work if the building falls on multiple polygons. The reason for centroids is it accounts for not-quite matching between the data by using only the very centre of the polygon. How does that sound? Commented Dec 3, 2014 at 22:49
  • 1
    @MichaelMiles-Stimson I think you should just go ahead and post the centroid method as an answer and just note the implications of what may happen when a building poly falls on two lots. It's certainly the cleanest/quickest method, because otherwise you have to edit building polys - and ones like the center example might be easy enough to judge, but a single-process solution like intersect is going to get you slivers galore (lower right, for example).
    – Chris W
    Commented Dec 5, 2014 at 1:00

2 Answers 2


In QGIS there is a toolbox, you will need to open this. Go to Processing menu and select toolbox.

It is really good to have a unique attribute on the polygons to allow attribute joining at the last step, to do this if you don't already have one, add a field and field calculate to $rownum: Calc Unique Field

To convert polyogns to centroids use the polygon centroids tool:

Polygon CentroidsCentroids

This will put a point roughly in the centre of each polygon with all of the attributes from the polygon (if you have a unique identifier this would be great). Then intersect the centroids with the PLUTO layer:


Which will add the attributes of the polygon in the PLUTO layer that the point (centroid) falls in.

To get the attributes from the intersected centroids back to the building polygons either Attribute Join if you have a unique identifier for the buildings or Spatial Join if there is no unique identifier. In an attribute join open the attribute table and field calculate, the joined records will have the layer name and an underscore before the fields.

As was mentioned earlier the centroid will only match with one polygon in your PLUTO layer; if the building is across two PLUTO polygons it will only have the value of one of these polygons.

Warning centroids are not guaranteed to be within polygons. In certain rare instances the centroid may fall outside (Thanks for reminding me about that ChrisW): Centroids outside

There is a suggested workaround involving creating random points but this would introduce new problems. I suggest intersecting the centroids with the buildings and anywhere where the unique IDs don't match fix manually by moving the centroid to the visual centre of the building but well inside. Normally the number of points on man-made features that would need to be edited is around 1%; people tend to build boxes, only rare instances have voids or are unusually shaped enough for the centroid to fall outside. Natural features on the other hand you can expect to edit between 10 and 50 percent as the shapes tend to be more organic.

  • Note that, from what I can see in the screenshots, there is no option to constrain the centroids to be within the polygon (I guess they wouldn't really be centroids then, but I don't know if there's a feature to point tool that would have the option like in Arc). This means that with some odd-shaped buildings it's possible the centroid will not only fall outside the building, but maybe even on a different lot with a different height. Something to be aware of in addition to a building polygon already falling on more than one lot.
    – Chris W
    Commented Dec 6, 2014 at 1:49
  • Yes, I noticed that too @ChrisW. There is a definite problem there. A workaround is suggested lists.osgeo.org/pipermail/qgis-user/2011-October/013784.html by creating random points but that would cause other problems. There would have to be a manual fix of the centroids that don't match the polygons. Commented Dec 7, 2014 at 22:34

As the comment notes to transfer data between datasets cleanly you need a one to one relationship which you'll have to evaluate the best geoprocessing method (ie clip/join/etc) once you have that figured out the best method will likely be converting whichever dataset you want to sample from using zonal statistics to extract the value from the raster into the target vector dataset

  • Needing a one-to-one relationship is probably a bit broad of a statement. And I don't see any mention of raster data?
    – Chris W
    Commented Dec 4, 2014 at 0:55
  • Good point... What I mean to say is you need to parse down the data so that one polygon equals one lot as some builds might have different heights on different lots you'll want to take the buildings data and clip it with lots... That way you have the one polygon = one height but still hopefully have the unique id for the building so to analysis later... For example after this you may have 3 polygons from what was one buildings but all three still have the building id... At this point you can either create a centroid from the Pluto data and use a point sampling point to transfer the value
    – user33290
    Commented Dec 4, 2014 at 2:05
  • Or convert the Pluto data into a raster with the grid set to close the resolution of the polygon ~10m, using zonal statistics to average the pixel value (height) for each area for each polygon... On 2nd thought point sampling sounds the better path.. Should I edit my original answer?
    – user33290
    Commented Dec 4, 2014 at 2:08
  • I would suggest editing, yes. Clip is probably not the right tool, and I suspect a more direct version of your solution (avoiding use of rasters) would be Intersect (or possibly Union). I do understand the idea of raster and zonal stats to deal with small overlaps like the lower right corner. Larger overlaps like the center might warrant splitting the building poly and having a different height or each part, an alternative to a straight centroid approach but asker hasn't clarified what is acceptable. It looks like some of the footprint data would need 'cleaning'.
    – Chris W
    Commented Dec 5, 2014 at 0:55

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.