Working Note: Using SLEUTH Urban Growth Modelling Environment

Transcription

1 Working Note: Using SLEUTH Urban Growth Modelling Environment By Dr. S. Hese Lehrstuhl für Fernerkundung Friedrich-Schiller-Universität Jena Jena Löbdergraben 32 V 0.1 Versioning: v : initial stuff and structure definition 1.SLEUTH Intro Input Daten Driving SLEUTH Results from SLEUTH Verschiedenes SLEUTH Intro Preface: This document is based heavily on the web documentation for SLEUTH that can be found on the GIGALOPOLIS Project web Site: SLEUTH Overview Developed by Dr. Keith C. Clarke, research continues at the University of California, Santa Barbara, Department of Geography. This work began through sponsorship from the United States Geological Survey's Urban Dynamics program, and continues under the NSF funded Urban Research Initiative. A related UCSB website focusing on the NSF work is located on the UC-IME project page. The Urban Growth Model (UGM) is a C program running under UNIX that uses the standard gnu C compiler (gcc) and may be executed in parallel. It can be formatted for any other

2 standard C compiler. Some minor changes in the code might be necessary for execution in new environments. In order to implement the model a good understanding of C programming is expected. The land cover deltatron model (LCD) is included within the code and will be called and driven by the UGM. The LCD is tightly coupled with the urban code, but the UGM can run independently of it. Together, these coupled models are referred to as SLEUTH. The name SLEUTH was derived from the simple image input requirements of the models: Slope, Land cover, Exclusion, Urbanization, Transportation, and Hillshade. For a thorough explanation and history of this work, the publications pages should be reviewed. Tom Boutell's C language gd graphic libraries are also used and are included with the downloaded code. These libraries manipulate GIF images, and are no longer supported by the GD site which has converted to more open image formats such as PNG. For the execution of the model, it is assumed in this documentation that all program and input files are located as they are in the downloaded directory structure. The input files must be in the proper format, and a naming convention must be followed in order for the model to read data in correctly. In order to intelligently calibrate the model a thorough understanding of the growth rules, scenario file and statistical output files is necessary and should be reviewed carefully. 2 Input Daten SLEUTH requires an input of five types of grayscale gif image files (six if land use is being analyzed). For all layers, 0 is a nonexistent or null value, while 0 < n < 255 is a "live", or existing, value. The model requires all input layers to have a consistent number of rows and columns. For statistical calibration of the model, at least four urban time periods must be used. Also, for purposes of calibration, the roads must be represented in two or more time periods. The model requires two land use layers for deltatron land use modeling. All layers should be checked for agreement; urban areas should not be present locations defined as undevelopable in the excluded layer. SLOPE: The slope is commonly derived from a digital elevation model (DEM), but other elevation source data may be used. Cell values must be in percent slope, not degree, which is a common default in some GIS software. %slope equation: Pixel value range: LAND USE: Each pixel value contained in the grayscale land use images should represent a unique land class. For example, if the Anderson Level I scheme was used to classify the land cover data:

3 (R,G,B) class (1,1,1) urban (2,2,2) agriculture (3,3,3) range land (4,4,4) forest where (R,G,B) represents the red, green and blue color bands in the image, and class is the land cover type associated with the (R,G,B) value. This information is entered in the land cover colorable section of the scenario file where pix is the (R,G,B) value and name is the class land cover type. Pixel value range: EXCLUDED: The excluded image defines all locations that are resistant to urbanization. Areas where urban development is considered impossible, open water bodies or national parks for example, are given a value of 100 or greater. Locations that are available for urban development have a value of zero (0). Pixels may contain any value between (0-100) if the representation of partial exclusion of an area is desired - unprotected wetlands could be an example: Development is not likely, but there is no zoning to prevent it. Pixel value range: (values > 100, are read as 100) URBAN: The urban extent for the start year, or seed, is used to initialize the model and is the basis for the CA driven urban growth. For calibration, the earliest urban year is used as the seed, and subsequent urban layers, or control years, are used to measure several statistical best fit values. For this reason, at least four urban layers are needed for calibration: one for initialization and three additional for a least-squares calculation. The definition of "urban extent" is up to the creators of the data set. The model simply requires a binary classification of urban/nonurban. Methods used in the past include digitizing city maps and aerial photographs, thresholding remotely sensed images or block densities from census data. Pixel value range: 0 = nonurban 0 < n < 256 = urban TRANSPORTATION: The road influenced growth dynamic included in SLEUTH simulates the tendency of urban development to be attracted to locations of increased accessibility. A transportation network can have major influence upon how a region develops. To include this effect in calibration several road layers, that change with the city's growth over time, are desirable. SLEUTH will

