Skip to main content
Log in

Ambient populations and the calculation of crime rates and risk

  • Original Article
  • Published:
Security Journal Aims and scope Submit manuscript

Abstract

In the past, crime rate calculations have favored one denominator for spatially referenced crime rates, the residential population. Dominantly, this practice is the result of cost and time constraints on research. This paper uses freely available spatially referenced population data, the LandScan Global Population Database, which provides an alternative measure of the population at risk in crime rate calculations, the ambient population. Calculated crime rates using the residential and ambient populations exhibit a weak statistical relationship. This provides a strong positive implication for the use of these data such that their utilization may give a more precise depiction of victimization, particularly when considering violent crime. Consequently, it is argued that ambient-based (violent) crime rates should be used to supplement the conventional residential-based (violent) crime rates.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6

Similar content being viewed by others

Notes

  1. For an example of the use of mobile phones in ambient population research, see SENSEable City: http://senseable.mit.edu/.

  2. Although a census tract analysis is not presented here, the results are qualitatively similar. Therefore, the results presented are not qualitatively sensitive to changes in spatial scale.

  3. Geocoding the point locations of these crimes provide the potential for error. Aside from the accuracy of geocoding algorithms (see Ratcliffe, 2001), geocoding procedures run the risk of not finding addresses or point locations. Although the imported data file must be in a format recognized by the GIS software and street addresses must be standardized, particular addresses or point locations may not be mapped. After consultation with the proprietors of the data, it was determined that on occasion an address is improperly recorded in the field and, therefore, cannot be found by the geocoding procedure – either a non-existent street address is provided or only the street block number. With such a high success rate of perfect matches and the nature of the improper address records appears to be random, the analysis is performed without concern for bias (Ratcliffe, 2004).

  4. The results presented here strongly indicate that the residential population is not the appropriate population at risk given its difference with the ambient population estimates, using an example of violent crime – an exception would be if crime data were recorded temporally so risk could be assessed at different times of the day, such as when the population is, largely, expected to be at their residence.

  5. This is especially true if the reporting of rates does not reflect the current perception of the public. The perception of the public most often developed during the conscious hours of the day and not the unconscious.

References

  • Andresen, M.A., Jenion, G.W. and Jenion, M.L. (2003) Conventional Calculations of Homicide Rates Lead to an Inaccurate Reflection of Canadian Trends. Canadian Journal of Criminology and Criminal Justice. Vol. 45, No. 1, pp 1–17.

    Article  Google Scholar 

  • Birkin, M., Clarke, G. and Clarke, M.P. (2002) Retail Geography and Intelligent Network Planning. Chichester: John Wiley & Sons Inc.

    Google Scholar 

  • Boggs, S.L. (1965) Urban Crime Patterns. American Sociological Review. Vol. 30, No. 6, pp 899–908.

    Article  Google Scholar 

  • Brantingham, P.J. and Easton, S.T. (1998) The Costs of Crime: Who Pays and How Much? 1998 Update. Vancouver, BC: The Fraser Institute.

    Google Scholar 

  • Cohen, L.E., Kaufman, R.L. and Gottfredson, M.R. (1985) Risk-Based Crime Statistics: A Forecasting Comparison for Comparison for Burglary and Auto Theft. Journal of Criminal Justice. Vol. 13, No. 5, pp 445–457.

    Article  Google Scholar 

  • Dobson, J.E. (2003) Estimating Populations at Risk. In Cutter, S.L., Richardson, D.B. and Wilbanks, T.J. (eds) The Geographical Dimensions of Terrorism. New York and London: Routledge, pp 161–167.

    Google Scholar 

  • Dobson, J.E. (2004) The GIS Revolution in Science and Society. In Brunn, S.D., Cutter, S.L. and Harrington, Jr., J.W. (eds) Geography and Technology. Dordrecht: Kluwer Academic Publishers, pp 573–587.

    Chapter  Google Scholar 

  • Dobson, J.E., Bright, E.A., Coleman, P.R. and Bhaduri, B.L. (2003) LandScan: A Global Population Database for Estimating Populations at Risk. In Mesev, V. (ed.) Remotely Sensed Cities. London and New York: Taylor and Francis, pp 267–279.

    Google Scholar 

  • Dobson, J.E., Bright, E.A., Coleman, P.R., Durfee, R.C. and Worley, B.A. (2000) LandScan: A Global Population Database for Estimating Populations at Risk. Photogrammetric Engineering and Remote Sensing. Vol. 66, No. 7, pp 849–857.

    Google Scholar 

  • Gold, S.S. (2003) Watch us Move: Homeland Security Requires a New Kind of Population Map. Popular Science, January, p. 40.

  • Harries, K.D. (1991) Alternative Denominators in Conventional Crime Rates. In Brantingham, P.J. and Brantingham, P.L. (eds) Environmental Criminology. Prospect Heights, IL: Waveland Press, pp 147–165.

    Google Scholar 

  • Johnson, H. and Lazarus, G. (1989) The Impact of Age on Victimization Rates. Canadian Journal of Criminology. Vol. 31, No. 3, pp 309–317.

    Google Scholar 

  • Monmonier, M.S. (1996) How to Lie With Maps. Chicago, IL: University of Chicago Press.

    Book  Google Scholar 

  • Oak Ridge National Laboratory (2003) LandScan Global Population Database. Oak Ridge, TN: Oak Ridge National Laboratory. Available at http://www.ornl.gov/gist/.

  • Pittman, D.J. and Handy, W.F. (1962) Uniform Crime Reporting: Suggested Improvements. Sociology and Social Research. Vol. 46, No. 2, pp 135–143.

    Google Scholar 

  • Ratcliffe, J.H. (2001) On the Accuracy of TIGER Type Geocoded Address Data in Relation to Cadastral and Census Areal Units. International Journal of Geographical Information Science. Vol. 15, No. 5, pp 473–485.

    Article  Google Scholar 

  • Ratcliffe, J.H. (2004) Geocoding Crime and a First Estimate of a Minimum Acceptable Hit Rate. International Journal of Geographical Information Science. Vol. 18, No. 1, pp 61–72.

    Article  Google Scholar 

  • Reiss Jr, A.J. (1986) Official and Survey Crime Statistics. In Fattah, E.A. (ed.) From Crime Policy to Victim Policy: Reorientating the Justice System. London: Macmillan.

    Google Scholar 

  • Sacco, V.F. (2000) News that Counts: Newspaper Images of Crime and Victimization Statistics. Criminologie. Vol. 33, No. 1, pp 203–223.

    Article  Google Scholar 

  • Sacco, V.F. and Kennedy, L.W. (2002) The Criminal Event: An Introduction to Criminology in Canada, 3rd edn. Toronto, ON: Thompson and Nelson.

    Google Scholar 

  • Schmid, C.F. (1960a) Urban Crime Areas: Part I. American Sociological Review. Vol. 25, No. 4, pp 527–542.

    Article  Google Scholar 

  • Schmid, C.F. (1960b) Urban Crime Areas: Part II. American Sociological Review. Vol. 25, No. 5, pp 655–678.

    Article  Google Scholar 

  • Silverman, R.A., Teevan, J.J. and Sacco, V.F. (1996) Measurement of Crime and Delinquency. In Silverman, R.A., Teevan, J.J. and Sacco, V.F. (eds) Crime in Canadian Society. Toronto, ON: Harcourt Brace.

    Google Scholar 

