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.