4 be initialized with the earliest road layer. As growth cycles, or "time", pass and the date for a more recent road layer is reached, the new layer will be read in and development will proceed from there. Road network images may be binary (road/non-road) or have relative values: weighting 1 weighting 2 pixel values pixel values accessibility high 2 50 medium 1 25 low 0 0 none note that the relative weighting of the two schemes above are equivalent and would have an identical effect if applied to the same data. For more information see road weighting. Pixel value range: binary: 0 = non-road, 0 < n < 256 = road relative: HILLSHADE: In order to give spatial context to the urban extent data, a background image is incorporated into image output. This must be a grayscale image, and a hillshaded DEM (pictured here) is commonly used. To give further definition to a region, bodies of water may also be represented. This occurs by any pixels in the background image whose values are zero (0) being filled with the WATER color defined in the scenario file. *Note: this will also mean that any heavily shaded locations that have a zero value will also be filled with the WATER color. This can be avoided by remapping any zero values in the hillshade image to one (1) before adding the water mask. If WATER is defined as black (R,G,B = 0,0,0) zero value pixels will remain black in the output images 3 Driving SLEUTH The scenario file is where all execution option flags and variables are set. Understanding the options contained in the scenario file is crutial to properly executing and examining output from SLEUTH. The downloaded scenario file contains documentation on its options. An online example of this file may be found here:

5 4. Results from SLEUTH Output image types generated by SLEUTH are dependent upon the mode and function of the application. Further, flag settings in the scenario file act as secondary controls. The table below lists all image files generated by SLEUTH. Urban simulation image output: file name created in mode flag dependent animated_urban.gif P yes animated_z_growth.gif P yes cumulate_urban.gif P no <location>_cumcolor_urban_<stop_date>.gif P no <location>_urban_{date}.gif T, P no echo_of_<location>.{attribute}.gif T, C, P yes key_{colormap_type}.gif T, C, P yes z_growth_types_{run}_{monte carlo}_{date}.gif Land use simulation image output: T C P file name T, C, P yes created in mode flag dependent animated_deltatron.gif P yes animated_land_n_urban.gif P yes animated_z_growth.gif P yes cumcolor_landuse.gif P no cumulate_urban.gif P no <location>_cumcolor_urban_<stop_date>.gif P no <location>_land_n_urban_{date}.gif T, P no deltatron_{run}_{monte carlo}_{date}.gif T, C, P yes echo_of_<location>.{attribute}.gif T, C, P yes key_{colormap_type}.gif T, C, P yes uncertainty.landuse.gif P no z_growth_types_{run}_{monte carlo}_{date}.gif = test mode = calibrate mode = predict mode < > = static identifier T, C, P yes

6 { } = variable identifier STATISTICAL OUTPUT: Output data files generated by SLEUTH are dependent upon the mode of the application. Further, function and flag settings in the scenario file act as secondary controls. Some contain information on memory storage and system performance while others store model output data. Generating log files can slow the model's performance considerably, especially during calibration. For general applications, most log flags should be set to "NO". The table below lists all statistic files generated by SLEUTH. T C P file name created in mode flag dependent LOG_# T, C, P yes avg.log T, C, P yes coeff.log T, C, P yes control_stats.log T, C no restart_file.data# T, C, P no std_dev.log T, C, P yes = test mode = calibrate mode = predict mode < > = static identifier { } = variable identifier avg.log and std_dev.log flags: WRITE_AVG_FILE(YES/NO) and WRITE_STD_DEV_FILE(YES/NO) Measurements of simulated data, such as number of urban edges, clusters and urban pixels, are saved in the avg.log file. If in test or calibrate mode, for every year that real data exists (a control year) SLEUTH writes out a grid of urban extent (and land cover). Values are calculated from these grids and at the end of a run (a run begins with a single set of coefficient values and is executed n MONTE_CARLO_ITERATIONS). These values for each year are then averaged over the number of monte carlo iterations, and the result is written to the corresponding run number in control_stats.log. The standard deviations of the averaged values are written to the std_dev.log file. If in test mode, this process is performed for every year, not just the control years. The avg.log file may be used in the final step of calibration to derive forecasting coefficients. control_stats.log Control_stats.log is generated in test or calibrate mode. It contains the r2 values of the simulated data (found in the avg.log file) compared to input urban (and land cover) data. The values for the input urban statistics can be written to the LOG_# file by setting the LOG_BASE_STATISTICS flag in the scenario file to "YES". This is the primary file used to narrow coefficient ranges during calibration. coeff.log flags: WRITE_COEFF_FILE(YES/NO) Due to SLEUTH's self-modification qualities, coefficient values may be modified slightly after each growth cycle. The coeff.log file stores coefficient values for every run, monte carlo iteration and year. These data can also be written to the avg.log file. This file may be used in the final step of calibration to derive forecasting coefficients.

7 5 Verschiedenes