Download references

Acknowledgements

We extend our gratitude to Patricia L. Brantingham and Paul J. Brantingham for discussions on crime rates, risk, and the ambient population. We also thank two anonymous reviewers for insightful comments. The usual disclaimer applies.

Author information

Authors and Affiliations

Authors

Appendix

Appendix

The GIS work in the paper was performed using Environmental Systems Research Institute (ESRI) software, so the procedure for obtaining the data used is described for that software package. Other GIS software should have similar functions that would allow this procedure to be used in another software environment.

The first step to implement the ambient population data is gaining access through the Oak Ridge National Laboratory (ORNL) web page: <http://www.ornl.gov/sci/gist/>. These data are available free of charge for non-commercial purposes, once a declaration of the research/data use is made. After your data use has been cleared by ORNL, essentially the non-commercial use only needs to be established, you will be given a username and password to access the data. At this time, the data available is at the 30 second by 30 second (30″×30″) resolution, approximately one square kilometer. ORNL is currently working on a 3″×3″ resolution for the United States.

Given that most census data is in vector format, shapefiles or coverages for those familiar with ESRI software products, and the ambient population data is in raster format, a conversion is necessary for the data to be compatible. The ambient population data comes in geographic areas the size of continents; therefore, the specific region of interest (or an area slightly larger to avoid missing data) should be “clipped” from the original file to ease computation. This is a simple function using Arc/INFO or ArcToolbox in the ArcGIS software package. You need to obtain the coordinates for the upper, lower, left, and right extents of the desired clipped region. The default in the “Clip” function is the complete extent of the raster image. You only need two points to get all four of the extents: top-right and bottom-left or top-left and bottom-right. The next step is to convert the raster image into a GRID file, so the ambient population data can be transformed into a format that can be manipulated along with the census boundary shapefile. This function is contained within ArcToolbox in ArcGIS or using the “SDTS Raster to Grid” function in ArcView 3.x. If ArcGIS software is not available, the clip function is not a necessary step before the raster image is converted into a GRID. It merely reduces the computation time for the previous and subsequent steps outlined below.

