I've found a couple of other Stack Exchange questions related to this, but they were not satisfying.

For example:

How does ArcGIS Desktop calculate INSIDE point for Feature to Point?

does not tell me how the "Inside" point is determined. While the ArcObjects may refer to centroids and label points, I have at least 4 outcomes in my situation that vary differently, wildly in some cases.

I have unidentifiable points inside zip codes, so I'm assigning each one to the centroid of that zip code. Then I will calculate straight line distances from these centroids to various locations of interest. Therefore, my choice of centroid is important. Some zip codes are also of odd shapes and may possibly be discontinuous. At least that is what I assume is generating some of the odd behaviors.

Now, I have found four different ways to identify possible centrality of these polygons.

  1. The polygon geometry contains a centroid information that can be directly extracted (and supposedly is used for labeling?).
  2. The labeling location of the polygon (which I found does not always match where the above point is located--hence, the confusion).
  3. Feature to point method with 'centroid' option.
  4. Feature to point method with 'inside' option.

Some of these or most of these may overlap. In some zip codes, they are all completely different. I would have expected 1. and 3. to be similar and maybe even 1. and 2. to be identical, depending on how labeling is set up (I'm using default).

My question is not to ask "so how are these calculated?" That's neither here nor there since their algorithms are proprietary, and there's no point in trying to figure it out.

The real question is practical i.e. how should one go about determining the appropriate centroid to use?

My conclusion is the feature to point method with the 'inside' option will be the most appropriate because it is guaranteed to reside within the polygon boundary. I also assume it will be relatively central. But the descriptions about this are nebulous e.g. consider a crescent shaped polygon. The centroid would be outside the crescent but in the middle of the encapsulating envelope. Would an "inside" option literally just "push" it over into the crescent? We may not know the algorithm, but does the "inside" option actually identify centrality? Is it better than 1.? Maybe I'm missing something in my approach to this problem? Can the projection impact these comparisons? Is there a post-processing review of the polygons I should consider?

  • 2
    It's a great question, but much of its interest stems from your assertion that the choice of a central point in each ZIP polygon will be important for your subsequent analyses. If this is so, you ought to consider not replacing the polygons with points! What you should do instead depends on the meaning of the distances you will be calculating, what will be done with those distances, and your computing limitations relative to the dataset size. Please, then, give us some guidance by explaining these things.
    – whuber
    Commented Jun 24, 2012 at 14:46
  • Well the problem is we don't have individual locations, only their zip codes. Thus, it makes sense to represent their location by the zip code. However, to give a gross estimate of their distance to another location (hospitals, in this case), a point-to-point seems most appropriate since we're already generalizing them to the zip code. If we had networks, that would be better, but we're just going to do distance as the crow flies. Does that make sense? I don't see a better way. I think polygon centrality (center of mass?) would be best (than, say, center of geometry?) Commented Jun 24, 2012 at 22:12
  • 2
    Ignoring the zip codes that do not represent definite areas or locations, we can think of them as representing polygonal regions. Given you know a location lies within such a polygon, if you want to estimate its distance to a hospital (say), you might average over all distances between the polygon and that location. Unfortunately, no single point can stand in for such an average, because it depends on the hospital's location. If you instead take the square root of the average squared distance, though, a nice solution is available: use the centroid (even if it's outside the polygon!)
    – whuber
    Commented Jun 25, 2012 at 12:54
  • 1
    The centroid is special, Bryan, in that we do not have to go to all that computational effort: it is unique among all points related to a polygon in that the mean squared distance between the polygon and any other point equals a constant (depending only on the polygon's shape) plus the squared distance between the centroid and that other point. That constant is given by the total inertial (second) moment of the polygon, which is computed as easily as the centroid itself. I'm not saying this is the right method for your application, but it sure is simple! What will you do with these distances?
    – whuber
    Commented Jun 25, 2012 at 18:48
  • 1
    I did a similar analysis a year ago, also with a multinomial logistic model of consumer choice. A zip code covers a large enough area to make a real difference in hospital choice, so you're going to lose some potentially important information by aggregating over a zip code. (I used travel times by various forms of transportation based on geocoded addresses.) It may also be important to use distances to many competing hospitals, not just distance to the nearest one. See Lee & Cohen, "A Multinomial Logit Model for the Spatial Distribution of Hospital Utilization" (JBES 1985).
    – whuber
    Commented Jun 25, 2012 at 19:22

1 Answer 1


For a general clarification I would say that a centroid may lie outside the polygon, but with the within option it is selecting a point within the polygon but may not be a true centroid, so in both instances the point would be in different locations.

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.