I have a problem that I can't seem to get my head around. I have two polygon layers:

  • Polygon A - is a subset of polygon B with the same fields and has identical polygons to Polygon B
  • Polygon B - has the attribute data I want to be in Polygon A

How can this be done?

I tried the QGIS tool "Join Attributes by Location" but as some of the polygons are within others, it tends to link to the first intersect it finds (the outer polygon).

  • create centroids (points) of Polygon A and join the attributes to B and export to new file to preserve the attributes from A.
    – Mapperz
    Aug 5, 2011 at 16:35
  • 3
    @Mapperz This is a dangerous approach, because it can produce errors even though it will usually generate a likely looking answer. If the polygons overlap each other, all bets are off. Even when there are no overlaps, it's possible for the centroid of a polygon to lie within a different (non-overlapping) polygon. Correctness can be assured in general only when all polygons in A are non-overlapping and convex.
    – whuber
    Aug 5, 2011 at 20:21
  • +1 @ Diego - your question lead to quite the interesting discussion/debate; an interesting one at that!
    – Dano
    Aug 6, 2011 at 2:24

7 Answers 7


@Dano rightly raises some issues that are best addressed in a full reply.

One difficulty, already noted by @Celenius, is that a join between B and A (in either direction) duplicates all the fields; it can be onerous to correct this. I have suggested in comments that the obvious easy way (export to a spreadsheet) raises questions of data integrity. Another difficulty, already addressed by Celenius' proposal, concerns solving this problem when no combination of attributes can serve as a key for both A and B, because that precludes a database join. The spatial join gets around that problem.

What, then, is a good solution? One approach uses A to identify the corresponding records of B containing the desired data. Depending on assumptions about the configurations of the polygons--whether they overlap, whether some can contain others, etc--this can be carried out in various ways: using one layer to select objects in the other, or via joins. The point here is that all we want to do at this stage is select the subset of B corresponding to A.

Having achieved that selection, export the selection and let it replace A. Done.

This solution assumes that all fields in B are intended to replace their counterparts in A. If not, then it really is necessary to perform a 1-1 join of B (source) to A (destination). The join based on identifiers is best, but making a join on polygon identity (Celenius) works fine if ids are not available and there's no chance corresponding polygon shapes in A and B might differ, however slightly. (This is a subtle point, and the potential cause of insidious errors, because previous edits in B to polygons that don't correspond to A could still invisibly modify the other polygons in B if the GIS is "snapping" or "maintaining topology" or otherwise automatically making global changes during local edits.)

At this juncture, there are two copies of every field: if [Foo] is a common field to A and B, then the join contains A.[Foo] and B.[Foo]. Using a field calculation, copy B.[Foo] into A.[Foo]. Repeat for all needed fields. After this is done, remove the join.

Although this procedure can be a little onerous when many fields are involved, its merits include

  • It is straightforward and fast to script.
  • Scripting it leaves an audit trail documenting the processing being done on the data. This is crucial for protecting data integrity.
  • It defends against some kinds of wholesale errors, such as retaining the wrong field after the join (thereby keeping the old data instead of the new data for that field) or deleting a crucial field.
  • It capitalizes on built-in defenses offered by the database management system, such as data type enforcement and business rule enforcement, that operate to prevent and identify errors and to maintain consistency among all the tables and layers in the database.

Some of the guiding principles involved in this suggestion are

  1. Use your a database management system to process data rather than using software not designed or unsuitable for this task.
  2. Avoid changing database structures (such as deleting or adding fields) when operations don't absolutely require it.
  3. Use the software's capabilities for automation to simplify the work, document it, and make the operations reproducible.

One might object that in many cases there are faster and easier ways to reach the same result. Yes, there can be, and they can be effective and usually they work when performed with care. But solutions that risk the data are difficult to recommend and defend as general-purpose answers. They are best employed in one-off situations with small datasets where corruption in the data should rapidly become obvious and the consequences of any such mistakes are immaterial.

  • +1 @ whuber - It's obvious that you've attempted to weigh all the variables here; a well thought out answer. Please see the addition to my original answer, as I will run out of space in th is comment box.
    – Dano
    Aug 6, 2011 at 3:26
  • 1
    for people wondering what happened to the "Celenius" mentioned various places in this thread: now know as @djq, and his/her answer is here. Kudos to wayback machine: web.archive.org/web/20120127210858/http://gis.stackexchange.com/… Mar 2, 2015 at 22:38

In Arcmap you could spatially join Polygon B to Polygon A; this would relate the attributes. As the field names are the same it will create some new combination of the name.

  • This is what I would put. In my eyes, this short answer is the right one.
    – jakc
    Aug 6, 2011 at 1:05

Export the table for Shapefile "B" to Excel and delete the columns that are redundent, and any columns containing information you don't need. Make sure you keep your shared identifier column, then save it to the appropriate folder. Go in to ArcMap, add the table, then Right mouse on Shapefile "A" and conduct a table join. The link should lead to a video on how to do this.

