6

I have some experience using ArcGIS, but mostly with the field calculator in the attribute table/spatial joins, so I apologize if I say something that doesn't make sense.

To provide a bit of background, I have a vector layer containing census tract data. I have another layer with geocoded supermarket locations. I'm trying to determine the number of supermarkets per census tract, which I can then use for various regression models. When I first tackled this issue I simply used raw counts for each census tract. Those counts, however, assume that residents from one census tract have absolutely no access to supermarkets in other census tracts. I've been struggling with a way to account for this in my regression model, so I decided to ditch the regression statistics for now and find a way to account for this issue in my count data.

After doing some searching, I found a method described by Liam Downey (2003) that would seem appropriate for what I'm trying to do. I'm not sure if we're allowed to directly quote academic articles, so I'll paraphrase his method in steps.

  1. Convert census tract maps to raster maps (he used 25x25m grid cells).
  2. Determine the number of facilities within a 1 km radius of the center of each grid cell.
  3. Calculate the distance (m) from the center of each grid cell to the nearest facility.
  4. Sum the values in (2) and (3) for each tract and divide by the number of cells in each tract.

You're then left with two new variables: the average number of facilities in each tract, and the average distance to the nearest facility for each tract.

This method sounds interesting, but beyond converting the census tract vector map to a raster map using polygon to raster (and truth be told, I'm not even sure I did THAT correctly), I'm not really sure how to proceed. What tools should I be using for this?

Improve this question
8
  • 2
    Why not spatial join the tracts to supermarket points then use summary statistics on the joined points to combine the TractIDs with a 'count' statistic and a case field of TractID so that each tract lists the count of supermarket points they contain? If you have an advanced license Generate Near Table may be more helpful as it will count points multiple times within a search distance. If either of these sound like fun I can expand into an answer.
    – Michael Stimson
    Apr 20, 2015 at 23:26
  • 1
    Your first method is precisely what I did to generate my raw count values, but I was wary of sticking with those counts because they assume that 1) people in one census tract have no access to supermarkets in other tracts and 2) the facility exposure is uniform throughout the tract, which I why I liked Downey's method as described above. Thanks for the Generate Near Table suggestion, though I'm not sure that addresses (2). I'm not sure what kind of license my school has, I'll have to check when I go in tomorrow and I'll let you know. Thanks.
    – user3642531
    Apr 20, 2015 at 23:37
  • 1
    Another method, should you not have Advanced licensing, is to buffer the census tracts by the maximum distance you can expect to travel to a supermarket then use a tool like intersect (resources.arcgis.com/en/help/main/10.1/index.html#//…) to update the points with the census tract information, limited to two feature classes in Basic and Standard license which is all you need; in the case of overlapping polygons points are duplicated - one point per intersecting polygon, then continue with summary statistics, join to your original census tracts and calculate field.
    – Michael Stimson
    Apr 20, 2015 at 23:58
  • Network distance is more realistic than 'crow-flies' distance since a network analysis can allow you to account for time and other impedances. Also, you can use spatial allocation...aka a 'buffer' which better reflects factors like distances along a network being different that straight line distances
    – user681
    Apr 21, 2015 at 0:14
  • 1
    There are settings within the Spatial Join tool to address your first comment concerns and negate the need for some of @MichaelMiles-Stimson's other suggestions (which are still valid ways of doing it). Change the join operation to one-to-many and you do the duplication mentioned with intersecting buffers inherently and can just summary stat the join result for counts. Leave it one-to-one and if multiple features are found you automatically get a count stat and can use whatever stat field you want since you won't use it. You can also use the 'within a distance of' match instead of buffer.
    – Chris W
    Apr 21, 2015 at 5:10

2 Answers 2

Reset to default
4

Both variables are zonal means.

  1. The average distance to the nearest facility is the zonal mean of the Euclidean distance grid (based on the facilities).

  2. The average number of facilities is the zonal mean of a one-kilometer radius focal sum of the facilities grid. (This is merely a grid whose cell values count the number of facilities within each cell. Typically it will be an indicator grid whose values are just zeros and ones.)

These both are fast, computationally efficient calculations to perform. Moreover, great flexibility is afforded (if desired) by using a weighted focal sum in (2), which is not any more difficult to compute but can weight facilities according to their distances.

Improve this answer
5
  • I knew something with neighborhood analysis would do it, but I just haven't used those tools except when originally learning about them and looking through the toolbox last night I didn't put 2 & 2 together. I had thought about Euclidean distance, but for some reason mixed up parts of the question and thought we'd be looking for average distance to multiple stores within range and not just closest. Thanks for this.
    – Chris W
    Apr 21, 2015 at 20:40
  • @Chris It took me a few years to really appreciate what can be accomplished with a Euclidean distance grid. It is the basis for most raster-based analogs of all buffering and other "nearest distance" analyses of vector data, such as Thiessen polygons. In principle it contains all the information needed for any nearest-distance analysis. By virtue of the capability to summarize over zones or neighborhoods, the relatively limited distance-based calculations of vector data become much more powerful and flexible in the raster realm.
    – whuber
    Apr 21, 2015 at 20:46
  • This seems to be the method the author used. I'm guessing they created a point density map and used zonal means to calculate the average facility density. This is slightly off-topic but is there a limit to the amount of questions that can be asked per day. I know I'm going to have some questions about cell-size, but I don't want to put them here.
    – user3642531
    Apr 21, 2015 at 20:54
  • Also, which option allows you to calculate the Euclidean distance?
    – user3642531
    Apr 21, 2015 at 20:55
  • (1) I have inserted a link to the Euclidean distance ArcGIS help. (2) There's no limit, but if you ask a lot of closely related questions on the same subject at once (without waiting for answers) people might get annoyed. It's often worthwhile searching the site first, because--especially for basic operations--it's likely you will find good answers have already been posted. Certainly plenty of questions about both the mechanics of specifying cellsizes and the rationale for choosing them have appeared.
    – whuber
    Apr 21, 2015 at 21:05
1

You can follow through with the Downey method and raster. Since step one is done (polygon to raster your census tracts) you move on to step 2.

First up will be Raster to Points to get a set of points that represent each raster cell. Once you have those you can use the same Spatial Join methods you would on the census tracts - after all, you're just trying to get a finer grain measurement than that polygon. Join store points to your raster points using the within a distance match (or whatever other method you want as discussed in comments). You can also kill two birds with one stone here. The spatial join tool will let you add a distance field. This will give you the distance to the closest store match for each raster point. Of course if you want the average of all matches, it will require a different step.

Once you have your count for each point you can Points to Raster them back into a raster which will have raster cell values that are a count of stores within search radius. Note if you do both count and distance, you'll need to run Points to Raster twice and generate two different rasters - one for the count value and one for distance.

For step three, same general principle. You've already got the points for each raster cell so you can use the Generate Near Table tool to get the distance to all stores within a search radius. You could also use Spatial Join with either stat fields or duplication. Either way you'd have to use Summary Statistics with raster point ID as a CASE field to get the average distance to its matching store points. That resulting table would then have to be joined back to the points and converted back to raster.

Step four is handled with the Zonal Statistics tool (or alternate 'as table' tool). You run this using your census tracts as zones (preferably your original raster created from the zones so that the raster exactly matches your points, because if you use the actual polygons it will do that conversion internal to the tool), and it will give you the average value of each cell in that zone. You'll run it on your count and distance rasters and wind up either with a raster showing the zones as one value (make centroids for polygons, Extract Values to Points to get table) or a table you can join back to the census tracts.

Improve this answer
3
  • Thanks for the answer, I'll try this when I get a chance. I was thinking about various methods, and I was wondering if there is a significant difference between the method you just stated and generating a point/kernel density map from the supermarket points, then calculating mean density per tract using the aforementioned zonal statistics tool (thank you for mentioning this tool, I didn't know of it before).
    – user3642531
    Apr 21, 2015 at 14:07
  • 1
    This seems much more computationally expensive and involved than simply computing the two zonal means described in the OP's steps (2) through (4)!
    – whuber
    Apr 21, 2015 at 16:47
  • 2
    @whuber I don't doubt it is, but I couldn't think a way to work with individual raster cells vs points in terms of distances and multiple potential matches. Of course you can convert the store points to raster, but I'm still not sure what that workflow/tools would be. I was hoping someone would post a different answer that stayed in raster or at least didn't involve the point conversion. Or was bottom line a more efficient way to do it. To me those are the most valuable questions on SE - here's how you thought to solve something, and here in the same place are other ways that might be better.
    – Chris W
    Apr 21, 2015 at 18:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.