Census 2010 Redistricting Data Program—Phase 2 Supplemental Information for Digital Updates I. General Business Rules A. Definitions 1. TIGER® is the acronym for the Topologically Integrated Geographic Encoding and Referencing System (TIGER®). TIGER® is a computer database that contains a digital representation of all map features (streets, roads, rivers, railroads, lakes, and so forth) required to support Census Bureau operations, the related attributes for each, and the geographic identification codes for all entities used by the Census Bureau to tabulate data for the United States, Puerto Rico, and Island Areas. 2. MAF/TIGER Feature Class Code (MTFCC) is a code intended to classify and describe geographic objects or features. A feature class is a grouping of features in MAF/TIGER that share basic characteristics. A "feature" differs from a "feature class" in that the feature is an instance of the feature class. For example, "Lake" and "Road" are feature classes while "Lake Superior" and "Suitland Road" are features. The first letter of the MTFCC is used to group features into their common feature category. There are eleven generic feature categories. “MTFCC and CFCC Crosswalk - Draft v.1” is a table that shows the relationships between the Census Feature Class Codes (CFCCs in the TIGER/Line® file) and the MTFCC (in the MAF/TIGER data base). 3. BBSP is the acronym for the Block Boundary Suggestion Project. This project gives state participants the ability to suggest qualified features to be held as tabulation block boundaries for the 2010 Census. B. Viewing and Editing 1. Allow users to turn on (view) and turn off (hide) all the linear features in the all lines layer. a. Symbolize the linear features by subtype based on the following groupings. i. Roads 1. MTFCC = S1100 2. MTFCC = S1200 3. MTFCC = S1400 4. MTFCC = S1500, S1630, S1640, S1710, S1720, S1730, S1740, S1750 ii.Hydrography – Linear 1. MTFCC = H3010, H3013, H3020 iii.Railroads 1. MTFCC = R1011, R1051, R1052 2. Allow users to turn on (view) and turn off (hide) all the area landmarks, area hydrography, and point features. 3. Allow users to turn on (view) and turn off (hide) all primary names for features identified in the all lines layer. 4. Allow users to turn on (view) and turn off (hide) all secondary names for features identified in the all lines layer if secondary names have been provided by the Census Bureau. 5. Allow users to import data files for use as a reference when delineating their voting districts or identifying features they want held as 2010 blocks. 6. Provide an "Info" command to select any line segment or feature and identify: a. Feature type b. Feature name c. Entity type (see 7.) d. Names for all entities (see 7.) e. Codes for all entities (see 7.) f. The BBSP status of any line segment i. Planned Census 2010 block boundaries (by using data in the ‘All Lines’ layer in the CBBFLG field, with a legal value of 4.) ii. Ineligible for selection Census 2010 block boundaries (by using data in the ‘All Lines’ layer in the CBBFLG field, with a legal value of 9.) iii. Census 2000 BBSP "must hold" lines which were held as 2000 block boundaries (by using data in the ‘All Lines’ layer in the BBSPFLG field, with a legal value of 1.) iv. Census 2000 BBSP "do not hold" lines which were not held as 2000 block boundaries (by using data in the ‘All Lines’ layer in the BBSPFLG field, with a legal value of 2.) v. Census 2010 BBSP “must hold” lines as designated by the participant (by using data in the ‘All Lines’ layer in the 2010_BBSP field, with a legal value of 1.) vi. Census 2010 BBSP "do not hold" lines as designated by the participant (by using data in the ‘All Lines’ layer in the 2010_BBSP field, with a legal value of 2.) 7. Allow users to turn on (view), turn off (hide) and distinguish between the boundaries and names of the following entities: a. State (and equivalents) b. County (and equivalents) c. County subdivision i. Minor Civil Division ii. Census County Division d. Subbarios e. Incorporated Place f. Census Designated Place g. American Indian reservations and off reservation trust lands h. American Indian tribal subdivisions i. Alaska Native village statistical areas j. Hawaiian home lands k. Alaska Native Regional Corporations l. Congressional District m. State Legislative District upper (SLDU) chamber n. State Legislative District lower (SLDL) chamber o. VTD boundaries (Census 2000) p. School Districts: i. Elementary ii. Secondary iii. Unified q. D class area landmarks i. Military installations ii. State and national parks r. Census tracts (Census 2000) s. Census tabulation blocks (Census 2000) t. Area Hydrography 8. Allow users to: a. Suggest deletions to the following pre-existing lines i. All road features ii. All railroads and spurs iii. All other transportation features iv. All physical features v. All voting district boundaries (Note: These will be coded as P001 along with other non-visible legal and statistical boundaries.) vi. All non-visible feature extension vii. All point-to-point lines viii. All State Legislative District boundary ix. All Congressional District boundary x. All property lines, non-visible boundaries of either public or private lands, e.g., a park boundary xi. All island block definition lines (block area groupings) xii. All hydrography b. Add (and then delete if participant added) the following lines: i. All road features ii. All railroads and spurs iii. All other transportation features iv. All physical features v. All voting district boundaries (Note: These will be coded as P001 along with other non-visible legal and statistical boundaries.) vi. All non-visible feature extension vii. All point-to-point lines viii. All State Legislative District boundary ix. All Congressional District boundary x. All property lines, non-visible boundaries of either public or private lands, e.g., a park boundary xi. All island block definition lines (block area groupings) xii. All hydrography c. Suggest edits (rename or add) to the names of pre-existing features. d. Edit (rename or add) names to features participants have newly added themselves. e. Force users to either provide a description for all added features or to select from a list of existing MTFCCs. f. Edit Area and Point Landmarks i. If the participant edits Area Landmarks they must be able to select the following change types: 1. Boundary Correction (add area) 2. Boundary Correction (remove area) 3. New Landmark 4. Deletion or De-annexation 5. Change Name ii. If the participant edits Point Landmarks they must be able to select the following change types: 1. New Landmark 2. Deletion 3. Change Name iii. If a participant selects to change the name or add a new area or point landmark, a name must be entered into the fullname field. iv. The participant must be able to add a new area or point landmark by selecting New Landmark and selecting the faces or adding points. v. The participant must be able to delete an area or point landmark by selecting Deletion or De-annexation (area landmarks) or Deletion (point landmarks). vi. The corresponding change type code must be populated in the chng_type field of the table. vii. For area landmarks, Boundary Correction (add area) and Boundary Correction (remove area) polygons, populate the chng_type field with ‘B’. Populate the Relate field in the shapefile with ‘In’ if Boundary Correction (add area) is chosen or with ‘Out’ if Boundary Correction (remove area) is chosen. viii. The participant must have the same update functionality for these change types as it does with other layers. ix. Area hydrography can be edited in the same manner as area landmarks (including same chng_types). g. Coding Explanations for Area and Point Landmarks Type of Change for Area Landmarks / Hydrography Areas Code Explanation B Boundary Correction D Deletion or Deannexation E New Landmark G Change Name Type of Changes for Point Landmarks Code Explanation D Deletion E New Landmark G Change Name C. Topology 1. The participant can perform only those actions that will enforce the basic rules of topology in order to ensure that coincident features remain coincident. 2. All topological requirements are met before the participant delivers the updated file to the U.S. Census Bureau. II. VTD Update module: A. Initial View 1. Begin with display at the state level. 2. Allow the user to view the state-level layers. B. VTD Business Rules 1. Instruct users to delineate their VTDs before making 2010 block suggestions. 2. Throughout the software order any reference to this program as VTD/BBSP. 3. Allow users to work on one county at a time, but view adjacent counties if needed including any updates they may have already made. 4. Give users the option to use their Census 2000 VTDs as the basis for their 2010 VTDs or to create a completely new set and start their 2010 VTDs from a blank slate. a. Provide the option for the VTDs to be displayed with a shaded color fill, where no like colored districts are touching, or as a uniquely outlined polygon layer. b. Show all features regardless of which district display method is chosen. 5. Allow users to import an external GIS file. 6. Allow users to export a file from the application containing the newly defined VTDs in a shapefile format. 7. Allow users to assign or change a VTD code. VTD codes are text and no longer than 6 characters. 8. Allow users to assign or change a name that is alphanumeric and no longer than 100 characters. This name is optional. 9. Allow the user to classify the VTDs as “actual” or as “pseudo”. This should be stored in the VTDI field as an A or a P. The default value for this should be “pseudo” or P. 10.Allow users to define a VTD boundary by several methods, these changes should be tracked through the use of change polygons. (see the returned requirements section for change types and dependent attributes) a. By selecting one or more polygons b. By drawing a line (fence or lasso method) around polygons to be included in the VTD, or c. By selecting some other existing entity 11.Provide a VTD review session before any county can be considered complete. In this session: a. Alert user if a VTD polygon is not closed. b. Alert the user if there is any area within the county not assigned to a VTD. Allow the user to view and assign the undefined area. Instruct the user that any area left not assigned to a VTD will be automatically given an unassigned area code by the U.S. Census Bureau. c. Alert the user if there are any discontiguous VTDs within a county. Allow the user to “fix” this situation by one of the following actions: i. correct the VTD to make it contiguous, or ii. renumber the VTD, or iii. select an option to flag the VTD as having one or more valid discontiguous pieces. This will allow the file to be submitted with a discontiguous VTD. 12.Allow the users to set relationship combinations for a selected VTD as: (These relationships are not required to be validations, they are for our informational purposes.) a. Completely Contains one of these entities: county, county subdivision, incorporated place, or American Indian reservation. b. Wholly Within one of these entities: county, county subdivision, incorporated place, or American Indian reservation. c. Coextensive with one of these entities: county, county subdivision, incorporated place, or American Indian reservation. Completely Contains = CC Wholly Within =WW Coextensive = CO Other = O d. The relationship information will be stored in specific fields. i. The relationship types will be stored in the RELTYPE1, RELTYPE2, RELTYPE3, RELTYPE4, and RELTYPE5 fields of the returned shapefile. ii. The related entity will be stored in the corresponding REL_ENT1, REL_ENT2, REL_ENT3, REL_ENT4, and REL_ENT5 fields by the unique FIPS code for that entity. iii. The user should have the ability to enter a relationship description in a text box for further explanation or for complex relationships. This field should be required when they have chosen a relationship of OTHER. This information should be stored in the RELATE field. iv. The relationship type of OTHER should only be allowed for one of the REL_ENTx fields for any VTD. v. If a the user has more than 5 relationships for a single VTD they should be stored in the RELATE text field using the CC, WW, CO, O codes followed by all entities that fall under that code. (e.g. CC place 54509, 67890 WW mcd 48756) 13.Identifies, and prompts users to review, all newly added line segments that are within 10 meters of one of the following existing line/boundary features (for both connected and disconnected lines.) a. county or equivalent area b. MCD c. incorporated place d. state legislative district e. congressional district f. school district g. military/park boundary h. roads i. hydrography (streams and area water bodies) 14.Identifies, and prompts users to review, all newly added line segments that repeatedly cross an existing line/boundary features (for both connected and disconnected lines.) 15.Allow users to view address ranges associated with street features. 16.Allow users to generate an inventory file, in .dbf format, for all current VTD codes with associated names by county and also by state. Allows the user to access this log file interactively or print for review. 17.VTD boundaries that are not any other type of feature will and should be coded as P0001s. These are non-visible linear legal/statistical boundaries. Many non-visible legal and statistical boundaries will be held. That said, if the participant selects an MTFCC of P0001 on a participant added line then that line should also be coded with a 4 in the CBBFLG field. If the participant changes the MTFCC of an existing line to P0001 then that line should also be coded with a 4 in the CBBFLG field. 18.Allow for session to be saved and re-opened. III. BBSP Updates module: A. Initial View 1. Begin with display at the state level. 2. Allow the user to view the state-level layers. 3. Instructs users to invoke a BBSP module after completion of their VTD work. 4. Provide the ability to turn on (view), highlight, and turn off (hide) line segments based on their BBSP status: a. Planned Census 2010 block boundaries (by using data in the ‘All Lines’ layer in the CBBFLG field, with a legal value of 4.) b. Ineligible for selection Census 2010 block boundaries (by using data in the ‘All Lines’ layer in the CBBFLG field, with a legal value of 9.) c. Census 2000 BBSP "must hold" lines which were held as 2000 block boundaries (by using data in the ‘All Lines’ layer in the BBSPFLG field, with a legal value of 1.) d. Census 2000 BBSP "do not hold" lines which were not held as 2000 block boundaries (by using data in the ‘All Lines’ layer in the BBSPFLG field, with a legal value of 2.) e. Census 2010 BBSP “must hold” lines as designated by the participant (by using data in the ‘All Lines’ layer in the 2010_BBSP field, with a legal value of 1.) f. Census 2010 BBSP "do not hold" lines as designated by the participant (by using data in the ‘All Lines’ layer in the 2010_BBSP field, with a legal value of 2.) 5. Allows users to display their Census 2000 feature extensions. These can be identified by displaying the lines from the all lines layer that have an MTFCC of P0001 AND a BBSPFLG legal value of 1. B. BBSP Business Rules 1. 2010 BBSP selections a. Allow users to select by a segment or "chain" of lines for applying 2010 BBSP “must hold” suggestions. These suggestions are recorded as ‘1’s in the 2010_BBSP field of the returned shapefile. b. Allow users to select by a segment or "chain" of lines for applying 2010 BBSP “do not hold" suggestions. These suggestions are recorded as ‘2’s in the 2010_BBSP field of the returned shapefile. c. Alert the user when an ineligible line (CBBFLG = 9) segment has been selected for a 2010 BBSP "must hold" and inform the user the line will not become a must hold unless current imagery can be supplied verifying the line as a valid feature. d. Allow for the user to provide the supporting imagery or a direct reference to a publicly accessible source of imagery when current imagery is required. e. Alert the user when a segment "planned" to be a 2010 block boundary has been selected for a "do not hold" and inform the user this line will not become a “do not hold” segment. f. Upon completion of their suggestions or on demand, alert the user and identify the segments when the selected segments for 2010 BBSP "must holds" do not form a polygon with planned and/or legal "must hold" segments. Inform the user that all must hold segments are required to form a closed polygon. 2. Feature Extensions a. Prompt users to review the Census 2000 feature extensions: b. Allow users to create new feature extensions, identifying their length in feet as the line is added. (Guidelines will recommend only up to 300 foot extensions.) c. Assign a code to the new feature extensions of MTFCC of P0004. 3. Block Area Grouping (BAG) a. Allow users to create a polygon surrounding selected individual islands for grouping into a single Census 2010 tabulation block. These island groupings will be referred to as a block area grouping (BAG). b. Uniquely identifies, within county, each Census 2010 block area grouping by assigning an MTFCC of G5035 to the polygon and a BAGCE number starting at 001 and incrementing by one for each BAG created. c. Allows user to turn on (view), highlight, and turn off (hide) all BAGs. d. Prevents BAGs from overlapping. e. The BAG perimeter can only be created over water features. No land area can be split by the BAG perimeter. 4. General Rules a. Allow users to export a file from the application containing the newly defined BBSP line segments in industry standard formats. b. Prompt the user to verify that BBSP suggestions for highlighted "must hold" and "do not hold" features are correct before county submission. c. Allow for sessions to be saved and re-opened. IV. SLD and CD updates module A. Initial View 1. Begin with display at the state level. 2. Allow the user to view the state-level layers. B. SLD and CD Business Rules 1. Give users the option to use their current SLDLs/SLDUs/CDs as the basis for their new SLDLs/SLDUs/CDs or to create a completely new set and start their new SLDLs/SLDUs/CDs from a blank slate. a. Provide the option for the SLDLs/SLDUs/CDs to be displayed with a shaded color fill, where no like colored districts are touching, or as a uniquely outlined polygon layer. b. Show all features regardless of which district display method is chosen. 2. Allows the user to edit the SLDU, SLDL, and CD boundaries at the county level while still allowing them to view them at the state level with any updates they may have already made. 3. Employ the same edit rules as outlined for VTD above. 4. Restrict the user to a 3 digit alphanumeric code for the SLDUs or SLDLs. 5. Restrict the user to a 2 digit numeric code for the CDs. 6. Alerts the user if there are any areas in the state with no assigned SLDU(s) or SLDL(s). 7. Allows the user to view and assign the undefined SLDU area. Instruct the user that any area left not assigned to an SLDU will be automatically assigned an unassigned area code by the U.S. Census Bureau. 8. Allow the user to view and assign the undefined SLDL area. Instruct the user that any area left not assigned to an SLDL will be automatically assigned an unassigned area code by the U.S. Census Bureau. 9. Alert the user if there are any areas in the state with no assigned CDs. 10.Allow the user to view and assign the undefined CD area. 11.Alerts the user if there are any discontiguous SLDUs, SLDLs, or CDs. 12.Allows the user to flag an SLDU, SLDL, or CD as having one or more valid discontiguous pieces. 13.Identifies, and prompts users to review, all newly added line segments that are within 10 meters of one of the following existing line/boundary features (for both connected and disconnected lines.) a. MCD b. incorporated place c. another level of state legislative district d. Congressional district. e. school district f. military/park boundary g. roads h. hydrography (streams and area water bodies) 14.Identifies, and prompts users to review, all newly added line segments that repeatedly cross an existing line/boundary features (for both connected and disconnected lines.)county or equivalent area, 15.Allows the users to set relationship combinations for a selected CD, SLDL, or SLDU as: (These relationships are not required to be validations, they are for our informational purposes.) a. Completely Contains upper district, lower district, county, county subdivision, incorporated place, American Indian reservation or congressional district. b. Wholly Within upper district, lower district, county, county subdivision, incorporated place, American Indian reservation or congressional district. c. Coextensive with upper district, lower district, county, county subdivision, incorporated place, American Indian reservation or congressional district. Completely Contains = CC Wholly Within = WW Coextensive = CO Other = O d. The relationship information will be stored in specific fields i. The relationship types will be stored in the RELTYPE1, RELTYPE2, RELTYPE3, RELTYPE4, and RELTYPE5 fields of the returned shapefile. ii. The related entity will be stored in the corresponding REL_ENT1, REL_ENT2, REL_ENT3, REL_ENT4, and REL_ENT5 fields by the unique FIPS code for that entity. iii. The user should have the ability to enter a relationship description in a text box for further explanation or for complex relationships. This field should be required when they have chosen a relationship of OTHER. This information should be stored in the RELATE field. iv. The relationship type of OTHER should only be allowed for one of the REL_ENTx fields for any one CD, SLDL, or SLDU. v. If a the user has more than 5 relationships for a single CD, SLDL, or SLDU they should be stored in the RELATE text field using the CC, WW, CO, O codes followed by all entities that fall under that code. (e.g. CC place 54509, 67890 WW mcd 48756) 16.Allow users to enter an alphanumeric name associated to the SLDLs and SLDUs. (100 character maximum – entry of name is optional) 17.Allows user to generate a log file, in .dbf format, for all current CDs, SLDU and SLDL codes with associated SLD names by state/county. 18.Allows the user to access this log file interactively or print for review. 19.Allows users to export a file from the application containing the revised SLDUs, SLDLs, and CDs in shapefile formats. 20.Prompts the user to verify the uniquely displayed CD, SLDU and SLDL codes, delineations, and code assignments before state submission. 21.SLDL/SLDU/CD boundaries that are not any other type of feature will and should be coded as P0001s. These are non-visible linear legal/statistical boundaries. Many non-visible legal and statistical boundaries will be held. That said, if the participant selects an MTFCC of P0001 on a participant added line then that line should also be coded with a 4 in the CBBFLG field. If the participant changes the MTFCC of an existing line to P0001 then that line should also be coded with a 4 in the CBBFLG field. 22.Allows for session to be saved and re-opened. V. Returned Data Requirements (All returned program specific data files will contain, at a minimum, the program name (abbrv.), program year(s), state + county code, and the specific program feature type in the file name.) A. VTD/BBSP 1. BBSP a. The all lines layer with the 2010_BBSP field populated. The field 2010_BBSP should be populated by 1s and 2s with 1s being the value for those lines selected by the participant as “must holds” and 2s being the value for “do not holds”. b. An all transaction lines layer (Changed Lines) which is an extract of all the lines added, deleted, attributed, or otherwise modified. The field 2010_BBSP should be populated, where tagged by the participant, by 1s and 2s with 1s being the value for those lines selected by the participant as “must holds” and 2s being the value for “do not holds”. c. A BAG polygon shapefile as delineated by the participant. The individual BAGs should be numbered from 001 to 999 in a three digit text field named BAGCE. The MTFCC code should be G5035 held in the five digit MTFCC field. These are the only attribute fields required for this shapefile. Shapefile Fields Field Length Description Editable? Expected Values All Lines STATEFP 2 FIPS State Code N Unchanged COUNTYFP 3 FIPS County Code N Unchanged TLID 10 TIGER/Line ID N Unchanged   TFIDL 10 Permanent Face ID - left N Unchanged   TFIDR 10 Permanent Face ID - right N Unchanged   MTFCC 5 Census Feature Class Code Y - new N -existing Varies   FIDELITY 1 Shape Fidelity Flag N Unchanged   FULLNAME 40 Feature Name Y – new N –existing Varies SMID 22 Spatial TMeta ID N Unchanged   BBSPFLG 1 2000 Census Block Boundary Suggestion Project Flag N Unchanged   CBBFLG 1 Census Block Boundary Selection Field Y - new N -existing Varies   2010_BBSP 1 2010 Census Block Boundary Suggestion Project Flag  Y 1, 2   CHNG_TYPE 4 Type of Line Update Y CA – (Change Attributes) SL – (Split Line) DL – (Delete Line) AL – (Add Line) RL – (Realign existing line)   LTOADD 10 Left To Address Y String   RTOADD 10 Right To Address Y String   LFROMADD 10 Left From Address Y String   RFROMADD 10 Right From Address Y String ZIPL 5 Left from Zip Code Y String ZIPR 5 Right from Zip Code Y String 2. VTD a. The returned data for this program should be: i. An all transaction lines layer (Changed Lines). (If more than one type of entity (VTD, SLDU, SLDL, or CD) is delineated at the same time, then a single changed lines layer should be submitted. The participant will still need to submit a change polygon layer, a whole entity layer, and a complete coverage layer for each individual entity type that was delineated.) ii. The whole entity polygons layer. (All polygons in the given VTD layer, that had changes, after the participant updates are complete.) a. The whole entity polygons will use four types of change codes that should be entered into the CHNG_TYPE field. These codes are; B – Boundary Change, E – New Entity, G – Name Change, and V – Code Change. There is a hierarchy to these codes. If an area has multiple actions for the same area, then the software should maintain the code with the highest rank. They are, from highest to lowest, (E, B, V, G). iii. The change polygons. (All transaction area polygons, for the given VTD layer, where each polygon is coded with the appropriate change type code.) a. The change polygons will use four types of change codes that should be entered into the CHNG_TYPE field. These codes are; B – Boundary Change, E – New Entity, G – Name Change, and V – Code Change. There is a hierarchy to these codes. If an area has multiple actions for the same area, then the software should maintain the code with the highest rank. They are, from highest to lowest, (E, B, V, G). iv. The complete coverage polygons. (The new post-update coverage for the entire county.) a. The complete coverage polygons will use four types of change codes that should be entered into the CHNG_TYPE field. These codes are; B – Boundary Change, E – New Entity, G – Name Change, and V – Code Change. There is a hierarchy to these codes. If an area has multiple actions for the same area, then the software should maintain the code with the highest rank. They are, from highest to lowest, (E, B, V, G). v. The rules for when each code is used are: a. E = any area change where ((NEW_NAME <> NAMELSAD) AND (NEW_CODE <> VTDST00)) Note: This also requires a rechecking of areas coded as Bs, due to previous operations, when they have a later name or code change. (Example: When two areas are merged into one district with an existing code or name but are later renamed and recoded to a name and code that didn’t previously exist it should be coded as an E) b. B = any area change that is not considered an E c. V = any code change that does not involve area change. (recoding an existing district to a new code number) d. G = any name change that does not involve area change or a code change. (recoding an existing district to a new name) e. If the user creates a new VTD layer from scratch rather than use a copy of their 2000 VTDs then all polygons will have a CHNG_TYPE code of E and the change polygons will be the same as the whole entity layer. If they use a copy of their 2000 VTDs then the individual change polygons will be coded with the appropriate CHNG_TYPE codes and unaffected polygons will retain their null value. f. The user should be able to change the code and/or name of a VTD without changing the geography. Shapefile Fields Field Length Description Editable? Expected Values Voting Districts STATEFP00 2 Census 2000 FIPS code N Unchanged   COUNTYFP00 3 Census 2000 FIPS code N Unchanged   VTDST00 6 Census 2000 VTD code N Unchanged   NAMELSAD 100 Census 2000 VTD code + LSAD N Unchanged VTDI 1 Voting District Indicator Y A, P   LSAD 2 Census 2000 Legal/Statistical Area Description Code Y 00, V1, V2   CHNG_TYPE 2 Type of Area Update Y E, B, V, G   EFF_DATE 8 Effective Date or Vintage Y Date (yyyymmdd)   NEW_NAME 100 New Voting District Name Y String   NEW_CODE 6 New Voting District Code Y String   RELTYPE1 2 Relationship Type1 Y CC, WW, CO, O RELTYPE2 2 Relationship Type2 Y CC, WW, CO, O RELTYPE3 2 Relationship Type3 Y CC, WW, CO, O RELTYPE4 2 Relationship Type4 Y CC, WW, CO, O RELTYPE5 2 Relationship Type5 Y CC, WW, CO, O REL_ENT1 8 Relationship Entity1 Y (if a value is in RELTYPE1) String REL_ENT2 8 Relationship Entity2 Y (if a value is in RELTYPE2) String REL_ENT3 8 Relationship Entity3 Y (if a value is in RELTYPE3) String REL_ENT4 8 Relationship Entity4 Y (if a value is in RELTYPE4) String REL_ENT5 8 Relationship Entity5 Y (if a value is in RELTYPE5) String RELATE 120 Relationship Description Y (if a Relationship Type of OTHER is chosen) String NAME 100 Base Name portion of the Standardized Name N Unchanged VINTAGE 2 Vintage of the data N Unchanged FUNCSTAT 1 Functional Status N Unchanged 3. SLDUs a. The returned data for this program should be: i. An all transaction lines layer (Changed Lines). (If more than one type of entity (VTD, SLDU, SLDL, or CD) is delineated at the same time, then a single changed lines layer should be submitted. The participant will still need to submit a change polygon layer, a whole entity layer, and a complete coverage layer for each individual entity type that was delineated.) ii. The whole entity polygons layer. (All polygons in the given SLDU layer, that had changes, after the participant updates are complete.) a. The whole entity polygons will use four types of change codes that should be entered into the CHNG_TYPE field. These codes are; B – Boundary Change, E – New Entity, G – Name Change, and V – Code Change. There is a hierarchy to these codes. If an area has multiple actions for the same area, then the software should maintain the code with the highest rank. They are, from highest to lowest, (E, B, V, G). iii. The change polygons. (All transaction polygons, for the given SLDU layer, where each polygon is coded with the appropriate change type code.) a. The change polygons will use four types of change codes that should be entered into the CHNG_TYPE field. These codes are; B – Boundary Change, E – New Entity, G – Name Change, and V – Code Change. There is a hierarchy to these codes. If an area has multiple actions for the same area, then the software should maintain the code with the highest rank. They are, from highest to lowest, (E, B, V, G). iv. The complete coverage polygons. (The new SLDU post-update coverage for the entire county.) a. The complete coverage polygons will use four types of change codes that should be entered into the CHNG_TYPE field. These codes are; B – Boundary Change, E – New Entity, G – Name Change, and V – Code Change. There is a hierarchy to these codes. If an area has multiple actions for the same area, then the software should maintain the code with the highest rank. They are, from highest to lowest, (E, B, V, G). v. The rules for when each code is used are: a. E = any area change where ((NEW_NAME <> NAMELSAD) AND (NEW_CODE <> SLDUST)) Note: This also requires a rechecking of areas coded as Bs, due to previous operations, when they have a later name or code change. (Example: When two areas are merged into one district with an existing code or name but are later renamed and recoded to a name and code that didn’t previously exist we would want it coded as an E) b. B = any area change that is not considered an E c. V = any code change that does not involve area change. (recoding an existing district to a new code number) d. G = any name change that does not involve area change or a code change. (recoding an existing district to a new name) e. If the user creates a new SLDU layer from scratch rather than use a copy of their current SLDUs then all polygons will have a CHNG_TYPE code of E and the change polygons will be the same as the whole entity layer. If they use a copy of their current SLDUs then the individual change polygons will be coded with the appropriate CHNG_TYPE codes and unaffected polygons will retain their null value. f. The user should be able to change the code and/or name of an SLDU without changing the geography. Shapefile Fields Field Length Description Editable? Expected Values SLDU STATEFP 2 Current State FIPS Code N Unchanged COUNTYFP 3 Current County FIPS Code N Unchanged   SLDUST 3 Current State SLDU Code N Unchanged   NAMELSAD 100 Current State SLDU Name + LSAD N Unchanged   LSAD 2 Current 2000 Legal/Statistical Area Description Code Y 00, L1, L2, L7, LU   PARTFLG 1 Part Flag Indicator AUTO Y, N   CHNG_TYPE 2 Type of Area Update Y E, B, V, G   EFF_DATE 8 Effective Date or Vintage Y Date (yyyymmdd)   NEW_NAME 100 New State SLDU Name Y String   NEW_CODE 3 New State SLDU Code Y String   RELTYPE1 2 Relationship Type1 Y CC, WW, CO, O RELTYPE2 2 Relationship Type2 Y CC, WW, CO, O RELTYPE3 2 Relationship Type3 Y CC, WW, CO, O RELTYPE4 2 Relationship Type4 Y CC, WW, CO, O RELTYPE5 2 Relationship Type5 Y CC, WW, CO, O REL_ENT1 8 Relationship Entity1 Y (if a value is in RELTYPE1) String REL_ENT2 8 Relationship Entity2 Y (if a value is in RELTYPE2) String REL_ENT3 8 Relationship Entity3 Y (if a value is in RELTYPE3) String REL_ENT4 8 Relationship Entity4 Y (if a value is in RELTYPE4) String REL_ENT5 8 Relationship Entity5 Y (if a value is in RELTYPE5) String RELATE 120 Relationship Description Y (if a Relationship Type of OTHER is chosen) String LSY 4 Legislative Session Year Y String NAME 100 Base Name portion of the Standardized Name N Unchanged VINTAGE 2 Vintage of the data N Unchanged FUNCSTAT 1 Functional Status N Unchanged 4. SLDLs a. The returned data for this program should be: i. An all transaction lines layer (Changed Lines). (If more than one type of entity (VTD, SLDU, SLDL, or CD) is delineated at the same time, then a single changed lines layer should be submitted. The participant will still need to submit a change polygon layer, a whole entity layer, and a complete coverage layer for each individual entity type that was delineated.) ii. The whole entity polygons layer. (All polygons in the given SLDL layer, that had changes, after the participant updates are complete.) a. The whole entity polygons will use four types of change codes that should be entered into the CHNG_TYPE field. These codes are; B – Boundary Change, E – New Entity, G – Name Change, and V – Code Change. There is a hierarchy to these codes. If an area has multiple actions for the same area, then the software should maintain the code with the highest rank. They are, from highest to lowest, (E, B, V, G). iii. The change polygons. (All transaction polygons, for the given SLDL layer, where each polygon is coded with the appropriate change type code.) a. The change polygons will use four types of change codes that should be entered into the CHNG_TYPE field. These codes are; B – Boundary Change, E – New Entity, G – Name Change, and V – Code Change. There is a hierarchy to these codes. If an area has multiple actions for the same area, then the software should maintain the code with the highest rank. They are, from highest to lowest, (E, B, V, G). iv. The complete coverage polygons. (The new SLDL post-update coverage for the entire county.) a. The complete coverage polygons will use four types of change codes that should be entered into the CHNG_TYPE field. These codes are; B – Boundary Change, E – New Entity, G – Name Change, and V – Code Change. There is a hierarchy to these codes. If an area has multiple actions for the same area, then the software should maintain the code with the highest rank. They are, from highest to lowest, (E, B, V, G). v. The rules for when each code is used are: a. E = any area change where ((NEW_NAME <> NAMELSAD) AND (NEW_CODE <> SLDLST)) Note: This also requires a rechecking of areas coded as Bs, due to previous operations, when they have a later name or code change. (Example: When two areas are merged into one district with an existing code or name but are later renamed and recoded to a name and code that didn’t previously exist we would want it coded as an E) b. B = any area change that is not considered an E c. V = any code change that does not involve area change. (recoding an existing district to a new code number) d. G = any name change that does not involve area change or a code change. (recoding an existing district to a new name) e. If the user creates a new SLDL layer from scratch rather than use a copy of their current SLDLs then all polygons will have a code of E and the change polygons will be the same as the whole entity layer. If they use a copy of their current SLDLs then the individual change polygons will be coded with the appropriate CHNG_TYPE codes and unaffected polygons will retain their null value. f. The user should be able to change the code and/or name of an SLDL without changing the geography. Shapefile Fields Field Length Description Editable? Expected Values SLDL STATEFP 2 Current State FIPS Code N Unchanged COUNTYFP 3 Current County Code N Unchanged   SLDLST 3 Current State SLDL Code N Unchanged   NAMELSAD 100 Current State SLDL Name + LSAD N Unchanged   LSAD 2 Current 2000 Legal/Statistical Area Description Code Y 00, L3, L4, L5, L6, L7, LL   PARTFLG 1 Part Flag Indicator AUTO Y, N   CHNG_TYPE 2 Type of Area Update Y E, B, V, G   EFF_DATE 8 Effective Date or Vintage Y Date (yyyymmdd)   NEW_NAME 100 New State SLDL Name Y String   NEW_CODE 3 New State SLDL Code Y String   RELTYPE1 2 Relationship Type1 Y CC, WW, CO, O RELTYPE2 2 Relationship Type2 Y CC, WW, CO, O RELTYPE3 2 Relationship Type3 Y CC, WW, CO, O RELTYPE4 2 Relationship Type4 Y CC, WW, CO, O RELTYPE5 2 Relationship Type5 Y CC, WW, CO, O REL_ENT1 8 Relationship Entity1 Y (if a value is in RELTYPE1) String REL_ENT2 8 Relationship Entity2 Y (if a value is in RELTYPE2) String REL_ENT3 8 Relationship Entity3 Y (if a value is in RELTYPE3) String REL_ENT4 8 Relationship Entity4 Y (if a value is in RELTYPE4) String REL_ENT5 8 Relationship Entity5 Y (if a value is in RELTYPE5) String RELATE 120 Relationship Description Y (if a Relationship Type of OTHER is chosen) String LSY 4 Legislative Session Year Y String NAME 100 Base Name portion of the Standardized Name N Unchanged VINTAGE 2 Vintage of the data N Unchanged FUNCSTAT 1 Functional Status N Unchanged 5. CDs a. The returned data for this program should be: i. An all transaction lines layer (Changed Lines). (If more than one type of entity (VTD, SLDU, SLDL, or CD) is delineated at the same time, then a single changed lines layer should be submitted. The participant will still need to submit a change polygon layer, a whole entity layer, and a complete coverage layer for each individual entity type that was delineated.) ii. The whole entity polygons layer. (All polygons in the given CD layer, that had changes, after the participant updates are complete.) a. The whole entity polygons will use four types of change codes that should be entered into the CHNG_TYPE field. These codes are; B – Boundary Change, E – New Entity, G – Name Change, and V – Code Change. There is a hierarchy to these codes. If an area has multiple actions for the same area, then the software should maintain the code with the highest rank. They are, from highest to lowest, (E, B, V, G). iii. The change polygons. (All transaction polygons, for the given CD layer, where each polygon is coded with the appropriate change type code.) a. The change polygons will use four types of change codes that should be entered into the CHNG_TYPE field. These codes are; B – Boundary Change, E – New Entity, G – Name Change, and V – Code Change. There is a hierarchy to these codes. If an area has multiple actions for the same area, then the software should maintain the code with the highest rank. They are, from highest to lowest, (E, B, V, G). iv. The complete coverage polygons. (The new CD post-update coverage for the entire county.) a. The complete coverage polygons will use four types of change codes that should be entered into the CHNG_TYPE field. These codes are; B – Boundary Change, E – New Entity, G – Name Change, and V – Code Change. There is a hierarchy to these codes. If an area has multiple actions for the same area, then the software should maintain the code with the highest rank. They are, from highest to lowest, (E, B, V, G). v. The rules for when each code is used are: a. E = any area change where (CDFP <> NEW_CODE) Note: This also requires a rechecking of areas coded as Bs, due to previous operations, when they have a code change. (Example: When two areas are merged into one district with an existing code but are later recoded to a name and code that didn’t previously exist we would want it coded as an E) b. B = any area change that is not considered an E c. V = any code change that does not involve area change. (recoding an existing district to a new code number) d. If the user creates a new CD layer from scratch rather than use a copy of their current CDs then all polygons will have a code of E and the change polygons will be the same as the whole entity layer. If they use a copy of their current CDs then the individual change polygons will be coded with the appropriate CHNG_TYPE codes and unaffected polygons will retain their null value. e. The user should be able to change the code of a CD without changing the geography. Shapefile Fields Field Length Description Editable? Expected Values Congressional Districts STATEFP 2 Current State FIPS Code N Unchanged COUNTYFP 3 Current County FIPS Code N Unchanged   CDFP 2 Current Congressional District Code N Unchanged CDTYP 1 Congressional District Type N Unchanged   NAMELSAD 100 Current Congressional District Name + LSAD N Unchanged   LSAD 2 Census 2000 Legal/Statistical Area Description Code Y 00, C1, C2, C3, C4, C5   CHNG_TYPE 2 Type of Area Update Y E, B, V   EFF_DATE 8 Effective Date or Vintage Y Date (yyyymmdd)   NEW_CODE 2 New Congressional District Code Y String RELTYPE1 2 Relationship Type1 Y CC, WW, CO, O RELTYPE2 2 Relationship Type2 Y CC, WW, CO, O RELTYPE3 2 Relationship Type3 Y CC, WW, CO, O RELTYPE4 2 Relationship Type4 Y CC, WW, CO, O RELTYPE5 2 Relationship Type5 Y CC, WW, CO, O REL_ENT1 8 Relationship Entity1 Y (if a value is in REL_TYPE) String REL_ENT2 8 Relationship Entity2 Y (if a value is in REL_TYPE) String REL_ENT3 8 Relationship Entity3 Y (if a value is in REL_TYPE) String REL_ENT4 8 Relationship Entity4 Y (if a value is in REL_TYPE) String REL_ENT5 8 Relationship Entity5 Y (if a value is in REL_TYPE) String   RELATE 120 Relationship Description Y String CDSESSN 3 Congressional District Session Y String NAME 100 Base Name portion of the Standardized Name N Unchanged VINTAGE 2 Vintage of the data N Unchanged FUNCSTAT 1 Functional Status N Unchanged 1