@ whuber - The entire approach is sound, and ensures the integrity of the data. The only thing I can say to refute this answer, is that certain situations / projects do not afford us the time or the budget to be this methodical in our approach.

A true-to-life example:

A Junior Mining Company is sitting on a major orebody with hundreds-of-millions of dollars in cash infusions resting on their ability to "prove-up" the resource. A desktop review of publications & geology maps/data leads to a very targeted, and very costly drill program. When the assays come back from the first run, these values are tagged to their respective point locations via a table join, and pumped back out in an Excel format where the data are painstakingly prepped for import into DataMine (for 3D orebody interpolation).

In my experience, the project Geologists required that this data be prepped in Excel, that it followed EVERY formatting rule/convention to the letter (no spaces, no special characters, etc) and that the DataMine import file was delivered in a .csv format (back then anyway). This would lead to more investment in targeted drilling, and we would revisit the process (in some cases) many times over. All of this generally occurred on an exceptionally tight and critical timeline.

Each of us has our own story, and our own array of experiences that we've incorporated into our approach to how we do things. Having said that, my experience has seen Excel as a an absolute necessity, and a vital tool in my workflows; it's what I know. We took every QA/QC precaution in the preparation of this data. Where you guys would shy away from Excel, I had no choice but to use it.

  • (-1) Using Excel to do a join is not only more difficult than accomplishing it with a GIS or RDBMS but also invites serious errors.
    – whuber
    Aug 5, 2011 at 19:21
  • 8
    Excel is simple, it works, and because of that it is probably responsible for more undetected, wholesale errors than any software ever produced. It violates basic principles of DBMSes that were developed to protect against errors that Excel makes all too easy to commit, such as (1) sorting some columns but not others; (2) typographical errors that change data types; (3) stray keystrokes that obliterate data; (4) inadvertent deletion of rows or columns; (5) hidden conversion of data, such as text to dates; (6) hidden truncation of data; (7) hidden rounding of numeric values; and many more.
    – whuber
    Aug 5, 2011 at 20:27
  • 2
    this answer and resultant commentary is a wonderful illustration of how a "bad" answer can invoke good results, revealing info that might not otherwise come to light. Please don't feel like you should delete it to avoid "taking a hit". Aug 5, 2011 at 22:01
  • 3
    ...and to make up for the hit, a GREAT QUESTION would be to ask why using Excel to process data can lead to very serious problems. And how to use it safely. Aug 5, 2011 at 22:05
  • 1
    (+1) For the thoughtful and well described edit. @matt Check out the discussions on stats.stackexchange.com concerning What would be a good way to work with a large data set in Excel? and Excel as a statistics workbench.
    – whuber
    Aug 6, 2011 at 16:01

In the late 1990's we received a large-scale update to all of our waterbodies and watercourses, covering some 55 NTS map sheets and an unremembered thousands number of features. We needed to keep the value added attributes of our old hydrology (lake names, surface elevation, etc.) and replace the geometry. The geometry of old and new were close enough that we could guarantee the centroids of each polygon would still be bounded by the new polygon boundaries -- this is an important point, without this basic certainty the approach below is not a good idea.

The solution in this particular case was instead of bringing the attributes to the geometry, bring the geometry to the attributes. So, conceptually:

  1. from *Layer_with_attributes*, delete polygons but keep table records,
  2. from *Layer_with_polys* copy and paste geometry into *Layer_with_attributes*
  3. merge and save.

See here for a more extended description and recipe for . I'm not sure it's even possible in modern Arcgis or Qgis to delete a geometry without simultaneously deleting it's attribute record, but hey, just in case it is, here's the idea.


I'm not sure but perhaps some DBMS's perform equality operations on Shape fields in SQL(?). It seems to me that if two geometries are identical the SQL = operator should return true (WHERE A.Shape = B.Shape).

If this is true for the database you are using, you should be able to do a spatial join using the same syntax you would for a non-spatial join.

Looks the ST_Equals method (an OGC standard) could be used for this.


As usual whuber is right. You need to think thoroughly about your process. Especially if these are large datasets and this operation will be undertaken many times or the data is mission critical.

Consider your data and responsibilities:

What have you done?

What are you doing?

What do you intend to do?

And always ask: Why?

Now for one easy answer aimed directly at the question asked. Keeping in mind there is always at least 5 ways to do things but usually only one best way.

Assuming the fullset has every attribute you want to be in the subset and the subset has nothing not already in the fullset except outdated information.

Guessing that the subset topology matches the fullset (including Origin/Projection and XY Tolerance).

1) Use Feature to Point with the "Inside" checkbox checked and create a points feature class or shapefile from the subset.

2) Use a Select by Spatial Join to find all polygons in the fullset that correspond to the subset based on the newly created Point feature class or shapefile.

3) Export the Selection from the fullset, and that can be your new subset.


Surely, if Polygon A is a subset of Polygon B, the easiest approach would be to loop through Polygon A, use the ID that would be in Polygon A (and B if A were a subset or B) to search for the row data in Polygon B and then update the row in Polygon A.

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.