The Texas Legislative Council (TLC) has developed a GIS application using ArcInfo for the redistricting projects in the State of Texas. Three main applications have been written to accomplish this task: Redistricting Application (Red Appl), Boundary Definition System (BDS), and Spatial Integrated Cartographic Environment (SPICE). These application programs have been written using a combination of AML and C code. Red Appl is used to assist legislators and their staffs to create house, senate, congressional, State Board of Education, and judicial districts based on TIGER, U.S. census, and election data. BDS is a user interface system used by the GIS specialist at the TLC to create and update cartographic databases primarily for precinct coverages, voter tabulation districts (VTDs), and updates to school district boundaries. SPICE is the main menu-driven application for producing large numbers of maps. The SPICE menu system allows operators to choose a specific map for production and customize which features to show based on the needs of the request. This paper discusses how each application is used in the GIS application process for redistricting.
INTRODUCTION The decennial federal census, originally conceived as a method for ensuring equal representation among the states in the congress, is the basis for political reapportionment. Redistricting processeses must follow the "one person, one vote" principle and "must make a good faith effort to achieve precise mathematical equality." The states must defend even minimal exceptions, showing why better precision is unattainable by use of the best available data. The Texas Constitution requires that reapportionment be based on the population of the state "as ascertained by the most recent United States Census," and soon after its publication (Texas Constitution, 1876). Every redistricting plan is subject to the provisions of the Voting Rights Act of 1965, requiring pre-clearance by the U.S. Department of Justice. The complexity of meeting various levels of governmental requirements necessitates a need to develop an automated system in order to aid users in their decision-making process. The Texas Legislative Council (TLC) has developed a Geographic Information System (GIS) application to fulfill this need. The purpose of this paper is to: (a) discuss the requirements for redistricting; (b) describe and discuss the redistricting and adjunct applications; and (c) show how a geographic information system successfully supports redistricting and cartographic needs. The TLC is an agency dedicated to providing professional, nonpartisan service and support to the Texas Legislature (Texas Legislative Council, 1990). A major part of its activity is dedicated to drafting legislation. It was clear that if the state's redistricting solutions were to come from the Texas Legislature and not from courts or others, that the TLC must provide the legislature with a successful system that could provide the needed modeling and reporting capabilities. Requirements for Redistricting Although protection from the passage of any legislation abrogating a citizen's right to equal protection (including the right to vote) is elucidated in the 14th and 15th amendments to the U.S. Constitution, it was probably not until 1962 (Baker v. Carr, 1962) that a federal court found reapportionment justifiable with respect to those protections (one person, one vote). A chronology of events since that time would include passage of the Voting Rights Act and numerous legal rulings which would easily fill a textbook. The current discussion is about the technical constraints. The states must show that any deviation from a normal district size is defensible, either for some pragmatic reason (geography was one) or, because given the best available data, a better solution was unattainable. In addition, the states must also meet the Voting Rights Act guidelines. Contending players must have easily attained access to the data, which provide the common ground on which solutions are built. The GIS system must be capable of tracking client activity without compromising confidentiality, making it possible to archive and retrieve historical versions of redistricting plans and data as needed. It must also have a reporting and cartographic capability that would facilitate the pre-clearance process. Figure 1 shows the agencies involved in the redistricting process.
Figure 1: General flow chart for the redistricting process in Texas. The current GIS platform in use at the TLC consists of a local area network network of 12 Hewlett-Packard series 300/400 workstations running HP-UX using ArcInfo as the main GIS application software. Twenty gigabytes of storage space is available for redistricting data and application software. Large format map output is produced on an electrostatic E-size Calcomp plotter and two HP PaintJet plotters for 11-inch by 17-inch maps. Each workstation is also equipped with an HP laserjet printer for 8.5-inch by 11-inch as well as 8.5-inch by-14 inch black and white maps. The GIS platform is also networked to the TLC mainframe for transfer and storage of additional census data as well as access to other mainframe applications. U.S. census data serves as the main source for all base maps and analysis. The GIS platform is currently being upgraded to a HP K-200 (server) and J-200 series workstations with an additional 12 gigabytes of storage capacity as well as a HP 755cm plotter for improved map output. The system is also currently in migration to version 7.0.4 of ArcInfo. These upgrades are planned to be in use well before the next legislative session in January 1997. APPLICATION SYSTEMS Boundary Definition System The Boundary Definition System (BDS) is a GIS application developed in a UNIX environment using ArcInfo. The purpose of this application system is to provide the TLC staff the ability to create or change the geographic boundaries of different types of working coverages (i.e., adjusting precinct and Voting Tabulation District (VTD) boundaries as a result of changes in precinct lines made by individual counties). The system mainly uses Arc, Arcedit, Arcplot, and INFO to perform the necessary tasks. The system was designed so that it can be easily modified and prepared for use with other geographic datasets as needed, such as school districts, municipal utility districts, water districts, etc. BDS is divided into three main functions: (1) The Add Arcs module which allows a user to add an arc into an existing working coverage by extracting an arc from a background coverage or drawing a line; (2) The Assign Polygons module which allows a user to assign a polygon block to a specific unit such as a precinct or school district. Additionally, this subsystem provides several methods for changing district numbers; (3) The Additional Operations module provides the user the opportunity to run reports, dissolve working coverages, and to run a process called VTDSNAP for automatically adjusting any VTD. A client uses these modules to create a new VTD coverage. The process that the clients uses is outlined below: (1) create a new precinct working coverage from a census block coverage; (2) dissolve the working coverage on a precinct number; and (3) do a VTDSNAP on the dissolved precinct coverage. This VTDSNAP process provides the ability to automatically adjust (snap) precinct lines within the working coverage. The purpose of this operation is to make VTD lines follow census blocks, which is not necessarily true with precinct lines. VTD lines essentially follow precinct boundaries as long as these boundaries follow block lines. Therefore, if a precinct line follows a nonblock feature, then the VTD line must be "snapped" to the nearest block boundary. The entire block will be assigned to the VTD district that currently has the largest area of the block. After the client has finished making precinct assignments, the working coverage must be dissolved on precinct numbers. This will remove lines between polygons that have the same assignment leaving a single polygon for each contiguous precinct. During the dissolve process, the following reports are produced to assist the client in determining that all precincts have been assigned correctly: (1) Missing geography - detects unassigned geography; (2) Noncontiguous polygons - detects island polygons; (3) List - creates a general list of all units; (4) Splits - shows any units split by district lines; and (5) Changes - shows any units changed between the previous and new precinct coverage. An additional check is made to determine if the precincts are correct. Since the TLC works with two separate precinct databases, a check between the two databases is made. One database is maintained in the Texas Election Database (TED), a mainframe application used by the redistricting staff, which consists of tables of election information reported by precinct. The staff receives election data, and the associated precincts from counties, and enters this info into TED. The other database is maintained in BDS. Both databases agree so that election information can be allocated to VTDs. This check involves writing the BDS precincts to a UNIX text file. This text file is sent to the mainframe where the actual comparison is completed and which generates a report detailing any discrepancies. After the precinct production coverage has been created, the precincts must be snapped to block lines. When the VTDSNAP is completed, the same reports that are produced for the dissolving of precincts are generated to assist the client in determining that the VTDs have been snapped correctly. In addition, another process is initiated to send the VTDs and their corresponding precincts to the mainframe where election data is allocated from precincts to their respective VTDs. After the allocation of election information to VTDs, the VTDs and their respective election information is sent back to the GIS system and used in the Redistricting Application system. Redistricting Application System The Redistricting Application (Red Appl) system is a graphical GIS system developed to assist legislators and their designees to create house, senate, congressional, State Board of Education, and judicial districts by graphically displaying geographic, population, and election data. The Red Appl system was developed using ArcInfo, UNIX shell scripts, X windows, and C programs. It mainly uses Arcplot, INFO, and Librarian modules of ArcInfo. Geographic features such as county boundaries, tracts, and blocks are taken from TIGER (Topologically Integrated Geographic Encoding and Referencing) data provided by the U.S. Census Bureau. Population data is also provided by the census bureau. Election data is maintained by the redistricting staff using TED and BDS applications. In addition to Red Appl, the Population Analysis System (PAS), a nongraphical, IBM mainframe application, exists to assist redistricting clients (any member of the legislature or any group sponsored by the legislature) to create district plans. Due to the limited number of workstations and a large client base, PAS tends to be used as a sister system to Red Appl. The PAS system does not provide all the functionality that Red Appl provides. Clients can only create districts from VTDs and counties and does not provide a graphical interface. However, it does provide the client base more access to redistricting information since every client has access to mainframe applications and every client does not have a workstation. The client can begin creating a plan (a proposal for dividing the state into districts) by assigning districts at their respective offices using the PAS system. The client can then transfer this plan to the Red Appl system and use one of the limited number of workstations to assign districts at a much more detailed level of geography using a graphical GIS interface. Administration, plan manipulation, and modeling are the main modules to Red Appl. Administrative functions include copying plans between clients (interclient), authorizing new client accounts, making plans public, merging two plans, sending a plan to the mainframe for a more in-depth population analysis report using the PAR system on the mainframe, producing a contiguity report, producing an unassigned geography report, and dissolving a plan for mapping. Plan manipulation includes all functions that manipulate a client's plan other than the actual assignment of geography (such as copying a plan intraclient), marking a plan for deletion, creating a new plan, viewing/adding comments, editing a plan's description, renumbering districts, copying a county, recalculating population statistics for a plan, and generating reports on contiguity, unassigned geography, and incumbents, as well as producing a simple population analysis report. Modeling incorporates viewing graphical and nongraphical population data, election data, and geographic features in order to assist in the adding/removing of geographic units to a particular plan. It also provides the client the opportunity to choose the level of geography for modeling. In modeling, the client can add/remove multiple units of contiguous or noncontiguous unfrozen units of geography or display information about a selected unit of geography. After the client has assigned a polygon to a district, the client can freeze this assignment. Therefore, when the client wants to unassign a group of geography, the client will be informed that the client has selected one of the districts that cannot be changed. Types of data and geography used by the Red Appl system are: (1) Census geography - blocks, block groups, and counties; (2) Election geography - Voting Tabulation Districts; (3) Election returns; (4) Census population statistics - total population, age population, minority total population, minority voting age population, and noncitizen voting age population. Each district in a plan that is drawn by a redistricting client must comply with the following criteria: (1) follow a block boundary line; (2) be contiguous; (3) have a population that is close to the population of all other districts in the plan; and (4) not have minority population that will have the effect of discriminating against the minority group. In order to assist the client in meeting the above criteria for a district composition, population statistics are tracked and are reported both on the screen and as hard copy output by Red Appl and the Population Analysis Report (PAR) system. PAR is a mainframe application that provides detailed reports about a plan's demographics. In addition to the population information, election information can be reported for a plan to assist the client in drawing districts. However, election information is reported by precinct and does not necessarily follow block lines. Since all district lines must follow a block boundary, the precinct lines must be adjusted to follow block lines and election data must be allocated from precincts to the VTD level of geography, which are then allocated to all other levels of geography. The population information and election information can also be used to shade the level of geography on the screen. Since a district line must follow a block boundary line, all levels of geography (i.e., block, VTD, county, tract, and block group) that a client can use to draw districts must follow block lines. All these levels of geography follow block lines, therefore, they do not have to be adjusted. The population for these levels of geography are reported at one of the levels of geography and have to be allocated to the other levels. For example, if population is reported at the block level, it will be allocated to the other levels of geography (i.e., county, VTD, tract, and block group). The Red Appl system also provides reports about contiguity and unassigned geography, since all geography must be assigned and all districts must be contiguous. Figure 2 illustrates the hierarchy of the different levels of geography that a client can use in creating districts.
Figure 2: Hierarchial structure of geography for creating districts. Most of the programs are written in AML, however, some C programming and UNIX shell scripts are incorporated in order to speed up the system and compress the files. In order to preserve disk space, the plan file with district assignments is packed at the block level using a run length encoding process. The pack and unpack routines are used when the client changes from one level of geography to another and when the client enters or exits modeling. Unpack means taking a packed plan file, uncompressing it, and expanding it to the level of geography at which the client wants to model. Pack means taking an unpacked plan file, expanding it to the block level, and compressing it. Compress means taking an unpacked plan at the block level, and compacting it using a district compression routine written in-house. Uncompress means taking a packed plan file and enlarging it to the block level. The unpacked UNIX plan file is externaled to an INFO file. This INFO file keeps track of the district assignments and shading of districts while a client is creating districts. When a client wants a map produced of the plan using the automated mapping system, an operator must dissolve the plan. Since up to this point the plan is only a file used for shading the districts and is not a coverage, the statewide VTD coverage must be dissolved on district numbers in the plan file. This statewide dissolved coverage is the statewide VTD district coverage. If a county is split at a level of geography other than the VTD level, the county block coverage must be dissolved on district numbers in the plan file. Each county that is dissolved at the block level is joined. This joined coverage is used to update the VTD coverage in order to create the statewide district block coverage. In addition to the statewide coverages, each county that is split at any level of geography has a coverage created as well. After the dissolve process, ArcInfo coverages are available for use in the mapping applications. Spatial Plotting and Integrated Cartographic Environment The Spatial Plotting and Integrated Cartographic Environment (SPICE) is a map-plotting application that makes extensive use of Arcplot. It was originally made available to users at the TLC in 1992. An improved version became available in 1993-1994 and enhancements have been added since then. The need for a standardized plotting system originated with the needs of the client base. The first and most important purpose of the system was to have at hand a capability for producing demographic maps and maps that show political geography quickly and accurately (Burrough, 1986; Goodchild and Kemp, 1990; Huxhold, 1990). Not only would the maps be needed as working papers for our clients, but they would be used for submitting redistricting plans for pre-clearance by the U. S. Department of Justice in the Voting Rights Act. It was recognized that since there would almost certainly be litigation, the courts, justice department, and the redistricting players would be best served if they could share common resources (including those associated with printing maps and reports) and data. It was expected that the GIS technical support would also prove useful for projects other than redistricting, therefore, the system had to have the capability for extensions to cartographic support for other projects as well; this was a distinction made between routine (redistricting) and special (all other) requests. The routine requests would be fully classed, but a programming standard would be that the system not be limited to its original vision, therefore, designed to accommodate new kinds of requests. Since its first use in 1992, it has processed a hundred routine requests and about twice as many special requests. The SPICE system is a menu-driven mapping application designed to produce a wide variety of maps in quantity, in such a way that there is a consistent treatment of the content from one page to the next, and so that the same map will be easily reproducible years into the future. In its current version, the menu system is constructed from X-intrinsic "widgets," built around a core of C programs that mediate a dialogue in which system values and small files are built that will provide the particulars about the content of the map. In the Arc environment, there is a collection of AML macros that accepts the parameters and generates the map. One macro sets up the page layout, another prints the titles and a logo, another handles coverages and data naming conventions, another adds the map content and builds a legend, others control text styles and fonts, and so on. This modular approach has given the system the flexibility it needs, while providing stylistic consistency and providing the capability for handling the special requests. The model is a semantic system in which there are basic themes that have characteristics that can determine the map. For example, a mapping AML called "red500," routine request ("red"), generates a map of political districts ("500" indicates that the map will contain a redistricting plan). A redistricting plan is a universe of polygons (districts) that are mappable at the extent of the state, of an individual county, an inset of a county, a city, and so on. In this system, then, "red500.aml" will contain options that will permit the user to specify a map extent based on one of those places. The AML presents the users with options to map a redistricting plan as a type DS (district), STATE (the entire state), C1 (a plan within a county), and so on. Selecting "C1" (by clicking on a button) displays a menu that allows the user to build a list of counties (each page will be a map of a county); selecting "DS" instead causes the user to display a list of districts to choose from, and each page is a map whose extent is that of an individual district. The first major departure from the so-called RED (redistricting, routine request) maps were those associated with school funding. This was a focus of legislative activity in 1993 and 1995, and led to the creation of an SDI series of maps that presented econometric data supplied by the Texas Education Agency in much the same manner as the thematic presentation in the redistricting maps. At this time (March 1996) the map groups are: Map type RED - associated with routine redistricting requests SDI - school districts, school funding JUD - judicial redistricting SPE - special request maps TLC - in-house data verification Map Class 000 - 099 census geography or other spatial information but no thematic content 200 - 299 census geography, with a population theme by thematic shading 300 - 399 census geography with an election result by thematic shading 500 - 599 a redistricting plan with no thematic content 600 - 699 redistricting plan, with a population theme 700 - 799 redistricting plan, with an election result as thematic content 800 - 899 maps showing two or more plans simultaneously. Important features of this system include that the AMLs containing the core functionality are useful in several contexts, and the use of recursion and modularity are the standard. This permits the creation of batch processes that will produce a complete set of maps from one invocation of the system. For example, one of the processes, "red599," permits users to specify a "plan packet," which spawns a subprocess that will unpack a client plan from the Red Appl system, generate a list of counties needed to make a complete set of maps, determine which will require a full page and which can be placed in a four-per-page layout (generally, the rural counties), and print the entire package by repeatedly invoking variants of another AML, "red595." In this example, there are several versions of a plan packet: one that provides city limits; another zip code areas; and a third, voting precincts. This obviates any concern for operator error, especially important during a waning legislative session when there is a peak of activity and fast publication is essential. The maps are distributed to clients and the general public through the redistricting library at the TLC. In the interest of facilitating public access to the data, routine requests are available to the general public at cost (this includes a very inexpensive but complete presentation on legal-size, monochrome plan packets that are optimized for easy photocopying). There is a vision of extending public access through the internet in the near future (a " server"), but also a recognition that there will still be a need for access to hardcopy, for the foreseeable future. Boundary Block Suggestion Project The Block Boundary Suggestion Project (BBSP) provides a forum for states to "suggest" census features to be held as block boundaries for the 2000 census. Working with procedures and data from the U.S. Census Bureau, the participants will select census features to define census block boundaries which will most benefit their states to create voting precincts and legislative districts. The TLC has been chosen to be the participant for the State of Texas. A GIS application has been written to help the council complete this project. The data from the census bureau to be used is the 1995 TIGER/Line files specifically created for BBSP. The files will be converted to ArcInfo coverages using a program created by Esri called TIGERTOOL94. After conversion, the coverages will have two new important items in the AAT: BBSPCEN and BBSPPART. The BBSPCEN item has three possible values and are set by the census bureau. A value of 4 means the arc is guaranteed to be held as a census block boundary. A value of 2 means the arc cannot be held as a census block boundary. A value of 0 means the arc has not been flagged by the census bureau and the participant can either leave the arc unflagged, flag as a "must hold," flag as a "do not hold," or flag as a "contingent hold." All these choices made by the participant will be stored in the BBSPPART item. For a final output, the census bureau requires an ASCII text file which includes a state code, a county code, TLID number ( a unique number the census bureau has assigned to every arc in the U.S.), and the value of the BBSPPART item. The file will contain every arc in that county, not just the ones that were flagged. The TLC wants to ensure that the boundaries that make up voting precincts and legislative districts are held as census block boundaries. This will ensure that VTDs will be able to represent precincts as closely as possible. It was determined that a process was to be created to automatically match as many of these precinct/district arcs to BBSP arcs as possible. An automatic matching process would save an incredible amount of time in determining which arcs are to be held. The automatch process is a very important step in the pre-processing of the data for the application. The precinct/district coverages were originally created by 1990 TIGER/Line files, so they match up with the BBSP arcs for the most part. Pseudo nodes had been removed from the precinct coverages and some additional arcs had been added when precinct lines did not follow census features. The goal was to match the coverages (node-to-node and arc-to-arc) as much as possible so a MATCHCOVER command could be executed. To accomplish this, the precinct/district coverages were unioned with the BBSP coverage. The results of the union had the nodes needed from the BBSP coverage and the attributes from the precinct/district coverages to identify the arcs as precincts or districts. The output coverage was dissolved using the precinct/district items as the dissolve items. The net option was used to ensure the arc attribute information remained intact. The net option left many arcs in the dissolved coverage that did not make up a precinct or district boundary which were subsequently deleted. At this point, the manipulated coverage had only the arcs we originally started with in the precinct/district coverages, except now nodes were inserted where the coverages were intersected by BBSP. This allowed for the closest match, topologically speaking, for the BBSP and the precinct/district coverages. The items of both coverages were made identical, which is required for the MATCHCOVER to work. The MATCHCOVER is used to transfer attributes from one coverage to another when the arcs of the two coverages fall within a given tolerance. A tolerance too small gives few matches, not allowing for any variation between the two coverages. A tolerance too large gives multiple matches which are ignored as if nothing matched. Each county had a different match rate but all seemed to fall between 90 and 100 percent. The important information transferred during the MATCHCOVER was the TLID value item. Simply having the TLID for the arcs to be held was not enough. It was also important to know how that the census bureau has flagged those particular arcs (BBSPCEN). If the BBSPCEN value was a 4 (Guaranteed Hold), nothing needed to be done. If the BBSPCEN value was a 2 (Cannot Hold), an alternative arc would need to be chosen during manual selection. If the BBSPCEN value was a 0 (Not Flagged), the BBSPPART item needed to be flagged as a "must hold." To accomplish this, the newest coverage was related to the BBSP coverage in INFO using the TLID as a common item. Items were added to the BBSP coverage to identify all arcs that were precinct boundaries and, also, which arcs were district boundaries. The precinct/district and BBSP coverages are copied to a county workspace for storage until the operators are ready to work on them. The second module is the interface that allows the operators to manually flag BBSP arcs to be held. This module is executed in Arcplot since only attributes are being changed and allows for easy viewing of many coverages to be used as references when selecting arcs. Also, using MAPLIMITS, a locator window is drawn in the corner of the screen to show which part of the county is currently being viewed. A pop-up menu, with a list of nonmatching arcs, allows the operator to simply select one of these arcs and zoom in on the selected area. As the problems are fixed, the operator updates a field to show how the fix was accomplished. The field is updated in the pop-up menu so that the operator knows which problems have been fixed, how they were fixed, and wihch problems were left to work on. A drawing options menu is available to toggle on/off features like BBSP arcs, precinct arcs, district arcs, city limit boundaries, and feature type (CFCC) arctext. In addition to the zoom by selection feature, the operator has the ability to move around the county with features such as window-in, zoom out, pan, and save/restore mapextent. Buttons are available to flag BBSP arcs as "must hold," "do not hold," and "contingent hold." Also, an option is available to return a flagged arc back to the default value set by the census bureau. The color of the arcs is updated on the screen to represent how it has been flagged. A checker can also use the same functionality in this module to make sure the operators are making selections that conform to census bureau procedures and TLC needs. The final module is used to create the Equivalency File which will be sent to the census bureau. A copy of the BBSP.PAT is manipulated and used to create an ASCII text file in the form requested by the census bureau. These files will be sent over the Internet to the U.S. Census Bureau Regional Office in Dallas. This will complete the first phase of the Block Boundary Suggestion Project. SUMMARY The TLC has developed three main GIS application systems to assist legislators and their staffs to determine district boundaries for the State of Texas: BDS - creating and updating cartographic databases; Red Appl - create and modify district boundaries; SPICE - automated mapping system. In addition to these main applications, BBSP is being used to suggest block boundaries for the next census in the year 2000. All these systems are designed to work in conjunction with one another in order to automate cartographic, mapping, and analysis work. These automated systems have been an invaluable tool over the last few years in redefining and updating political districts. These GIS applications have been a success for redistricting and demonstrate the usefulness of GIS for applications development in the legislative community. ACKNOWLEDGMENTS The authors wish to acknowledge the following people who have contributed to one or more of these projects: Kelly Clausius, Todd Giberson, Rai-Ling Lee, and Reginald Warren (original designers of the Red Appl system); Kirk Divine, Tina Hengst, Carl Keprta, Shelley Leach, Steven Marquardt, Gregory Samson, and Robert White (for their work in the SPICE and BDS systems) Michael Clark, Robert Gatliff, Chris Miles, Thomas Moe, and James Ting (network and systems support); Tobin Crain, Clare Dyer, and Gary Grief (block boundary suggestion project); Greg Tingle and Tom Hayden (mainframe support), and especially Debbie Elliott, Alan Ware, and Shane Groves whose patience and support will not be forgotten; all helped to "put the GIS" into legislation; and finally to Karen White and Debbie Irvine, whose creativity and leadership made it all possible. REFERENCES Baker v Carr, 1962, 369 U.S. 186 Burrough, P.A., 1986, Principles of Geographical Information Systems for Land Resource Assessment: Oxford University Press, Oxford, 194p. Constitution of the State of Texas, 1876, Article 3, Sections 26, 26a, and 28. Esri, 1992, ArcInfo Technical Manuals: Esri, Inc., Redlands, California. Goodchild, M. F., K. K. Kemp, 1990, NCGIA Core Curriculum: National Center for Geographic Information Analysis: University of California at Santa Barabara, California. Huxhold, H.E., 1990, An Introduction to Urban Geographic Information Systems: Oxford, Oxford U.K., 337p. Texas Legislative Council, 1990, Guide To Redistricting, Information Report No. 90-1.