Minnesota Redistricting System
February 15, 2011
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 moved 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 continued to be the primary software for day-to-day GIS operations and were used to print maps and post plans to the World Wide Web, but the redistricting was done using Maptitude for Redistricting 4.5 from Caliper Corporation. The redistricting hardware and software changed, but the functionality of the system used to draw plans was essentially the same as during the 1990s.
For redistricting after the 2010 census, the system will use personal computers running Windows 7. Maptitude for Redistricting 6.0 will be used to draw plans and print maps and reports at the caucus workstations. Plan maps and reports submitted to the GIS Office for publication will be printed using ESRI’s ARC/GIS and posted to the Web using MapServer on a PostgreSQL/PostGIS database server.
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 server functions as the file server for the redistricting network.
2. Workstations and Peripherals
Each work site is equipped with a personal computer. Each PC has dual central processors with speeds of at least 2.8 GHz and 8 GB of RAM. It has a re-writable DVD drive, and a 500 GB external hard drive. It has a high-speed connection to the Internet. It has a 27” 2560 x 1440 high resolution monitor. Each work site include an Epson 84 video projector and screen to facilitate small-group participation in drawing plans.
3. File and Map Storage
Each work site has at least 500 gigabytes of hard disk storage capacity, consisting of dual 250 GB RAID/mirrored drives. This will be sufficient to store a complete copy of the geographic, population, and election database and all the plans created there.
4. Output Devices
Each work site has a Canon imagePROGRAF iPF8000S plotter that can plot maps up to 44 inches wide (size “E”) and of any length, either in color or in black and white.
Each work site has a Hewlett Packard Color LaserJet CP6015x printer to print size "A" (8-1/2" x 11") to “B” (11” x 17”) maps and - reports.
5. Copies of Maps
Both the “A”and “B”-size and 44" plotters can print multiple copies of maps, but will take awhile.
The system provides a 500 GB external hard drive for each workstation. Each caucus may consider maintaining a copy of its backup off site.
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 the Legislature’s 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 caucus work sites will use either the Senate or the House electronic mail software, as appropriate.
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.
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 Director will notify the caucuses when the common database is ready, and the caucuses will download it from the GIS Office map server to their hard drives. 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.
2. Database Elements
a. Minnesota’s Census Geography
The State of Minnesota has 87 counties and about 857 cities, 1,785 towns, 4,140 precincts, and 259,777 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, of which there are about 68.
Minnesota has completed both Phase 1 and Phase 2 of the Census Bureau’s 2010 Census Redistricting Data Program, so both its legislative districts (Phase 1) and blocks and precincts (Phase 2) should be properly delineated on the file for use in redistricting.
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 2010 TIGER/Line file of blocks, precincts, cities and towns, and counties for the State of Minnesota, available in January 2011, contains about 450 megabytes.
The GIS Office and the State Demographer’s Office have each received a copy of the 2010 TIGER/Line file on DVD. The file is available to the public for free download from the Bureau’s Web site:
(3) County, Town, City Boundaries
The 2010 TIGER/Line file contains county, town, and city boundaries as of January 1, 2010. There are nine cities that do not appear in TIGER. They are cities that historically depended on their surrounding township for election administration and for that reason have not been separately tracked by the Census Bureau, even after they ceased to be dependent. 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 2010.” The cities are: Beardsley, Johnson, and Ortonville in Big Stone County; Calumet, Marble, Nashwauk, and Taconite in Itasca County; and Aurora and Kinney in St. Louis County.
The counties along Minnesota’s northern border tend to have few people and fewer roads. They have created precincts in unorganized territory along public land survey lines. Before the 2010 census, the Census Bureau refused to recognize these invisible precinct boundaries and instead put the TIGER precinct boundaries along recognizable, visible physical features, such as rivers and lakes. They made the unorganized territory boundaries conform to the precinct boundaries. For the 2010 census, the Census Bureau used GPS units to locate housing units and began to allow the use of public land survey lines for precinct boundaries. Unfortunately, the Bureau did not change the boundaries of the unorganized territories to conform to the newly-recognized precinct boundaries, so the TIGER file contains a large number of erroneous unorganized territories in Lake of the Woods, Koochiching, and Itasca counties. The GIS Office has moved the unorganized territory boundaries to conform to the precinct boundaries and changed the unorganized territory names accordingly. A list of these changes, and the other changes to county subdivision names and numbers described below, is shown in Appendix A.
In Beltrami County, TIGER 2010 has the unorganized territory of Upper Red Lake. The GIS Office has divided it into North Beltrami Unorganized Territory and Lower Red Lake Unorganized Territory, in accordance with the precinct names there.
In Itasca County, TIGER 2010 shows a part of Northeast Itasca Unorganized Territory as Effie Unorganized Territory. The GIS Office has corrected that.
In Lake of the Woods County, TIGER 2010 shows 21 townships that are actually unorganized territory with different boundaries and different names. The GIS Office has corrected that.
In Nicollet County, TIGER 2010 shows a few blocks as part of the City of Le Sueur that the GIS Office has corrected to be part of Lake Prairie Township.
In Scott County, TIGER 2010 shows a few blocks as part of the Credit Lake Township that the GIS Office has corrected to be part of Spring Lake Township.
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 2002, 2004, 2006, 2008, and 2010.
For Phase 2 of the Census, which involved the states providing to the Census Bureau their block and precinct boundaries, the GIS Office provided all the precinct changes processed by the Secretary of State through the fall of 2009. Those precinct boundaries are what are shown in the 2010 TIGER/Line file with the following changes:
In St. Louis County, a precinct was created for Meadowlands City.
In Beltrami County, in the Ponemah/Redby precinct, two blocks were added to the east of Red Lake that follow the Battle River.
Precinct boundaries in Minnesota were “frozen” as of January 1, 2010, so the precinct boundaries shown in TIGER are close to those actually used in the 2010 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 2009, or as a result of annexations between January 1 and November 6, 2010, the boundaries shown in TIGER don’t tie to the precincts used in the 2010 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 2010 boundaries do not reflect any annexations after January 1, 2010.
The census block was the lowest level at which population data was collected and tabulated for the 2000 census. That will remain true for the 2010 census, but the boundaries and names of those blocks will change. The 2000 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 2010 census.
After the census information was collected and it was time to tabulate the results, the Census Bureau changed block boundaries to reflect changes in geography that it discovered during the collection process. Those “collection blocks” will be renumbered as “tabulation blocks” for reporting the population counts. So, we did not know either the block boundaries or the block numbers for the 2011 population counts until January 21, 2011, when the TIGER Files arrived. The Census Bureau will provide comparability files to show how the 2010 blocks relate to the 2000 blocks: one to one, one to many, many to one, or many to many.
(6) Streets and Addresses
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 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 2008 and 2009. As a result, the streets in the 2009 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, 2010. The 2010 Redistricting TIGER/Line file, available in January 2011, has streets and addresses up to 2009. The final census address ranges, up to Census Day, will follow in a separate release of TIGER 2010 between April and June of 2011.
d. Congressional District Boundaries
TIGER 2010 will show the current congressional district boundaries.
e. Legislative District Boundaries
TIGER 2010 will show the current legislative district boundaries.
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 DVD sometime before the legal deadline of April 1, 2011. Almost immediately, the file will also be available to the public for free download from the Census Bureau’s FTP site.
(2) Racial Data
The population 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 252 categories of racial and Spanish heritage data. 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 2002, 2004, 2006, 2008, and 2010 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 2002 through 2010 is kept at the precinct level. Once the block-level population counts are added to the database in March of 2011, 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 2000 and the actual count for 2010, so that the count for 2004 will be 40 percent of the difference between 2000 and 2010, the count for 2006 will be 60 percent of the difference, and the count for 2008 will be 80 percent of the difference.
h. Incumbent’s Residences
The residence of each incumbent was added to the redistricting database following the 2010 election. The GIS Office collected information on each incumbent’s mailing address and geocoded it on a map, sent the map to the incumbent, and asked the incumbent to approve or correct the location on the map. 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.
i. 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 2010 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 a 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. Interactive Reports
An option is available to view the reports using an interactive option. The user can sort values by clicking on any of the columns or view an interactive map by clicking on the district number. These reports are generated using PostgreSQL/PostGIS spatial functions and PHP programming.
E. Electronic Distribution of Plans
1. Privately Within a Caucus
Each caucus work station will have access to a secure folder on the GIS Office redistricting server. 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 Subcommittee assumes that the 2011 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 download from the site.
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 the Department of Administration 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, 2012.
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 state or federal court panel 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, 2012.
Send comments regarding this site to:
Last updated: November 17, 2011