0

I have two spatial layers of about the same (not exactly same) spatial extent. Layer#1 has about twice the number of polygons than layer#2 (in thousands).

I am trying to calculate values for Field#X and Field#Y present in layer#2 for layer#1 based on spatial location (using right click -> joins and relate, etc.).

What would be the best way to do it?

I am trying to do it using "join data from one layer based on spatial location" and then averaging. But once I sum up the total for Field#X and Field#Y for the resulting layer, it is a much different than the total for the same in the original layer (i.e. layer#2). It should be comparable as the spatial extents are about the same.

Any suggestions on how to address this?

1

That depends on the values you are attempting to calculate, and the relationship between the two layers boundaries (how coincident they are). Since it sounds like they're numeric values, a spatial join is probably not the way to go. Also note that the right-click join method doesn't give you full control over a spatial join as the GP tool does.

I'm not entirely clear on what you're trying to do from your description, but there are two concepts you need to know about - aggregation and apportioning. Aggregating means combining to larger, while apportioning means dividing between. We have tags for those, so if you search you'll get more info. In some cases you must first apportion before aggregating.

Say for example you have polygons A, B, C, D that all partially fall in polygons 1 and 2. You want to know the total of ABCD for each 1 and 2. First you would have to apportion ABCD to 1 and 2, then aggregate those results to get a total. If you're looking at a geometry property like area, a straight up overlay will do this. If you have a numeric attribute value, the apportioning is usually done by area (meaning percent area A1 of total area A times attribute value is assigned to A1).

A spatial join doesn't do this. It is considered an overlay operation, but it doesn't divide up the inputs at all. You either get one match (first record found) or multiple matches. There are any number of reasons why the join method would produce different totals than the inputs. There are three other overlay operations that could do what you want:

  • Intersect only returns areas of overlap (A and B)
  • Union returns all areas from both layers (A or B)
  • Identity will return all areas from one layer but cut up according to the other, but requires an Advanced license. (A, A and B, but not B)

The main choice is whether you care about the areas that don't overlap. And in ArcGIS, if you do need to apportion values, you will need to create feature layers, specify a ratio policy when creating said layers, and then run your overlay tool on those feature layers (see Apportion Neighborhood Information to Census Tracts for details).

  • Hi Chris, Thanks a lot!! You explanation has been quite helpful. I did spend time reading through several of the threads on aggregation and apportioning. It seems like I need to do Union (apportioning). And my problem is similar to several others discussed with the difference that I am trying to apportion for different fields. First problem was that due to the large size of the shapefiles, any geoprocessing i.e. union, clip etc are failing. Hope I am making sense here, but might come back to edit this as I keep trying to figure this out. – Sam Jun 3 '15 at 13:35
  • @Sam shapefiles have an inherent size limit (2GB max for any component file, usually only the .dbf or .shp will come close to hitting that). They can also become corrupted, so running Check/Repair Geometry may help. Or importing to a geodatabase. As far as geoprocessing, most (not all) tools use tiling to be able to process large datasets; size in theory shouldn't be an issue. You can apportion multiple fields at the same time, just set them all to have a ratio policy when you make your two feature layers. The steps I outlined at the linked question should be easily adapted to solve your case. – Chris W Jun 3 '15 at 17:04
  • thanks again. I will follow the steps to see if I get success in completing the GP steps. I imported them to a geodatabase and then tried to use ArcGIS interface, Python built in script window and python stand alone. But the processing failed in all the cases. I will run Check/Repair Geometry and run it again and see what happens. Thanks.. – Sam Jun 3 '15 at 17:47
  • So, I followed the check geometry, correct geometry and then ran the process in the foreground and I was able to run the union GP. But before this, I clipped the larger layer to the smaller layer extent so that both the layers have same spatial extent. I retained just one column as polygon ID for layer#1 (see above, original post) for simplicity. After I ran the union, I summed up the values for the targeted layers from layer#2 but the numbers came out to be different. So, what am I missing here? – Sam Jun 3 '15 at 21:07
  • You said that " If you have a numeric attribute value, the apportioning is usually done by area (meaning percent area A1 of total area A times attribute value is assigned to A1)". I am not sure how to do this, is that why I am having this difference? – Sam Jun 3 '15 at 21:07

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.