The following two steps, also straightforward, are to convert the grid file (and the census boundary file if it is not done already) into a shapefile, then to re-project the ambient population shapefile to match the projection of the census boundary coverage. This is done through ArcToolbox or the ArcView Projection Utility Wizard. This stage of re-projection is critical. The Project function recalculates the new projection based on the old projection. Therefore, you must be sure you know the old projection of the data. In the case of the ambient population data, it is a geographic coordinate system: GCS_WGS_1984. The census boundaries used also use a geographic coordinate system: GCS_NORTH_AMERICAN_1983. Because all projections are mathematical functions to display a curved object on a flat surface, there exists another mathematical function to convert one projection to another. If you zoom into a small area on the map once both data sets are projected the same – you usually won’t be able to see both of them if they are not projected the same way – you may notice that the outer boundaries of the two data sets do not match up perfectly. Although this is sometimes cause for alarm, not in this particular case. The census data are in vector format, meaning that lines are used to draw the shapes of the dissemination areas. However, the ambient population data are in raster/grid format, meaning that the image you see is made up of many small squares of data called pixels. Therefore, all shapes are made up of pixels rather than lines so when you zoom into a feature you see a “squared edge”. Keeping in mind the discussion above regarding boundaries, be sure to view both files simultaneously in GIS software to ensure everything has been done correctly.

The shapefile for the ambient population has a data set associated with it that contains the ambient population count for each polygon. During the conversion process, any contiguous pixels in the raster/grid file that contain the same value are joined together in the shapefile – this will not necessarily happen to all data sets, so the following may be ignored if not applicable. This brings about potential for error because the values for each of the pixels are not summed in the conversion. The new aggregated pixels have the value that each of the individual pixels had previously. Therefore, this variable, named GRIDCODE in our conversion process, must be changed for those aggregated pixels. Simply identify the aggregated pixels, determine the number of pixels that were aggregated, and multiply the value of GRIDCODE by that number. This is a simple operation because all of the pixels have extremely similar areas. Given any changes in latitude, they will not be identical but you can identify the aggregated cells easily. For example, say the area of each cell is approximately 1. If the area of a polygon in your shapefile has an area of 10.2, then 10 pixels were aggregated together. The easiest way to correct for this issue is to create another variable that is equal to the new polygon area divided by the baseline polygon area and multiply this variable by the ambient population. For those polygons that have not been aggregated with any other polygons, the value of this new variable will be unity and the multiplication will preserve the proper value. Only those polygons that were aggregated will be affected, having their values returned to their actual value.

The next step is to calculate the area of each polygon in the ambient population shapefile. The difficult way to do this is using script such as Avenue (ArcView 3.x) or VBA (ArcGIS), and the simple way is to download and install an extension called XTools: <http://www.odf.state.or.us/DIVISIONS/management/state_forests/XTools.asp>. Given that the map units are in decimal degrees, area calculations using script are in decimal degree squared, unless the appropriate transformations are made. Data may be re-projected into a format that supports meters or feet as the map units, but if one does not wish to modify the original data for one calculation, XTools is the easiest solution. A further difficulty with this area calculation is the small area values calculated because of the units used. As a consequence, many area values may be reported as zero or close to zero, losing precision in the calculation. XTools makes the necessary conversion from decimal degrees into meters-squared and/or hectares. Once installed, XTools appears in the drop-down menu and the area calculation function can be selected.

Using the modified GRIDCODE variable and an area variable (we used hectares), create an ambient population per unit area variable, AMBPOP_DEN – divide GRIDCODE by area. This new variable is needed below because the areas of the polygons change in the next step and the ambient population density per unit area variable is needed to recover the ambient population count.

The new shapefiles now need to be overlayed. This procedure places one shapefile on top of the other and creates an entirely new data set with a new set of polygons – see Figure 7. The specific overlay function to use is called identity. This function uses the input shapefile as the base and merges the portion of the identity shapefile that is common with the input shapefile together. The output shapefile has a larger number of polygons than the census boundary file or the ambient population because, as shown in Figure 7, the boundaries of the polygons are placed on top of each other to create new polygons boundaries. In this case, the input shapefile is the census boundary file and the identity shapefile is the ambient population. The output shapefile also contains all of the information from both data sets: the census boundary unit each polygon belongs to, the new areas of the polygons, the ambient population per unit area, and any other data that was present.

Figure 7
figure 7

Identity overlay.

Delete the area variables in the output shapefile and use the XTools extension to recalculate the areas as all have now changed. Using the area of the polygons in the new shapefile and the ambient population per unit area (AMBPOP_DEN), the ambient population count (AMBPOP) can now be calculated by multiplying the two variables together. At this stage, there are potentially multiple polygons associated with each census boundary unit. Therefore, the shapefile needs to be “dissolved” by the census boundary unit variable (its unique identifier), summing AMBPOP. This procedure is contained within the Geoprocessing Wizard in both ArcGIS and ArcView 3.x and sums all of the AMBPOP values associated with a single census boundary unit and creates a new shapefile. This new file can now be used for the presentation of the ambient population using the census boundary units, or joined together with other census data (such as residential population and crime counts) using the census boundary unit's unique identifier for further analysis.

The procedure outlined above has many steps, each critical to the proper assignment of the ambient population to the correct census boundary unit. However, with the ESRI software products mentioned above, there is no programming involved. Most of the steps can be performed using “procedure wizards” within the software.

Rights and permissions

Reprints and permissions

About this article

Cite this article

Andresen, M., Jenion, G. Ambient populations and the calculation of crime rates and risk. Secur J 23, 114–133 (2010). https://doi.org/10.1057/sj.2008.1

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1057/sj.2008.1

Keywords

Navigation