GlobalAdams

ArcPy data analysis SHAPE@XY token centroid different than SHAPE@ centroid value

Discussion created by GlobalAdams on Apr 23, 2014
Latest reply on Mar 3, 2017 by curtvprice
Working with a dataset of municipal parcels (polygons) I've noticed a difference between the XY centroid value accessed through the SHAPE@XY token VS SHAPE@. While I can't post an example, I found this issue by comparing where points were placed when geocoding using an address locator that was created from the parcel polygons. For odd shaped parcels, such as long and narrow landscape areas that wrap around a housing development, the point generated from the SHAPE@XY value is placed at the true centroid of the polygon, "The center of gravity for a feature." The SHAPE@ token, when dissected like "poly_geom.centroid.X" and "poly_geom.centroid.Y" will provide the XY coordinates for the centroid or label point as described on the ArcPy Polygon page: "The true centroid if it is within or on the feature; otherwise, the label point is returned..."

So the point of this post is that using the SHAPE@XY token is misleading. It is the same as getting the SHAPE@TRUECENTROID value for X&Y. This is also true of the SHAPE@X or SHAPE@Y. This will cause issues for people who want to geocode address locations and then do any kind of spatial analysis where counting points in parcels is important. There will be odd shaped parcels that should have a point inside but don't, and points in other parcels that shouldn't be there but are placed due to the center of gravity of the odd parcel. I use the SHAPE@ token to avoid this issue, but that means more memory is consumed to hold the entire polygon geom object instead of the just the centroid, which makes for a slower script.

Have other people noticed this? I don't feel like this is a bug, but it would be nice to have a consistent meaning for centroid when working with both the SHAPE@XY token and the centroid properties of a polygon geom object.

Outcomes