nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Spatially joining polygons centroid within

DavidMatthews2

I have two polygon feature classes that I want to do a spatial join between and sum certain fields. The target feature has larger polygons (regions) covering the second feature of smaller polygons (property parcels). I would like to use the centroid of the property parcels to do the join as they are not always fully contained in the regions but 'has their centre in' only joins the opposite way, with the target feature being the smaller polygons.

Is there anyway to do this without creating a point feature from my parcels and using 'contains' as my join?

Thanks

Find more posts tagged with

Accepted answers

All comments

RobertStevens

Because the join is made in order to dissolve and/or ignore the joined features in a suitable way (sum, average etc) and ultimately to retain just one copy of the larger geometry. With disparate data sources there is a problem when boundaries of two polygonal sets do not quite match. Neither completely within nor intersect address this issue, whereas having the centroid of the smaller polygons with the larger does. Clear?

JohannLall2

This is an analysis that pretty much every government needs to do at some point. We have zoning, or regions, or sectors, or whatever, and we need to know which parcels fall into which zone but the edges usually don't match exactly

Jan_PeterGlock1

Thank your for your comment Marianne. In fact I made a mistake stating that "A's centroids are always within B (but B's centroids are not always in A)". It is just the other way round: B's centroids are always in A but A's centroids not in B.

My aim is to have the attributes of B and the geometry of A. For "have their centroid in" i get "if A's centroid falls into B." As said, this does not work for me.

I am working with two different representations of city blocks from different sources, where one of them (A has the geometry I need) and B has information on the building density.

MarianneRohrbach

Could you explain why you would want to multiplicate potentially large B features to join attributes of A ? When joining this way you will end up with duplicated B geometries for every A with centroid in B and lost A geometry.
What is the use case for such a requirement?

Jan_PeterGlock1

[Edit: "A's centroids are always within B (but B's centroids are not always in A)" is wrong and should state "B's centroids are always within A (but A's centroids are not always in "]

This is no question:

I have the same problem as David however, the "do it the opposite wy and do an attribute join" solution is not an option for me. This is because my targets (A) are only partially in my joins (B) and the other way round. They just interesct. However they intersect with neighbouring features aswell. The only usefull spatial relation to join them is the centroid. A's centroids are always within B (but B's centroids are not always in A). Since I am far from being a coder I will have to convert the join features into points as David suggests.

In that sense, I would like to suggest that Esri adds the needed match option in an upcoming uptdate. It seems fundamental anyway.

RobertStevens

Amen to what David said. Why is there no "have their center in". Is there a workaround? Sure. But I have a better workaround: have ESRI actually make logical design decisions, and better software.

MarianneRohrbach

You may want to have a look at the Geoprocessing Tool arcpy.TabulateIntersection_analysis, probably followed by Sort and SummaryStatistics to select best match (first row).

XanderBakker

As you already mentioned, having 2M elements in a dictionary will be very slow, since a dictionary takes about 3x the size as overhead.

In addition to what Dan Patterson already mentioned, if there is any attribute that can be identified in both datasets (like a neighborhood or something a little bigger) you could base the "tiles" on those areas.If there is no common attribute then tile the area like Dan mentioned (perhaps with a little overlap just in case) and process those. Doing 200k select by locations on a dataset of 2M features will really take a lot of time and that is not the way to go.

Is it possible to post a part of the data (say 1 region and the corresponding parcels for that region)?

DanPatterson_Retired

given the size... I would consider tiling the data first, this is a classic case where tiling would be easy since it should be fairly obvious which polygon belongs to what... even with overlap if needed. The mere size of the files will bog processing down, so the workflows suggested should account for most situations and you can deal with the remaining separately.

DavidMatthews2

Thanks Dan Patterson‌ Xander Bakkerfor the suggestions. My datasets are large with 2m parcels and 200k regions so the dictionary option will be very slow I think.

It seems strange that there isn't a join option opposite to "HAVE_THEIR_CENTER_IN —The features in the join features will be matched if a target feature's center falls within them"

that is "HAVE_THEIR_CENTER_IN —The features in the join features will be matched if the join features center falls within the target feature."

XanderBakker

You posted this in the Python space. Are you looking for a script to do this? In case the simple way as Dan mentioned, doing a manual spatial join does not work for you, there is always a scripting solution. However, that will take a some time to complete. How much coding experience do you have and what have you tried so far?

I assume that you want to obtain statistical information from multiple parcels for each region and add that data to the regions, right?

How large are your datasets? How many features do you have in both featureclasses?

As a general outline of what could work I would be thinking along the lines of:

Creating a dictionary with the centroids of the parcels and corresponding numerics data on which to apply the statistics oid : [centroid, numeric fields]
Creating a dictionary of the regions (oid : polygon)
Loop through the regions and for each region looop through the parcels and check if the data is inside and populate a dictionary with a list of the parcel numeric data per region
Perform the statistics on the list pf parcels per region
Add the resulting statistics to the regions

If the datasets are large, it would be better to use select by location for each region in order to optimize the performance. This steps above only apply when the regions do not overlap and when a parcel centroid will only fall inside a single region, otherwise a parcel will be taken into account multiple times.

DanPatterson_Retired

switch the order of the join, then do a an attribute join in the opposite direction perhaps

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.