Minnesota Redistricting System
The State of Minnesota has had a computerized geographic information system since 1967. It was originally developed and maintained by the University of Minnesota under the name Minnesota Land Management Information System (MLMIS). It was not used to support redistricting in 1972. Rather, the University's Minnesota Analysis and Planning System (MAPS), which used a computer only to tabulate the census population data, provided technical support to the Legislature and a three-judge federal court.
In 1978, primary responsibility for the State's geographic information system was transferred from the University of Minnesota's MLMIS to a new Land Management Information Center (LMIC) in the State Planning Agency.
The 1982 redistricting was done on LMIC's PRIME 550 mainframe computer using redistricting software developed by Abt Associates, Inc. under contract with the Legislative Coordinating Commission's Subcommittee on Redistricting. Earl Nordstrand, as head of LMIC, supervised the creation and operation of the redistricting system. His supervisor was Al Robinette.
After the 1982 redistricting, the State Planning Agency was reorganized. The functions under Mr. Robinette's supervision were renamed the Planning Information Center (PIC), which included both the Land Management Information Center and the State Demographer. In 1983 the PIC purchased a copy of ARC/INFO (the second site in the country) and used it to operate the Land Management Information System on a PRIME 9955II mainframe.
For the 1990s round of redistricting, Mr. Robinette recommended that the Subcommittee on Redistricting purchase its own dedicated geographic information system using Unix workstations, rather than using the PIC mainframe. ESRI, Inc., the developer of ARC/INFO, hired Earl Nordstrand to tailor ARC/INFO for use in redistricting.
The Subcommittee contracted with ESRI, Inc. to customize ARC/INFO's core redistricting application for use in Minnesota. The application was run on SUN MicroSystems graphics workstations using the Unix operating system. Each caucus had its own SUN workstation and a Hewlett-Packard LaserJet IIP printer for printing reports. Large-format maps were plotted on a Precision Image plotter maintained by Charles McCarty, the System Administrator. The system was used by all four caucuses as well as by the three-judge panels in state and federal court to draw legislative and congressional plans. It was also used by the Legislature to draw Metropolitan Council districts in 1993.
In 1992, the Subcommittee on Redistricting was renamed the Subcommittee on Geographic Information Systems. It maintained and upgraded the hardware and software used for the system, continuing to rely on SUN as the primary hardware vendor and ESRI as the primary software vendor.
For redistricting after the 2000 census, the system will move from a Unix operating system run on SUN workstations to a Windows 2000 operating system run on Dell personal computers. ESRI's ARC/INFO, ArcView, and Map Objects will continue to be the primary software for day-to-day GIS operations and may be used to print maps and post plans to the World Wide Web, but the redistricting will be done using Maptitude for Redistricting from Caliper Corporation. The redistricting hardware and software will change, but the functionality of the system used to draw plans will remain essentially the same.
II. System Description
A. Work Sites
1. Office Space
The computerized redistricting system consists of four caucus work sites and two work sites for the nonpartisan director and assistant director of GIS. The GIS Director's workstation functions as the file server for the redistricting network.
2. Workstations and Peripherals
Each work site is equipped with the highest performance personal computer currently available. Each PC has dual Pentium III central processors with speeds of at least 1GHz and 1 GB of RAM. It has a 3.5 inch floppy drive, a DVD drive, a rewritable CD-RW drive, and a DLT tape drive. It has a T1 connection to the Internet. It has a 21" high resolution monitor. Each work site includes a video projector and screen to facilitate small-group participation in drawing plans.
3. File and Map Storage
Each work site has at least 36 gigabytes of hard disk storage capacity. This will be sufficient to store a complete copy of the geographic, population, and election database and all the plans created there. Each work site has a map rack and storage cabinet.
4. Output Devices
Each work site has a Hewlett Packard DesignJet 5000 plotter that can plot maps up to 42 inches wide and of any length, either in color or in black and white.
Each work site has an Epson Stylus Color 1520 ink jet printer to print size "A" (8-1/2" x 11") to "C" (17" x 22") maps and a Hewlett-Packard 8150DN laser printer for high-speed printing of reports.
5. Copies of Maps
Both the "A"-size and 42" plotters can print multiple copies of maps, but will take awhile. The GIS Director will keep abreast of developments in color copier technology, so that a copier may be used if it becomes feasible.
The system provides a DLT tape drive for each workstation and for the system as a whole, with copies put into vault storage at a remote location.
7. Uninterruptible Power Supply
Each workstation has an uninterruptible power supply to permit it to be shut down in an orderly manner in the event of a power failure.
The six work sites are connected to each other through an Ethernet network.
The network will be used to copy the common database onto each caucus's hard disk, to transmit plans to the central Web server, and to exchange plans among the caucus work sites. The network system includes electronic mail.
Network security will not allow a user electronic access to the plans, maps, or reports created by any other user, except as authorized by the user who created the plan on which the maps and reports are based. The GIS Director has electronic access to all data, plans, maps, and reports, but is not expected to use it except as necessary to keep the system running properly.
1. Common Database
The elements of the redistricting database, other than any confidential data added by each caucus, will be maintained by the GIS Director as a common database. The common database will be made available to the four caucuses by periodically copying the entire common database onto each caucus work site's hard disk. Each caucus has agreed to update its copy of the common database whenever the GIS Director makes additions, corrections, or deletions. These updates must be accepted and used by each caucus, at least until some point toward the end of the process, when the Subcommittee will authorize each caucus to cease accepting updates.
2. Database Elements
a. Minnesota's Census Geography
The State of Minnesota has 87 counties and about 855 cities, 1,743 towns, 4,100 precincts, and 200,000 census blocks. Some counties also include unorganized territory, that is, geographic areas not organized into a town or city and instead governed directly by the county board.
Minnesota has completed both Phase 1 and Phase 2 of the Census Bureau's 2000 Census Redistricting Data Program, so both its blocks (Phase 1) and precincts (Phase 2) should be properly delineated on the file for use in redistricting. Some of the precincts are not "true" precincts. "True" precincts have boundaries that follow "visible, clearly recognizable physical features," as required by Minn. Stat. § 204B.14 , subd. 6. They are shown on census maps exactly as they are used by the political subdivision. The "untrue" precincts do not comply with the law and have had to be adjusted for purposes of the census to follow the visible physical features that appear on the census maps. The boundaries actually used for election purposes in the "untrue" precincts can not be shown on the census maps or used for tabulating census data.
b. Minnesota's Redistricting Geography
Minnesota has eight congressional districts, 67 senate districts, and 134 house districts. The congressional districts bear no special relationship to the legislative districts, but the house districts must be nested within the senate districts, two each.
c. TIGER/Line File
(1) File Size
The Census Bureau's 2000 TIGER/Line file for the State of Minnesota, available in February 2001, contains about 470 megabytes, which requires one CD-ROM disk.
The GIS Office and the State Demographer's Office have each received one copy of the 2000 TIGER/Line file free of charge. The file is available to the public for free download from the Bureau's FTP site: http://www.census.gov/geo/www/tiger/rd_2ktiger/tgr2kweb.html. The Census Bureau is expected to charge members of the public about $60 for a CD-ROM including the entire state.
(3) County, Town, City Boundaries
The 2000 TIGER/Line file contains county, town, and city boundaries as of January 1, 2000. There are 11 cities that do not appear in TIGER. They are cities that historically have depended on their surrounding township for election administration and for that reason have not been separately tracked by the Census Bureau. The GIS Office has assigned each of these cities an unofficial FIPS (federal information processing standard) code and added it to Minnesota's redistricting geography, called "LCC 2000." The cities are: Beardsley, Johnson, and Ortonville in Big Stone County; Calumet, Grand Rapids, La Prairie, Marble, Nashwauk, and Taconite in Itasca County; and Aurora and Kinney in St. Louis County.
Some counties include unorganized territories that have served as election precincts but were not reported to the Census Bureau in time to be included in TIGER. The GIS Office has added them to the LCC 2000 file. They are: Peatland in Kittson County and America/Beltrami Island, Clear River/Oaks, and Jadis in Roseau County. Lake Superior has historically been included as an appendage to one of the towns in St. Louis, Lake, and Cook counties. The GIS Office has made it a separate unorganized territory in each of these counties.
(4) Precinct Boundaries
Each time a city changes a precinct boundary, it must report the change and provide a map showing the new boundaries to the Secretary of State and the State Demographer. Since 1992, the Secretary of State has been processing those changes as they come in and incorporating them into the database kept by the GIS Office. The GIS Office has kept a file showing the precinct boundaries that were in effect for the general election in each of the years 1992, 1994, 1996, 1998, and 2000.
For Phase 2 of the Census, which involved the states providing to the Census Bureau their precinct boundaries, the GIS Office provided all the precinct changes processed by the Secretary of State through the fall of 1999. Those precinct boundaries are what are shown in the 2000 TIGER/Line file.
Precinct boundaries in Minnesota were "frozen" as of January 1, 2000, so the precinct boundaries shown in TIGER are close to those actually used in the 2000 election. However, an existing precinct may be divided and some precinct boundaries "float" with the city boundary when territory is annexed. Where a city has changed its precinct boundaries after those processed by the Secretary of State in the fall of 1999, or as a result of annexations between January 1 and November 7, 2000, the boundaries shown in TIGER don't tie to the precincts used in the 2000 election.
After the election, the Secretary of State and the GIS Office created a new file that shows the precinct boundaries actually used within each city. The LCC 2000 boundaries do not reflect any annexations after January 1, 2000, but they do recognize that St. Augusta Township in Stearns County has become the City of St. Augusta, and that Forest Lake Township in Washington County has become a part of the City of Forest Lake.
Some of the precincts used in the 2000 election consist of a city that crosses a county boundary or a combination of cities, townships and unorganized territories that share a combined polling place. Minn. Stat. § 204B.14, subd. 2, permits the use of a combined polling place but requires each town and each statutory city to constitute at least one election precinct with a separate ballot box at the combined polling place.
The redistricting software requires that the geographic units used to build plans be nested into a clean hierarchy. It will not tolerate precincts that span more than one county, city, town, or unorganized territory. The GIS Office has assigned a separate precinct number to each of the Minor Civil Divisions (cities, towns, and unorganized territories) that make up these "multiple-MCD" precincts.
A list of all the new LCC 2000 precincts added to TIGER 2000 is shown in appendix A. A list of all the new LCC 2000 precincts that did not appear in the Secretary of State's election results for the November 7, 2000, general election is shown in appendix B.
The census block was the lowest level at which population data was collected and tabulated for the 1990 census. That will remain true for the 2000 census, but the boundaries and names of those blocks will change. The 1990 block boundaries were physical features, such as streets, highways, rivers, lakes, pipelines, and power lines; and political boundaries, such as counties, cities, and towns. During the last decade, new streets and highways have been built and city and town boundaries have moved as a result of incorporations and annexations. Thus, a new set of blocks was needed for the 2000 census.
Census blocks in 1990 were numbered with three digits. Where the Census Bureau discovered, as part of collecting census counts, that blocks needed to be split, the Bureau added an alphabetic suffix after the third digit of the block number. For 2000, the Census Bureau has adopted a new block numbering scheme consisting of four digits and no alphabetic suffix. Every 2000 block will have a different number from the one it had in 1990. Furthermore, rather than using a suffix to show which block boundaries change between the collection phase (2000) and the tabulation phase (2001), the Bureau has decided to renumber all the blocks. So, we did not know either the block boundaries or the block numbers for the 2001 population counts until about a month before the counts were to arrive. The Census Bureau will provide comparability files to show how the 2000 blocks relate to the 1990 blocks: one to one, one to many, many to one, or many to many.
(6) Streets and Addresses
The streets shown in the 1990 TIGER/Line file were primarily based on aerial photographs taken in 1984-86. For the 2000 census, the Census Bureau has worked to improve its Master Address File ("MAF") showing every housing unit and its street address. The first step was to augment its 1990 census address list with street addresses from the U.S. Postal Service's "delivery sequence file," which is based on "ZIP+4" carrier routes. Where street addresses in the Postal Service's file appeared in locations where TIGER had no streets, the Census Bureau obtained maps of the area and added the streets. In rural areas, where the Postal Service's file showed only a rural route and box number, rather than a street address, the Census Bureau hired local staff to travel the area, locate each housing unit, record its physical location, and "spot" the location on a census map. Again, where the street was missing, the Bureau drew it in.
After the 1990 census, local and tribal government officials had expressed concern about the completeness of the 1990 census and their belief that they had address information available that would make the census address list more accurate. In 1994, Congress passed the Census Address List Improvement Act, Pub. L. No. 103-430 , which directed the Census Bureau to provide an opportunity for local governments to review the census address list for accuracy and completeness before it was used to deliver the 2000 census questionnaires. The Census Bureau invited local and tribal governments to review census maps and compare address information they maintain to the Census Bureau's address list and to make additions, corrections or deletions to the Census Bureau's address list and identify missing units. This Local Update of Census Addresses (LUCA) program took place in 1998 and 1999. As a result, the streets in the 1999 TIGER/Line File should be up to date as of that time.
The Census Bureau continued to accept updates from the U.S. Postal Service, from its own census enumerators, and from local governments showing new streets constructed and new housing units occupied up to Census Day, April 1, 2000. The 2000 Redistricting TIGER/Line file, available in February 2001, has streets and addresses up to 1999. The final census address ranges, up to Census Day, will follow in a separate release of TIGER 2000 between April and June of 2001.
d. Congressional District Boundaries
The GIS Office has added current congressional district boundaries to the redistricting database.
The congressional district boundaries shown in TIGER 2000 contained a series of small errors, primarily along Interstate 494 through Richfield, Fort Snelling, Mendota Heights, and Eagan, where the boundary followed the highway instead of the city boundaries. The GIS Office has corrected those errors, so that the congressional boundary is coterminous with the city and precinct boundaries. The cities of Little Falls, Rockford, and Farmington have annexed territory in the adjacent congressional district, without creating a separate precinct for the new territory. Thus, the congressional boundary has floated along with the city boundary. The LCC 2000 file recognizes this float and thus differs from TIGER 2000. The blocks affected by these changes are shown in appendix C.
e. Legislative District Boundaries
The GIS Office has added current legislative district boundaries to the redistricting database.
Where a city boundary is an invisible line that has also been a legislative district boundary during the past decade, and the city has annexed territory so that its invisible boundary has moved, the precinct boundary for the legislative district has moved along with it and the old boundary is not included in TIGER 2000. This has occurred in the cities of Annandale, Baxter, Brainerd, Buffalo, Dillworth, Farmington, Fergus Falls, Granite Falls, Hastings, Hutchinson, Jordan, Lake Crystal, Lake Elmo, Le Sueur, Mankato, Melrose, Moorhead, Mountain Iron, New Prague, New Ulm, Northfield, Pierz, Pillager, Pine City, Red Wing, Rochester, Saint James, Sartell, Sauk Rapids, Tower, Wadena, Wanamingo, and Winona.
f. Pub. L. 94-171 Population Data
The Pub. L. 94-171 population data will contain about 90 megabytes. It will be delivered by the Census Bureau to the GIS Office by CD-ROM sometime before the legal deadline of April 1, 2001. Almost immediately, the file will also be available to the public for free download from the Census Bureau's FTP site and on CD-ROM for about $60.
(2) Two Population Counts
For the 2000 census, there has been a fight between the President and Congress over whether to use scientific sampling techniques to conduct the census. The Census Bureau proposed that, in order to obtain information on at least 90 percent of the households in each census tract, it would use statistical sampling techniques to estimate the characteristics of the households that did not respond to the first two mailings of a census questionnaire. In each census tract, the fewer households that responded initially, the larger would be the size of the sample enumerators would contact directly as part of their follow-up. The addresses that would be included in the sample would be scientifically chosen at random to insure they were statistically representative of all nonresponding housing units in that census tract. The total population for each census block would be extrapolated from the head count to an adjusted count based on the sample.
Congress attempted to stop the use of sampling by enacting Pub. L. No. 105-119 , § 209 (j), 111 Stat. 2480 (1997), which required that all data releases for the 2000 census show "the number of persons enumerated without using statistical methods." It also authorized lawsuits to determine whether the Bureau's plan to use sampling for apportioning seats in Congress was constitutional.
In Department of Commerce v. U.S. House of Representatives, 525 U.S. 316 (1999), the Supreme Court ruled that the Census Act prohibits the use of sampling for purposes of apportioning representatives in Congress among the states. It did not rule on the constitutionality of using sampling to determine the distribution of population within each state for purposes of redistricting its apportionment of congressional seats or the seats in its state legislature.
Following the Supreme Court's decision, the Census Bureau announced its plan to use statistical sampling methods to conduct a postenumeration survey called the "Accuracy and Coverage Evaluation." As of February 1, 2001, the Bureau was planning to publish the census counts derived from sampling along with the head counts mandated by Pub. L. No. 105-119 . In other words, each state would receive two sets of census counts for each area within the state and would have to make its own decision which count to use for each area. Minnesota's redistricting database is designed to accommodate both sets of data.
(3) Racial Data
Both sets of data will include information on race and Spanish heritage. The five main race categories are American Indian or Alaska Native, Asian, Black or African American, Native Hawaiian or Pacific Islander, and White. In accordance with OMB Bulletin No. 00-02 (Mar. 9, 2000), the redistricting database will tabulate individuals who reported more than one race using the following combinations: American Indian or Alaska Native and White, Asian and White, Black or African American and White, American Indian or Alaska Native and Black or African American, any other combination of races that totals more than one percent of the population, and the balance of individuals reporting more than one race.
To provide further guidance to states and local governments that must submit their redistricting plans for preclearance before they may take effect, the U.S. Department of Justice on January 18, 2001, issued a notice called "Guidance Concerning Redistricting and Retrogression Under Section 5 of the Voting Rights Act, 42 U.S.C. 1973c." 66 Fed. Reg. 5412 . The guidance says that, in most of the usual cases, the Department will analyze only eight categories of race data:
Non-Hispanic Black plus Non-Hispanic Black and White
Non-Hispanic Asian plus Non-Hispanic Asian and White
Non-Hispanic American Indian plus Non-Hispanic American Indian and White
Non-Hispanic Pacific Islander plus Non-Hispanic Pacific Islander and White
Non-Hispanic Some other race
Non-Hispanic Other multiple-race (where more than one minority race is listed)
The total of these racial groups will add to 100 percent. Where there is an unusual number of people checking multiple race categories, some additional categories may be needed. There may be circumstances in which the total population by race is important, but most redistricting decisions that consider race will be based on the voting age population, that is, persons age 18 and over.
The Subcommittee's redistricting system will include all 504 categories of racial and Spanish heritage data, actual and adjusted. A user will be able to select the combinations of data desired and to display that data on a map using numbers, thematic shading, or pie charts. The user will also be able to generate reports showing population counts by race for any of the categories or combinations of categories, such as those required by the Justice Department.
g. Election Data
The election database includes statewide, congressional, and legislative races for the 1992, 1994, 1996, 1998, and 2000 elections. For each of those races, it shows the votes for the DFL candidate, the Republican candidate, other major party candidates, and the total votes for "other" candidates. It also shows the number of persons voting at each of those five elections.
Election data for the years 1992 through 2000 is kept at the precinct level. Once the block-level population counts are added to the database in April of 2001, the election data for each precinct for each year will be allocated to the blocks that were in that precinct during that election year in proportion to the voting age population in those blocks. The voting age population for each year will be interpolated between the actual count for 1990 and the actual count for 2000, so that the count for 1994 will be 40 percent of the difference between 1990 and 2000, the count for 1996 will be 60 percent of the difference, and the count for 1998 will be 80 percent of the difference.
h. Income and Housing Data
Sometime in the fall or winter of 2002, the Census Bureau will deliver to the states income and housing data from the 2000 census. These data will be taken from both the short form filled out by every household and the long form filled out by one household in six. They will include data about the income and housing of each census tract, but not at the block level. Since these data will not arrive in time to be used for redistricting, the redistricting database will include only income and housing data from the 1990 census. Because the data is so old, and was gathered only at the tract level, it will not be allocated to blocks. It will be possible to overlay this data on a map showing current block and district boundaries, but not to calculate income or housing indices for new districts as they are being drawn.
i. Incumbent's Residences
The residence of each incumbent was added to the redistricting database following the 2000 election. This will permit the redistricting software to warn the user when incumbents have been paired in creating a district and to compare the impact of different redistricting plans on each incumbent by comparing the districts to which the incumbent has been assigned in the different plans.
j. Other Data
Maptitude for Redistricting will allow users to add other data about census units to the database. When users wish to use other data, these data files can be joined by a common field, such as a unique precinct number or census block number. To join data, a user will select the file to be joined and the field to be used by the join process. Then, the user will select the map file it will be joined to and the corresponding field it will use for the join. Once a join is complete, any field in the joined data file can be used for mapping and reporting.
The software will enable the user who adds the data to designate the users to whom it will be available. The database will be flexible enough to permit adding these data after the rest of the database is complete. The Subcommittee assumes that most of this data will be added by caucus staff for the confidential use of the caucus.
D. Redistricting Software
The redistricting software will display the census geography, taken from the 2000 TIGER/Line file, along with roads, streets, lakes, rivers, and other physical features included in the TIGER/Line file, as well as the feature and political subdivision names. The display will include a pop-up legend-menu that permits the user to select which boundaries, political subdivision names, physical features, and feature names to display at each level of resolution, i.e., county names when viewing the whole state and street names when viewing census blocks. The user will choose whether to display icons showing the residences of incumbents.
The software will be capable of showing census geography at the county, city and town (MCD), precinct (VTD), or block level, and moving quickly up or down among these levels.
The software will be capable of starting with a wide area, perhaps several counties, then zooming in on selected cities, towns, precincts, or blocks, and then zooming back out to a wider area. It will be capable of panning to adjacent areas in any direction.
Once a user has begun to create districts for a plan, the software will be capable of showing in a scrolling window statistics for both the district currently being worked on and all the other districts previously created.
The software will permit the use of color coding to show the districts to which census units have been assigned in the plan. The colors will fill each district on the bottom layer, with lines and text above, so that the boundaries, physical features, and population and election attributes within the district may still be seen.
The software will also permit the new district boundaries to be shown only as a line, in order to permit the display of pie charts and thematic shading within the district.
b. Population and Election Attributes
The redistricting software will enable the user to see the population and other attributes of the census units in the area being worked on. The user will be able to display these attributes on the monitor directly on the map of the area.
On the map, the user will be able to display attributes of the census unit, such as total population, minority population, and partisan index, in absolute or percentage terms, in a scrolling window. The user will be able to select the attributes to be displayed as labels on the map from an attribute menu listing all the population, election, and other attributes in the database.
On the map, the user will be able to show by color coding or shading how census units or districts compare to each other on the basis of any attribute selected from the attribute menu, such as total population, Black population, or partisan index. The colors will be on the bottom layer, with lines and text above. The user will be able to easily select the gradients to be used for color shading.
In a pop-up window for the census unit on which the cursor rests, the user will be able to display all the population and election attributes of that census unit that are on the attribute menu.
In a scrollable window for the plan currently being worked on, the user will be able to display attributes for all the districts so far created. The default attributes will be:
- Total population
- Deviation from the ideal - absolute
The user will be able to select the attributes to be displayed by selecting from the attribute menu.
A partisan index may be calculated from a limited number of races, chosen by the user when beginning a plan. The user will be able to change the index while working on a plan.
Windows will show:
- The districts currently being worked on, as selected by the user
- A sub-area of census units the user is considering for addition to or subtraction from one of those districts
- The hypothetical district that would result if the sub-area were added to or subtracted from the district
All attributes displayed on the map or in a window will be refreshed immediately as units are assigned, reassigned, or unassigned to districts.
The user will be able to control the portion of the screen that is used for the map and for each of the attribute windows, so that these can be changed as the user's needs and expertise change.
The redistricting software will allow the user to create congressional and legislative districts by assigning census units to appropriate districts. The software will be capable of assigning several levels of geography in the same plan. For example, the software will make it possible to begin assignment at the county level, then go down to the precinct or block level, and then revert to the county level, moving swiftly from level to level. The software will be capable of assigning whole counties, cities, towns, and unorganized territory to new districts, without specifying the precincts or blocks within them. The software will be capable of assigning whole precincts to new districts, but will also be capable of splitting precincts and assigning population to new districts block by block. It will be capable of making assignments either unit by unit or by lassoing groups of census units.
Districts will be numbered by the user as they are created. The user will be able to assign any number appropriate for the type of plan being created (Congressional, Senate, House), so long as it does not duplicate one already assigned in that plan. The user will be able to change the number of a district already created.
The software will check to make sure that no whole census unit is assigned to more than one district, and that, when a plan is completed, no units have been left unassigned.
The software will check to make sure that units assigned to a district are contiguous to other units already assigned to the district.
To assist in preserving the cores of prior districts, the software will permit the user to "freeze" census units that have been assigned to a district so that they cannot be reassigned to another district unless the user confirms the desire to do so.
To avoid contests between incumbents, the software will show the user when more than one incumbent is included in a district.
The software will permit the boundaries of districts in one plan to be compared with the boundaries of districts in another plan by showing the boundaries of a second plan as an overlay on a map showing the boundaries of the first plan. When two plans are compared in this way, the user will also be able to display the icons showing the blocks where incumbents reside.
The software will be capable of creating plans that cover only part of the state and merging them to form a plan for the whole state, as well as creating plans for the whole state at once. The software will be capable of saving plans for modification at a later date.
The software will permit the user to create house districts that are nested within senate districts. It will permit the Senate to create senate district "1" and then divide it into two house districts, numbered "1A" and "1B." It will permit the House to create house districts, number them as "1A" and "1B," and then combine them into senate district "1."
The software will be able to import plans drawn on other systems that use census geography. That is, it will be capable of reading an equivalency file that contains a tabular listing of census units in each district and using that equivalency file to create a plan that the system can display, edit, and produce maps and reports describing it.
The software will be able to export a plan in the form of an ASCII equivalency file that can be read by any of the common redistricting software applications.
The software will produce maps of the districts created. It will be capable of showing in printed form all of the information that can be displayed on the monitor, so that there can be a complete correspondence between what is on the display, what is shown in the report, and what is shown on the map. It will be able to scale the maps to print on a plotter size "A " to "E," as appropriate for the area to be displayed.
The maps will show, not only the district boundaries, but the other political boundaries and major physical features in the area, with their names properly located so that the reader can clearly see the political boundary or visible physical feature that the district line runs along. The maps will also show the names of at least the largest whole census units included in each district.
The software will be able to produce maps with color shading for the various districts and defined colors for various physical features, such as blue for water and red for major roads. The color shading will be on the bottom layer, with lines and text above.
The software will also be able to produce maps with color shading to show various kinds of statistical data about the census units and redrawn districts, such as degrees of population inequality, racial characteristics, and voting behavior. The color shading will be on the bottom layer, with lines and text above.
(1) State Map
Both congressional and legislative plans will have a map of the state, showing county, city, and town names and boundaries, the largest bodies of water and their names, and interstate highways and their numbers.
(2) Metropolitan Area Maps
Both congressional and legislative plans will have a map of the seven-county metropolitan area, showing county, city, and town boundaries and names, and major highways and bodies of water and their names. Legislative plans will also have a map of each of the other standard statistical metropolitan areas within the state, i.e. Duluth, Mankato, Moorhead, Rochester, and St. Cloud.
Both congressional and legislative plans will have a map of the inner metropolitan area, showing city streets and their names, in addition to the information on the seven-county map.
(3) County Maps
For either congressional or legislative plans that split county boundaries, there will be a map of the county, showing city and town names and boundaries, major highways, and major bodies of water and their names.
(4) City Maps
For either congressional or legislative plans that split city or town boundaries, there will be a map of the city, showing city streets and highways and major bodies of water and their names.
(5) District Maps
When a user is building a plan, the user will be able to print a hard copy of the map on the screen and a larger map that shows a particular district and its adjacent territory.
(6) Outline Maps
To assist in drafting legal descriptions of districts that split cities, either outside or within the metropolitan area, the mapping software will be capable of drawing outline maps that show the boundaries and the names of the physical features that form the boundary where the district splits a city.
c. Map Identifier
The software will include a banner or label to identify the operator who requested the map and the date and time it was printed.
a. Screen Prints
The software will make it possible to print in a report the same information on the population and voting characteristics of each district as is shown on the monitor's display.
b. Standard Reports
The software will produce printed reports showing the population and voting characteristics and the degree of population inequality of each district and of the plan as a whole.
For a plan, one standard report will be a summary listing only the name of each district, its total population, its absolute deviation from the ideal, its percentage deviation from the ideal (carried out to two decimal places), the absolute overall range of the plan, and the percentage overall range of the plan (carried out to two decimal places).
The user will be able to create custom reports to show additional summary data on each district. The customization will be by adding more columns of data for each district, the data to be selected from the menu of population and election attributes. To facilitate printing many columns of data, the custom reports may be printed in landscape mode.
A second standard report for a plan will be a tabular listing of the census units that make up each district, showing their name (and number, if appropriate) and total population. Only the largest whole census units in each district will be listed. That is, if all of a county is in a district, the cities and towns within it will not be listed; if all of a city is in a district, the precincts within it will not be listed; and so on.
A third standard report will show the minority population and minority voting age population of each district, both absolute and percentage.
A fourth standard report will show the number of times that counties, cities, towns, and precincts are split by the plan and list the districts to which the various parts of each county, city, town, or precinct were assigned.
A fifth standard report will list the district to which each incumbent member has been assigned, showing the districts where incumbents are paired and the districts that are open and the total pairs and open seats.
A sixth standard report will show how each of the districts and the plan as a whole score on various measures of compactness, including the Reock test and the Polsby-Popper test (comparing the area of a district with the area of the smallest circle that can encompass it), the Schwartzberg test (comparing the perimeter of a district with the circumference of the smallest circle that can encompass it), the perimeter test (the total length of the perimeters of all the districts), the population-polygon test, and the population-circle test.
c. Special Reports
The software will be capable of producing additional reports, as defined by the user, based on any of the data in the database and plans created.
d. Report Identifier
The software will print a banner or label that identifies the operator who requested the report and the date and time it was run.
E. Electronic Distribution of Plans
1. Privately Within a Caucus
Each caucus will have an intranet site to which only authorized caucus members and staff will have access. Security will identify a user by IP address and password. A plan posted on the site will not be simply a static image but rather a graphical and statistical database that can be queried but not changed. A user will be able to view the entire state or zoom down to the block level, seeing geographical features and their names, querying data attributes for census units and districts, and viewing standard reports, just as when creating a plan
2. Publicly in Committee and on the Floor
When a plan is ready for publication at a committee meeting or on the floor, it will be posted on the GIS Office web site. The posting procedure is explained in a separate document . The Subcommittee assumes that the 2001 Legislature will require that all plans considered by a committee or on the floor use the same geographic areas and population counts as in the Subcommittee's redistricting database, so that this posting of plans may be facilitated. A plan posted on the web will be open for inspection using the same tools as were available when the plan was created or when it was posted on its caucus intranet site.
3. After Enactment
When a plan has been enacted it will remain posted on the GIS Office web site and be made available for FTP download from the site. The GIS Office will also post the plan on the Minnesota Geographic Data Clearinghouse web site. The GIS Office will provide an equivalency file of the plan to the Land Management Information Center for sale to the public on CD-ROM or in other formats.
F. Operation, Maintenance, and Support
One set of documentation for the database management and network software will be provided. Six complete sets of documentation for the redistricting software will be provided.
The software vendor will provide training for the GIS Director in how to operate and maintain the system, and up to eight caucus staff and two staff each from Minnesota Planning and the Office of the Secretary of State in how to use the system to draw redistricting plans and produce maps and reports describing the plans.
3. Help Line
The software vendor will provide telephone software support to answer user questions during normal business hours.
Hardware vendors will provide telephone support to answer user questions, generally on the same terms as the software telephone support.
4. Hardware Maintenance
In addition to telephone support, hardware vendors will make on-site service available with a response time of no more than four hours for most equipment.
A combination of warranties and service agreements will insure continued operation of the system through June 30, 2002.
6. System Administration
Once the caucus staff have begun drawing plans, the GIS Director and Assistant Director will be on call to backup the system regularly and solve problems as they arise.
III. Use of System
The computerized redistricting system will be used by the Minnesota Legislature to draw redistricting plans and to make copies of the plans available to the state and local officials who must implement them. Use of each caucus work site is under the control of that caucus. The GIS Director's work site is for the exclusive use of the GIS Director to maintain the system, not to draw plans.
The system may also be used by a three-judge state or federal court to draw redistricting plans. The system will not be made available to anyone else for their use in redistricting.
The Subcommittee reserves the right to make the database available to political subdivisions for their use, but will not allow the system software to be copied or used anywhere other than at the work sites described in this document.
The system will be retained by the Legislature and used for other geographic data analysis after June 30, 2002.