The city of Long Beach, Calif., requires re-evaluation of its City Council districts once every five years to adjust for changes in population and ethnic composition. In 1991, redistricting was a labor-intensive process that took five months to complete. Thanks to technology, the next round of redistricting was much more pleasant. GIS Manager Tina Dickinson, using only ArcView, developed an application allowing Long Beach to wrap up
the redistricting project in just over two weeks.
Ruth McGree, chief of staff to Councilman H. Delano Roosevelt, said the 1991 redistricting was done manually, with each minor change to a district requiring recalculation of ethnicity and population figures. "We would sit down with maps and move district lines and see what census blocks were taken in. Then we would add up those figures, locate the larger-density areas and redesign the districts so that people were spread out evenly among all nine. It seemed to take forever.
"The political nature of redistricting is tough enough," McGree said, "having to add figures up on a Paradox-type program and estimate the final demographics and population figures for every change made was really tough." Since even the smallest change to a district required so much time and effort to assess the impact on all the others, council members were limited in the number of changes they could make. Not everyone was happy with the results.
Dickinson's user-friendly application, on the other hand, let council members and their aides create hypothetical district changes almost as fast as they were needed, after only 30 minutes of instruction. Without this application, redistricting in 1996 might have taken nearly a year to complete.
Of course, the technology was only part of the solution; before it could be used, the city had to adjust for the undercount of the 1990 Census, sort through a decade of economic decline, and come up with a new model on which to base ethnicity and population estimates.
Decade of Decline
From the late 1980s onward, Long Beach has experienced a series of economic setbacks. The Navy closed its massive shipyard, including its base, housing area and hospital; the Los Angeles riots torched part of the city, and Douglas Aircraft cut its workforce by nearly 50 percent. The cost? A $4 billion hole in the economy and 58,600 jobs lost. More than 21,000 people left town for good. Trying to assess the resulting changes in population and ethnicity, and come up with anything resembling an accurate census for the redistricting program presented a formidable challenge.
Assembling the Data
Data acquisition and processing was the task of Advanced Planning Director Jack Humphrey. Drawing from the 1990 Census, and from a subsequent demographic model developed by the Urban Research Unit, Humphrey created a 1.8MB spreadsheet down to the census-block level, then used it as a basis to estimate the ethnicity and population of the various districts.
Humphrey acknowledged the estimates were bound to be shaky. "Certainly, there was some element of error, but we felt we kept it to a minimum. Also, since the redistricting process involved large areas of the city, we believed the differences would average out."
In addition to new addresses picked up during the Census Bureau's LUCA (Local Updating of Census Addresses) Program in 1995 (see "The Census of The Century," Government Technology, August 1998), the planning department factored in the number of buildings and apartments demolished or no longer occupied, and checked with schools to determine the current ethnicity in various areas. "We couldn't wait till the year 2000 to do this," Dickinson pointed out. "Besides, we expect to run the redistricting process again as soon as the Census 2000 data is available to us. We'll probably see lots of changes in ethnicity, not so much in the number of people."
Building the Application
While the data was being assembled, Dickinson created and tested the Graphical User Interface (GUI) for the redistricting application. The primary considerations were that the program be easily understandable to council members and their aides, that it display immediate demographic changes in response to district boundary moves, and that it conform to city redistricting guidelines.
Dickinson designed the GUI to immediately display the results of district boundary changes geographically as well as through bar charts, pie charts, tables and a histogram indicating the degree of deviation from the ideal population configuration.
Dickinson linked the population data, provided by the planning department in DBF format, to the polygon shape files of census blocks, the latter being color-coded by district. To ensure boundary changes remained within city guidelines for redistricting, she also programmed the application to prevent the splitting of census blocks, moving council members out of their respective district, or putting together or breaking up districts with a minority majority.
Seeing the Options
Council members were allowed to develop up to five separate redistricting plans each for discussion. Out of these, members would select several for presentation to the City Council. Approved plans would then be open for discussion at a public hearing.
Since the application immediately and graphically displays the effects of boundary changes on the population and ethnic composition of a particular district, members were able to quickly explore a range of redistricting plans. The steps are fairly straightforward and the results of boundary changes immediately available. For example, if a district boundary is moved to include two adjacent census blocks, the newly acquired blocks assume the color coding of that district.
The program then recalculates the resulting changes in population and ethnicity, and indicates how close the district is to the ideal configuration. Council members can also click on a census block outside their respective boundaries and see its demographic makeup before moving the block into their district. The ability to quickly generate "what if" options helped members determine those redistricting plans most likely to be approved by other members, the City Council and the public.
Throughout the process, however, boundary adjustments had to be small because changes to a district also affected the surrounding districts.
The GIS staff trained council members and their aides in half-hour sessions for each group. After that, two-hour time slots on the application were allocated to each group for developing their respective plans. According to Dickinson, plans for all nine districts were completed within a week.
"This wasn't just for their own districts; council members had to come up with five plans for the readjustment of all districts." She said the process was an eye-opener for many council members. "They had an intuitive idea of the ethnic breakdowns of their respective districts, but some of them were in for a surprise when they incorporated census blocks into their districts before checking them out."
Dickinson said that after development of the individual plans, council members had to convince others that theirs was the plan to go with. "There was a lot of discussion and compromising. If a member liked another's plan except for one or two points, they would do minor tweaking until both were satisfied. Those who didn't need to make any plans agreed with the ones developed by others. In the final phase, council members came up with three different plans and voted on them. Open hearings resulted in general public approval of the final redistricting plan."
"It was an elegant application," said Humphrey. "Simple, easy to use and totally interactive. We tried to make it as open and understandable as possible. As a result, we did the redistricting process in just over two weeks. The public was generally accepting of the plan, mainly because there were no dramatic changes in the borders. The 1996 redistricting plan produced zero litigation."
Bill McGarigle is a writer, specializing in communications and information technology. He is based in Santa Cruz, Calif. E-mail