I have a problem that I can't seem to get my head around. I have two polygon layers:
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).
@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
Some of the guiding principles involved in this suggestion are
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.
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.
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.
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:
See here for a more extended description and recipe for arcinfo-worksation. 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.
