BBSPV_NonGUPS_ParticipantGuide_Final

Status: Original and derived artifacts are available for this document.

Download: docx | pdf | html

Non-GUPS Guide – Instructions for Participating in BBSPV with User Supplied GIS Software

January 2027
Last updated August 2026
Table of Contents
Introduction	v
SECTION 1.	Planned 2030 Census Tabulation Block Boundaries	1
SECTION 2.	Suggested Workflow	3
2.1	Obtaining Census Partnership and Prototype Shapefiles	3
2.1.1	Shapefile Projection	4
2.2	Updating Census Bureau Shapefiles	5
2.3	Linear Feature Review	5
2.3.1	Creating the Update Shapefile for Linear Features	7
2.3.2	Required Attribution for Linear Features	8
2.4	Area Landmark Review	9
2.4.1	Creating the Update Layer for Area Landmarks	9
2.4.2	Required Attributes for Area Landmarks	10
2.5	Legal Boundary Updates	11
2.5.1	Required Attributes for Annexations and Deannexations	12
2.5.2	Boundary Correction Criteria	12
2.5.3	Required Attributes for Boundary Corrections	13
2.6	2020 Census Linear Feature Extension Review	13
2.7	Prototype Block Review	14
2.7.1	Block Size Review	14
2.7.2	Block Shape Review	15
2.8	Block Boundary Suggestion Flagging	15
2.8.1	Assigning a “Must Hold” Flag	17
2.8.2	Assigning a “Do Not Hold” Flag	17
2.9	Block Area Grouping Delineation	18
2.9.1	Creating the Block Area Grouping	18
2.9.2	Required Attribution for Block Area Groupings	19
2.10	Block Boundary Review	19
2.10.1	Performing Verification	19
2.11	Validation Checks	20
2.12	Submitting Updates to the Census Bureau	20
SECTION 3.	Creating Data Submissions	21
3.1	Submitting Linear Feature Updates/Block Boundary Suggestions	21
3.2	Submitting Area Landmark Updates	22
3.3	Submitting Legal Boundary Updates	22
3.3.1	BAS Partnership Toolbox Submission Files	22
3.3.2	Minor Civil Division Change Polygon Shapefile (Manual)	22
3.3.3	Incorporated Place Change Polygon Shapefile (Manual)	23
3.4	Submitting Block Area Grouping Updates	23
3.5	Creating .ZIP File Containing All Change Files	23
SECTION 4.	File Submission through the Secure Web Incoming Module (SWIM)	24
4.1	Submitting Files Through SWIM	24
Appendix A	Partnership Shapefile Data Dictionary	A-1
Appendix B	MTFCC Descriptions	B-1


List of tables
Table 1: 2030 Census Planned Block Boundaries by MAF/TIGER Feature Class Code (MTFCC)	1
Table 2: Partnership Shapefiles for Submissions	5
Table 3: MTFCCs for Linear Feature Updates	6
Table 4: Required Attributes for Linear Feature Updates	8
Table 5: MTFCCs for Area Landmark Updates	9
Table 6: Required Attributes for Area Landmark Updates	10
Table 7: Required Attributes for Annexations and Deannexations	12
Table 8: Required Attributes for Boundary Corrections	13
Table 9: Block Size Indicator Values	16
Table 10: Description of Block Boundary Flagging Fields	17
Table 11: Required Attributes for Block Area Groupings	20
Table 12: Hold Values for BBSP and BBSPV	20
Table 13: How to Change Previously Set Flags	20

List of Figures
Figure 1: Suggested Workflow	3



Introduction
Public Law (P.L.) 94-171 stipulates that the U.S. Census Bureau work in a non-partisan manner with the states to identify and provide the small-area population counts necessary for legislative redistricting. The Census Bureau is required to provide these counts within one year of Census Day, to the governor and the officers or public bodies responsible for redistricting in each state. For the 2030 Census, the Census Bureau must deliver the counts by April 1, 2031.
The Redistricting & Voting rights Data Office (RVDO) implements the requirements of P.L. 94-171 through the Redistricting Data Program (RDP) which is organized into five phases for the 2030 Census:
Phase 1: Block Boundary Suggestion Project (BBSP) 
Phase 2: Voting District Project (VTDP)
Phase 3: Delivery of the 2030 Redistricting Data 
Phase 4: Collection of Post-2030 Census Congressional and State Legislative District Plans 
Phase 5: Review of the 2030 Census Redistricting Data Program and Recommendations for the 2040 Census
This document pertains to the second cycle of Phase 1: Block Boundary Suggestion Project (BBSP) called Block Boundary Suggestion Project Verification (BBSPV) of the RDP. Through the BBSP, nonpartisan liaisons designated by the governors and legislative leadership in each state, the District of Columbia, and the Commonwealth of Puerto Rico, can influence the delineation of the 2030 Census tabulation blocks (i.e., blocks). 
Participants influence block delineation by suggesting linear features (e.g., roads, rivers, railroads, property lines, etc.) or edges to be held or not held as block boundaries. The Census Bureau refers to this as suggesting block boundaries, or setting or flagging ‘Must Hold’ or ‘Do Not Hold’ on the features. Participants can also influence block boundaries by adding and deleting linear features or edges, and by suggesting updates to boundaries for other census geographies including incorporated places, minor civil divisions (MCDs), counties, and area landmarks, all of which are potential block boundaries.
This guide is intended for states participating in the program using their own geographic information system (GIS) software. 
    • SECTION 1 of the document provides a conceptual overview of the planned 2030 Census tabulation block boundaries. 
    • SECTION 2 of the document contains the suggested workflow, update activities including verification, and quality control activities. 
    • SECTION 3 of the document contains the instructions for creating the submission to the Census Bureau. 
    • SECTION 4 of the document contains the instructions for using the Secure Web Incoming Module (SWIM) for submitting BBSP updates.

    SECTION 1. Planned 2030 Census Tabulation Block Boundaries
Block boundaries primarily follow visible features, such as roads and rivers, as well as any edges that bound legal, administrative, or statistical geographic areas or selected area landmarks stored in the Master Address File/Topologically Integrated Geographic Encoding and Referencing (MAF/TIGER) System. Census blocks nest within tabulated census geographic entities and are the smallest tabulation geography published by the decennial census.
Table 1 lists the feature and boundary types currently planned as 2030 Census block boundaries. If state participants flag these features as a “Do Not Hold” (i.e., request that the feature or boundary type not become a 2030 block boundary), the Census Bureau may not accept the “Do Not Hold” suggestion.
Table 1: 2030 Census Planned Block Boundaries by MAF/TIGER Feature Class Code (MTFCC)
MTFCC
Description
MTFCC
Description
G2120
Hawaiian Home Land
G5200
Congressional District
G2130
Alaska Native Village Statistical Area
G5210
State Legislative District (Upper Chamber)
G2140
Oklahoma Tribal Statistical Area
G5220
State Legislative District (Lower Chamber)
G2150
State-designated Tribal Statistical Area
G5240
Voting District
G2160
Tribal Designated Statistical Area
G5400
Elementary School District
G2170
American Indian Joint Use Area
G5410
Secondary School District
G2200
Alaska Native Regional Corporation
G5420
Unified School District
G2300
Tribal Subdivision
G6330
Urban Growth Area
G2400
Tribal Census Tract
G6500
Military Installation
G2410
Tribal Block Group
K2181
National Park Service Land
G4000
State or State Equivalent
K2182
National Forest or Other Federal Land
G4020
County or County Equivalent
K2540
University or College
G4040
County Subdivision
K1235
Juvenile Institution
G4060
Sub-Minor Civil Divisions
K1236
Local Jail or Detention Center
G4110
Incorporated Place
K1237
Federal Penitentiary, State Prison, or Prison Farm
G4120
Consolidated City
K1238
Other Correctional Institution
G5020
Census Tract
S1100
Primary Road
G5035
Block Area Grouping
S1200
Secondary Road
While primary and secondary roads (i.e., MTFCCs S1100 and S1200) are planned block boundaries, other linear features, such as local roads, alleys, railroads, and perennial water, may or may not qualify as block boundaries based on the established criteria. These features can be flagged as “Must Hold” or “Do Not Hold” block boundaries.
Participants can determine whether a feature is a planned block boundary by the feature’s value in the Census Block Boundary Flag (CBBFLG) field in the attribute table of the All Lines (edges) shapefile. A CBBFLG value of “4” indicates the feature is a planned 2030 block boundary, while a CBBFLG value of “9” indicates the feature is ineligible as a 2030 block boundary. A CBBFLG value of “1” indicates the feature was flagged as a “Must Hold” and a CBBFLG value of “2” indicates the feature was flagged a “Do Not Hold” during the delineation cycle of BBSP conducted in 2026. When the CBBFLG field is null, its status has not yet been determined. This indicates that it is a good candidate for a “Must Hold” or a “Do Not Hold” flag.
    SECTION 2. Suggested Workflow
Figure 1 depicts the suggested workflow for reviewing and updating Census Bureau data for the BBSP. This section outlines the activities associated with each of the workflow process boxes. 
Work is performed at a county level and should be submitted to the Census Bureau on a flow basis, as each county is completed. Submitting work on a flow permits the RVDO and the Census Bureau to review the files early in the process, provide feedback as necessary, and facilitates file processing.

Figure 1: Suggested Workflow
Note:	The review process may be different for each state. The number in parentheses refers to the section where the action is described.
        2.1 Obtaining Census Partnership and Prototype Shapefiles
To verify and submit new block boundary suggestions and other geographic updates, the Census Bureau requires participants to review and update Census Bureau-supplied partnership shapefiles. Participants can access the partnership shapefiles from two locations: 
    • Download the partnership shapefiles from the Geography Partnership website at:
        ◦ <www.census.gov/geographies/mapping-files/time-series/geo/partnership.html> 
    • Download the partnership shapefiles from the FTP site at:
        ◦ <https://www2.census.gov/geo/pvs/> 

In addition, all participants should download the prototype block shapefiles (described in section 2.7, Prototype Block Review) to use in conjunction with the partnership shapefiles.
    • Download the prototype block shapefiles from the FTP site at:
        ◦ <https://www2.census.gov/geo/pvs/bbsp/>
The partnership shapefiles are downloaded in a .zip file and reflect the legal boundaries of governments as reported through the 2026 BAS. The .zip file name begins with “partnership_shapefiles_ 26v2_<ssccc>,” where ss represents the two-digit state code and ccc represents the three-digit county code. When unzipped, the names of the shapefiles begin with the prefix “PVS_26_v2”. For example, the edges shapefile is named PVS_26_v2_edges_<ssccc>. 
Note:	The FTP site may contain multiple vintages of partnership shapefiles. For BBSP, make sure to use the vintage 2 shapefiles that begin with “PVS_26_v2.”
The prototype block shapefiles are downloaded in a .zip file and are created annually. The .zip file name begins with “bbsp_2027_prototype_blocks_st<##>" (where ss represents the two-digit state code). When unzipped, the names of the shapefiles begin with the prefix bbsp_2027_block_<ssccc>. There is a prototype block shapefile for every county within the state.
Note:	The FTP site may contain multiple vintages of the prototype block shapefiles. For BBSP, make sure to use the shapefiles that begin with “bbsp_2027.”
            2.1.1 Shapefile Projection
For participants using their own shapefiles for reference, the Census Bureau recommends re-projecting participant shapefiles to match partnership shapefiles provided by the Census Bureau to ensure correct alignment of the data. However, returned shapefiles may be in any projection as long as the projection information and the *.prj file are provided. A partnership shapefile data dictionary is provided in Appendix A. 
All shapefiles provided by the Census Bureau are in the following unprojected geographic based coordinate system:
    • GCS_NAD83
    • Angular Unit: Degree (0.017453292519943299)
    • Prime Meridian: Greenwich (0.000000000000000000)
    • Datum: D_North_American_1983
    • Spheroid: GRS_1980
    • Semi-major Axis: 6378137.000000000000000
    • Semi-minor Axis: 6356752.314140356100000000
    • Inverse Flattening: 298.257222101000020000
        2.2 Updating Census Bureau Shapefiles
Participants must use the following provided partnership shapefiles for their submissions. The Census Bureau requires that the returned shapefiles have specific names, attributes, and characteristics to be accepted as BBSP submissions. The attribute table layout will vary depending on the type of submission and is specifically described in that geography type’s section below.
Table 2: Partnership Shapefiles for Submissions
File name
Used For
PVS_26_v2_edges_<ssccc>
Linear feature review and updates (adds, deletes, attribute updates), linear feature extension review, and block boundary suggestion flagging.
PVS_26_v2_arealm_<ssccc>
Area landmark review and updates.
PVS_26_v2_place_<ssccc>
Incorporated place legal boundary updates.
PVS_26_v2_mcd_<ssccc>
MCD legal boundary updates.
PVS_26_v2_bag_<ssccc>
Block area grouping (BAG) review and updates.
Note: The MCD and BAG shapefiles will not be present in all counties
Because the Census Bureau requires that participants update Census Bureau partnership shapefiles with changes rather than submitting their own shapefile from their GIS, all participants must have the ability to edit a Census Bureau shapefile. Participants must create a separate linear feature update layer and change polygon layer for each updated entity type: area landmarks, places, MCDs, and block area groupings (BAG). Please create linear feature update layers and change polygon layers using only the current partnership shapefiles. The Census Bureau recommends the following steps to make any updates:
    1. Create a copy of the provided partnership shapefile to edit.
    2. Make updates to that copy as described in sections 2.3 through 2.9.
    3. Export the updates into a “changes” shapefile, following the naming conventions, and zip the shapefiles as described in SECTION 3.
    4. Submit the zipped shapefiles as described in SECTION 4.
        2.3 Linear Feature Review
All linear feature updates must be submitted back to the Census Bureau by updating the PVS_26_v2_edges_<ssccc> shapefile and exporting all changes into a participant created shapefile named bbsp27_<ssccc>_ln_changes. See section 3.1 for details on submitting the file.
Review the Census Bureau’s linear features (edges shapefile) to determine whether there are features needing to be added or deleted. Pay particular attention to any areas that have experienced population growth, and where there may be new housing or subdivisions not reflected in the Census Bureau’s geospatial data. To review the linear features, the Census Bureau suggests symbolizing the linear feature update shapefile based on the MTFCC.
Table 3: MTFCCs for Linear Feature Updates
MTFCC
Description
MTFCC
Description
C3024
Levee
L4165
Ferry Crossing
C3027
Dam
P0001
Nonvisible Legal/Statistical Boundary
H3010
Stream/River
P0002
Perennial Shoreline
H3013
Braided Stream
P0003
Intermittent Shoreline
H3020
Canal, Ditch, or Aqueduct
P0004
Other non-visible bounding edge (e.g., Census water boundary, boundary of area feature)
K2432
Pier/Dock
S1100
Primary Road
K2459
Runway/Taxiway
S1200
Secondary Road
L4010
Pipeline
S1400
Local Neighborhood Road, Rural Road, City Street
L4020
Power Line
S1500
Vehicular Trail (4WD)
L4110
Fence Line
S1630
Ramp
L4121
Ridge Line
S1640
Service Drive usually along a limited access highway
L4125
Cliff/Escarpment
S1730
Alley
L4130
Point-to-Point Line
S1740
Private Road for service vehicles (logging, oil fields, ranches, etc.)
L4140
Property/Parcel Line
S1820
Bike Path or Trail
R1011 
Railroad Feature (Main, Spur, or Yard)
R1051
Carline, Streetcar Track, Monorail, Other Mass Transit Rail
R1052
Cog Rail Line, Incline Rail Line, Tram


The basic groupings of the MTFCCs are as follows:
    • S-class = Roads.
    • R-class = Railroads.*
    • P-class = Nonvisible Features.*
    • L-class, K-class, and C-class = Other Linear Features.* 
    • H-class = Hydrography.*
The Census Bureau will also accept attribute updates (name and classification code) for MTFCCs in the S-class (roads). Added road features (except for highway ramps) require a feature name. If a road feature does not have a name but is still needed, use the name “BBSP Road”. Your update will be reviewed and adjudicated by Census staff during processing.
*These types of linear features should only be added if desired as a block boundary and therefore must have a “Must Hold” flag assigned to them when submitted to the Census Bureau.
Note:	Please be aware that the Census Bureau will not process the wholesale spatial realignment of features merely to conform to an alternate spatial accuracy. If a feature is in the incorrect location in the Census Bureau’s feature network, mark the feature for deletion and then add it in the correct location. Take this action only if most of the realigned feature is more than 7.6 meters from the existing feature or interferes (is topologically incorrect) with relationships to other features.
All linear feature updates, including linear feature extensions and block boundary suggestion flagging (“Must Holds” and “Do Not Holds”), and area landmark changes that require edge updates must be saved to the linear feature update layer.
            2.3.1 Creating the Update Shapefile for Linear Features
To submit linear feature updates, it is recommended to begin by making make a copy of the PVS_26_v2_edges_<ssccc> for editing and creating updates for submission. This is also referred to as the linear feature update shapefile in this document. Then, when done editing, export the changes from this update shapefile to create your submission file, as described in section 3.1. 
Once the edges shapefile is copied and symbolized, add the other partnership shapefiles (e.g., Congressional Districts, State Legislative District – Lower, State Legislative Districts – Upper, incorporated places, etc.), prototype block shapefile, and any local data shapefiles that may be helpful. During review, please note the following:
    1. Missing Road Features – If a road, subdivision, etc. is missing from the Census Bureau’s edges shapefile, add the feature(s) and provide the name and MTFCC in the attribute table. Feature name is required for any added roads except for highway ramps. The CHNG_TYPE field also needs to be updated to “AL” (AL stands for Add Line).
    2. Deleting Linear Features – If a feature in the Census Bureau’s edges shapefile does not exist, flag the feature by updating the attribute table with “DL” in the CHNG_TYPE field. Do not actually delete the feature in the shapefile (DL stands for Delete Line). Some linear features cannot be deleted from the MTS. If your goal is to ensure that the edge is not used as a block boundary, flag the edge(s) as a Do Not Hold, see section 2.8.2.  
    3. Spatial Inaccuracies – For our purposes, a feature is considered spatially inaccurate only if it is represented in the shapefile more than 7.6 meters from its actual location or it is positionally inaccurate in relation to other features and boundaries (e.g. a stream appears on the east side of the road, when it should be on the west side) in a way that would affect the assignment of housing units to legal entities, census tracts, and/or census blocks. If a feature is in the incorrect location in the Census Bureau’s edges shapefile, flag the feature for deletion (CHNG_TYPE=DL) in the attribute table, and add it as a new line (CHNG_TYPE=AL) in the correct location attributed with the TIGER/Line ID (TLID) value of the associated feature marked for deletion.
    4. Incorrect or Missing Names or MTFCCs – Correct or add the name and/or MTFCC in the attribute table and add “CA” in the CHNG_TYPE field (CA stands for Change Attribute). It is recommended to search the PVS_26_v2_allnames_ssccc.dbf file by TLID. If there are multiple names for the feature, the TLID will be listed more than once.  
Note:	In addition to not being able to accept wholescale realignments of features, there are other updates the Census Bureau cannot accept due to our representation requirements. For example, if a participant deletes both lanes of an interstate and adds a single line to replace the deleted interstate, the Census Bureau will not accept these changes.
            2.3.2 Required Attribution for Linear Features
Each linear feature update must have the required attributes and corresponding change type populated in the attribute table. The change type field (CHNG_TYPE) must be populated with either “AL”, indicating an added line, “DL”, indicating a deleted line, or “CA”, indicating the feature was renamed or given a different MTFCC. Table 4 lists the four potential actions and denotes the required attribution with an “X” and values in parenthesis. 
In addition, the following applies:
    • If adding a new line and deleting an existing line to make a spatial correction, add the value in the TLID field of the deleted line to the TLID field of the added line.
    • If adding a new linear feature, provide the feature name and MTFCC code in the FULLNAME and MTFCC fields. Linear features with MTFCCs of P-class, R-class, or L-class, should only be added if needed as block boundaries, so in addition to updating the CHNG_TYPE field with AL, add the “1” (Must Hold) attribute to the BBSP_2030 field if adding one of these MTFCC types. 
        ◦ If adding S-class features, updating the BBSP_2030 field with a “1” (Must Hold) is not required but is allowed if the feature is desired as a block boundary. Features classified as S1100, S1200, or S1400 require road names. If a road feature does not have a name but is still needed, use the name “BBSP Road”. Your update will be reviewed and adjudicated by Census staff during processing. 
    • If a P-class, R-class or L-class is being reshaped using added and deleted features, the added feature does not require a Must Hold flag; however, the Census Bureau does not encourage widescale cleanup of these features unless it affects the BBSP updates. 

Note:	Due to internal address update processes, the Census Bureau no longer collects address range updates through the RDP.
Table 4: Required Attributes for Linear Feature Updates
Action
CHNG_TYPE
TLID
FULLNAME
MTFCC
BBSP_2030
Add Feature
X (AL)

Required for all Sxxxx features S1100, S1200, and S1400.
X
X (1) if new linear feature should be a “Must Hold”
Delete Feature
X (DL)
X

X

Rename Feature
X (CA)
X
X
X

Reclassify Feature
X (CA)
X

X

Flag Existing Linear Feature with a BBSP Flag 
X (CA)
X

X
X (1) if linear feature should be a “Must Hold” OR (2) if linear feature should be a “Do Not Hold”
Remove Previously Set  BBSP Flag
X (CA)
X


X (0) 
        2.4 Area Landmark Review
All area landmark updates must be submitted back to the Census Bureau in a participant created shapefile named “bbsp27_<ssccc>_changes_alndk”. See section 3.2 for details on submitting the file.
The Census Bureau accepts updates to area landmarks (such as prisons, state parks, and cemeteries) as part of the BBSP. Allowable updates include:
    • Boundary corrections (adding and removing area).
    • Creating a new area landmark.
    • Removing an area landmark.
    • Changing or adding a name to an area landmark.
    • Changing/updating the MTFCC of an area landmark.
If the state plans to reallocate prisoners during redistricting, consider reviewing the existing area landmarks with MTFCCs K1235, K1236, K1237, and K1238, which represent areas with prison populations, or create new ones for those types of areas.
To report updates to water area features, such as lakes or reservoirs, please contact the RVDO at 301-763-4039 or at <[email protected]>.
            2.4.1 Creating the Update Layer for Area Landmarks
To submit area landmark updates, participants must create a separate change polygon shapefile. It is recommended to make a copy of the area landmarks shapefile (PVS_26_v2_arealm_<ssccc>) for editing and then, when done editing, export all changes into the “bbsp27_<ssccc>_ changes_alndk” shapefile.
If adding a new area landmark, the Census Bureau will process the submission in conjunction with other sources to add the area to the MTS. Table 5 shows the MTFCCs for the types of area landmarks that can be updated.


Table 5: MTFCCs for Area Landmark Updates
MTFCC
Description
MTFCC
Description
C3023
Island
K2182
National Forest or Other Federal Land
H2030
Lake/Pond
K2184
State Park, Forest, or Recreation Area
H2040
Reservoir
K2185
Regional Park, Forest, or Recreation Area
H2041
Treatment Pond
K2186
County Park, Forest, or Recreation Area
H2051
Bay/Estuary/Gulf/Sound
K2187
County Subdivision Park, Forest, or Recreation Area
H2081
Glacier
K2188
Incorporated Place Park, Forest, or Recreation Area
K1231
Hospital
K2189
Private Park, Forest, or Recreation Area
K1235
Juvenile Institution
K2190
Other Park, Forest, or Recreation Area (quasi-public, independent park, commission, etc.)
K1236
Local Jail or Detention Center
K2424
Marina
K1237
Federal Penitentiary, State Prison, or Prison Farm
K2457
Airport – Area Representation
K2131
Hospital/Hospice/Urgent Care Facility
K2540
University or College
K2180
Park
K2561
Golf Course
K2181
National Park Service Land
K2582
Cemetery
            2.4.2 Required Attributes for Area Landmarks
Each area landmark update must have the required attributes and corresponding change type populated. If participants are modifying an existing area landmark, they must preserve the existing AREAID for the feature in the AREAID field of the attribute table. Table 6 lists the five potential actions and denotes the required attribution with an “X”.
Table 6: Required Attributes for Area Landmark Updates
Action
FULLNAME
CHNG_TYPE
RELATE
MTFCC
AREAID
Boundary Correction (Add Area)
X
X (B)
X (IN)

X
Boundary Correction (Remove Area)
X
X (B)
X (OUT)

X
Delete Area Landmark
X
X (X)


X
Change Area Landmark Name or MTFCC
X
X (G)

X
X
New Area Landmark
X
X (E)

X

        2.5 Legal Boundary Updates
All legal boundary updates must be submitted back to the Census Bureau in a participant created shapefile. The shapefile name depends on the type of updated geography. See section 3.3 for details on submitting the file. 
During the initial delineation phase and the subsequent verification phase of the BBSP, participants may provide legal boundary updates (annexations, deannexations, incorporations and disincorporations), along with their supporting documentation, or boundary corrections. The Census Bureau will assume the responsibility for reconciling the updates with the appropriate governments as part of the Boundary and Annexation Survey (BAS).
Participants may submit legal boundary updates for counties, MCDs, incorporated places, and consolidated cities. Although legal documentation (effective date, authorization type, and documentation number) is not required for boundary updates submitted through the BBSP, the Census Bureau strongly encourages the submission of documentation to expedite our ability to reconcile and process any legal updates reported. Annexations, deannexations, incorporations, and disincorporations without supporting documentation should be submitted as boundary corrections. To report a new county, MCD, incorporated place, or consolidated city, or to delete an existing one, please call the RVDO at 301-763-4039 or at <[email protected]>.
There are two ways that legal boundary updates can be created and submitted to the Census Bureau: using the BAS Partnership Toolbox in ArcGIS Pro or manually creating updates. 
The BAS Partnership Toolbox was developed to facilitate creating a Boundary and Annexation Survey (BAS) submission. This toolbox simplifies the update process for participants by automating the download of data, change creation, sliver removal, attribution formatting and checks, and the export of files for submission. This allows the Census Bureau to easily process returned BAS files. The BAS Partnership Toolbox is also programmed to accept Tribal BAS updates; however, these updates cannot be submitted via BBSP. For more information, please refer to <https://www.census.gov/programs-surveys/bas/geographies/map-tools/arcmap-tools.html>. To download the Toolbox, visit <https://www2.census.gov/geo/pvs/bas/BAS_Partnership_Toolbox_Pro.zip>
To submit legal boundary updates manually, participants must create a separate change polygon shapefile showing the spatial differences between the boundary represented in the Census Bureau-provided partnership shapefile and the updated boundary. The Census Bureau recommends making a copy of the relevant entity’s partnership shapefile for editing and then, when done editing, exporting all the changes into the submission changes shapefile. Refer to SECTION 3 for the submission file naming requirements. 
If manual legal boundary updates are created, the Census Bureau requests that participants supply, in addition to the changes file, a whole entity file to accompany the legal boundary updates or boundary corrections made. A whole entity file is a shapefile that shows the entity being modified in its entirety (i.e., the new after editing boundary). It is not required but assists in the Census Bureau’s research on the change or correction. 
Note:	The Census Bureau cannot guarantee these updates will be made, as we must adjudicate and receive concurrence for the updates from the official BAS contact.
            2.5.1 Required Attributes for Annexations and Deannexations
The name field (NAME) in the attribute table should be populated with the name of the geographic entity affected. The change type field (CHNG_TYPE) should indicate whether the change is an annexation (A) or deannexation (D).
The effective date field (EFF_DATE) should be populated with the date of the ordinance, resolution, or local law authorizing the annexation or deannexation. If available, the authorization type field (AUTHTYPE) should be populated with the type of documentation authorizing the change (i.e., ordinance, resolution, local law, other). The documentation field (DOCU) should be populated with the documentation number. Table 7 lists the two acceptable legal boundary update actions and denotes the required attribution with an “X”.
Table 7: Required Attributes for Annexations and Deannexations
Action
NAME
CHNG_TYPE
EFF_DATE
AUTHTYPE
DOCU
Annexation
X
X (A)
X
X
X
Deannexation
X
X (D)
X
X
X
As a reminder, annexations, deannexations, incorporations, and disincorporations submitted without documentation should be submitted as boundary corrections.
            2.5.2 Boundary Correction Criteria
Because the Census Bureau uses a topologically integrated database, not all boundary corrections can be processed for incorporation in the MAF/TIGER System. The Census Bureau will accept, adjudicate, and process boundary corrections that meet both of the following conditions:
    • The existing boundary has been digitized incorrectly or appears in a significantly incorrect location.
    • The overall shape of the geographic entity is maintained and no feature-to- boundary relationships are dissolved.
The Census Bureau will not accept boundary corrections that:
    • Are along county boundaries unless there is a written agreement between the two counties that documents the correct location of the boundary.
    • Dissolve boundary-to-feature relationships (roads, rivers, railroads, etc.) if the difference is less than thirty feet.
Have a width of less than thirty feet over the entire polygon.
Note:	The Census Bureau will typically snap any entity boundary correction to a feature in the MAF/TIGER System when it exists within thirty feet of that feature.
            2.5.3 Required Attributes for Boundary Corrections
The name field (NAME) must be populated with the name of the geographic entity whose boundary is being corrected. The change type field (CHNG_TYPE) must be populated with a “B” to indicated boundary correction. The relate field (RELATE) must be populated with “IN”, indicating the corrected area is to be added into the named legal entity, or “OUT”, indicating the corrected area is to be removed from the named legal entity. Table 8 lists the two acceptable boundary correction actions and denotes the required attribution with an “X”.
Table 8: Required Attributes for Boundary Corrections
Action
NAME
CHNG_TYPE
RELATE
Boundary Correction (Add Area)
X
X (B)
X (IN)
Boundary Correction (Remove Area)
X
X (B)
X (OUT)
Please review all changes to ensure that the correct boundary-to-feature relationships are being created or maintained. For example, if a road and boundary are aligned as a single linear feature, the road and boundary should still be aligned as a single linear feature after the boundary correction. The Census Bureau is aware that many governments base their legal boundaries on cadastral (parcel-based) right-of-way mapping; however, the Census Bureau bases maps on spatial data that is topologically integrated. Therefore, when housing units are not affected, the Census Bureau suggests snapping the boundaries to nearby street centerlines (or rivers, railroads, etc.) wherever applicable. This will help establish a more accurate population count for entities.
        2.6 2020 Census Linear Feature Extension Review
All linear feature updates must be submitted back to the Census Bureau in a participant created shapefile named “bbsp27_<ssccc>_ln_changes”. See section 3.1 for details on submitting the file. This is the same submission file that would contain any updates to other linear features (adds, deletes, name changes, etc.) covered in section 2.3. 
All block boundary suggestions are contingent upon the lines intersecting to form a closed polygon at the time the Census Bureau creates blocks. As a result, all block boundary “Must Hold” flags, when combined with the features identified as planned holds, should form a closed polygon.
For the 2020 Census, BBSP participants could place a “Must Hold“ flag on an existing feature that did not form a closed a polygon. To do this, the participant also added a feature extension to close the polygon and create a potential new block. Those 2020 feature extensions are included in the 2030 BBSP files for review and update.
The Census Bureau requests that participants review the 2020 linear feature extensions to determine if they are still needed. Please be aware that to hold an old 2020 feature extension as a 2030 block boundary, participants must take an action to again classify that extension with a “Must Hold” flag, as described in section 2.8.
IMPORTANT:	The 2020 linear feature extensions can be identified by selecting all edges with attributes of BBSPFLG = 1, EXTTYP=I, and an MTFCC = P0001 in the PVS_26_v2_edges_<ssccc> shapefile.
During the linear feature extension review, participants may:
    • Hold the old 2020 linear feature extension as a 2030 block boundary suggestion along with the feature from which the extension originates by assigning BBSP_2030 with a value of 1 and a CHNG_TYPE = CA. If possible, when applying a Must Hold to a feature extension, review the extension against cadastral data or imagery to ensure it is in the most appropriate location.
    • Flag the old 2020 feature extension as a "Do Not Hold." Some linear features cannot be deleted from the MTS. By flagging the old 2020 linear feature extensions as "Do Not Holds," it will help the Census Bureau ensure the feature extension no longer serves as a block boundary. If it is determined that the 2020 linear feature extension is no longer needed as a feature extension, flag the extension with a BBSP_2030 = 2 and CHNG_TYPE = CA. 
    • Ignore the 2020 linear feature extension. Be aware that the Census Bureau may not use the 2020 feature extensions, and the features with which they are associated, as 2030 tabulation block boundaries. If no action is taken on a 2020 linear feature extension, the Census Bureau may delete the old extension or if kept, decide whether to hold the extension and the feature associated with it as a 2030 block boundary or not.
All updates should be saved in the linear feature update shapefile (bbsp27_<ssccc>_ln_changes). Refer to section 2.3 for details on creating this file.
        2.7 Prototype Block Review
The prototype block shapefile shows what the planned 2030 blocks would look like if created using the geography as it exists at this time. The prototype block shapefile is a useful tool for participants to review their potential block geography and then use the “Must Hold” and “Do Not Hold” flags to make targeted updates. 
Note:	The prototype block shapefile was created specifically for BBSP participants and is not included in the normal suite of partnership shapefiles. Download it from <https://www2.census.gov/geo/pvs/bbsp/>.
            2.7.1 Block Size Review
In the prototype block shapefile, the Census Bureau assigned a block size indicator (BLKZIND field) to each block based on the range of the estimated number of housing units in the prototype block. These values can be used to identify both potentially small population blocks or large population blocks to split or merge using the “Must Hold” and Do Not Hold” flags.
Note:	Although discrete numbers have been established to assign each block a size value, the actual number of housing units in a block is approximate.
Block size indicators range from “A” through “I,” with “A” blocks having the most housing units and “I” having the least. Prototype blocks estimated to contain no housing units are assigned an indicator letter of “Z.”
Table 9: Block Size Indicator Values
Indicator
Approximate Number of Housing Units
A
Greater than 2,000
B
1,600-1,999
C
1,200-1,599
D
1,000-1,199
E
700-999
F
480-699
G
400-479
H
240-399
I
1-239
Z
Potential “0” housing unit block
            2.7.2 Block Shape Review
In the prototype block shapefile, the Census Bureau also calculated a shape index (SHAPEIDX) using a simple area to perimeter ratio method. The shape index value will be between 0 and 1. The closer the value to 1, the more compact the block. The closer the value to 0 the less compact the block. These values can be used to help identify less compact blocks to see if their shape would interfere with the ability to conduct redistricting (e.g. long sinuous water bodies). Then, the “Must Hold” and “Do Not Hold” flags can be used to remedy this if it is an issue.
        2.8 Block Boundary Suggestion Flagging
All block boundary suggestions are considered linear feature updates and must be submitted back to the Census Bureau in a participant created shapefile named bbsp27_<ssccc>_ln_changes. See section 3.1 for details on submitting the file. This is the same submission file that would contain any updates to other linear features (adds, deletes, name changes, etc.). Refer to section 2.3 for details on creating this file.
The Census Bureau has identified features planned as 2030 block boundaries, which have a CBBFLG value of “4” in the edges shapefile (PVS_26_v2_edges). Refer to Table 1 for the complete planned feature list. The planned block boundaries may change if the criteria change, or if a feature’s attributes are updated through other Census programs.

The Census Bureau has also identified features that are ineligible to be 2030 block boundaries, shown with a CBBFLG value of “9” in the edges shapefile. There are also features with no block boundary status assigned (CBBFLG value is null). Participants are not required to assign a BBSP flag (e.g., “Must Hold” or “Do Not Hold”) to every feature in the file, nor should they.
The CBBFLG field also shows block boundary statuses set by participants during BBSP in 2026. A CBBFLG of “1” indicates the participant wanted the feature held as a block boundary, while a CBBFLG value of “2” indicates the participant wanted the feature set as a “do not hold.”
The BBSP_2030 field will be null in the partnership shapefiles. Values entered into this field will be used by Census to make the relevant flagging updates during processing.
Table 10: Description of Block Boundary Flagging Fields
Values
Description
BBSPFLG=1
2020 Participant Identified “Must Hold” Block Boundary.
BBSPFLG=2
2020 Participant Identified ”Do Not Hold” Block Boundary.
BBSPFLG=4
2020 Census Identified Planned Block Boundary.
BBSPFLG=9
2020 Census Identified Ineligible Block Boundary.
BBSP_2030=1
2030 Participant Identified “Must Hold” Block Boundary.
BBSP_2030=2
2030 Participant Identified “Do Not Hold” Block Boundary.
BBSP_2030=0
2030 Participant Identified “Must Hold” or “Do Not Hold” flag set during the initial BBSP Submission, now set for removal.
CBBFLG=1
2030 Participant Identified “Must Hold” Block Boundary (Populated by Census Bureau during processing of initial BBSP submission and corresponds to the value from the BBSP_2030 field when the Must Hold was applied and submitted.)
CBBFLG=2
2030 Participant Identified “Do Not Hold” Block Boundary (Populated by Census Bureau during processing of initial BBSP submission and corresponds to value from the BBSP_2030 field when the Do Not Hold was applied and submitted.)
CBBFLG=3
2030 Census Applied “Must Hold” Block Boundary.
CBBFLG=4
2030 Census Identified Planned Block Boundary.
CBBFLG=5
2030 Census Applied “Do Not Hold” Block Boundary.
CBBFLG=9
2030 Census Identified Ineligible Block Boundary.

            2.8.1 Assigning a “Must Hold” Flag
Participants may assign a “Must Hold” flag to features to suggest them as 2030 block boundaries. Candidates for assigning a “Must Hold” flag are:
    • Newly added features.
    • Features not currently planned as block boundaries.
    • To ensure features planned as 2030 block boundaries are held should the Census Bureau change their “planned” status. 
Participants may wish to assign a “Must Hold” flag to features that are planned 2030 block boundaries in case the block definition criteria or feature classification codes change between when BBSP occurs and when the Census Bureau creates the 2030 Census blocks. Assigning a “Must Hold” flag to a planned block boundary feature will increase the likelihood that the feature will become a 2030 block boundary.
Be aware that assigning a “Must Hold” flag to a feature that is ineligible to be a block boundary or assigning a “Do Not Hold” flag to a feature that is planned to be a 2030 block boundary does not ensure that the Census Bureau will honor the request. The Census Bureau will re-evaluate the feature’s status based on the participant’s suggestion.
All “Must Hold” block boundary flags are contingent upon the features intersecting to form a closed polygon at the time the Census Bureau creates the 2030 blocks. 
To assign a “Must Hold” flag, participants must edit the attributes of the linear feature update shapefile, as described in section 2.3:
    • To assign a “Must Hold” flag on an existing feature: BBSP_2030=1, CHNG_TYPE=CA.
    • To assign a “Must Hold” flag on a new feature: BBSP_2030=1, CHNG_TYPE=AL.
To hold a feature as a 2030 block boundary when the feature does not form a closed polygon, add a feature extension to close the polygon. Feature extensions must meet the following criteria:
    • Extensions, combined with other features and planned holds, must form a closed polygon.
    • Extensions must be no longer than 300 feet (if an extension needs to be longer than 300 feet, participants must provide justification in the JUSTIFY field of the attribute table of the linear feature update shapefile).
    • Extensions must be a straight line originating from the end of a road feature.
    • Extensions must terminate on a non-road feature, except for highways (i.e., extensions may terminate on highways – MTFCC S1100).
Digitize new 2030 feature extensions in the linear feature update shapefile described in section 2.3 and code each feature with a CHNG_TYPE = AL, BBSP_2030 = 1, and MTFCC=P0001.
            2.8.2 Assigning a “Do Not Hold” Flag
Participants may assign “Do Not Hold” flags to features that they do not want to become 2030 block boundaries. Potential candidates for assigning a “Do Not Hold” flag may include:
    • Private roads, trails, and unimproved roads.
    • Hydrographic features with no area, shown as a single-line feature, such as streams or creeks.
    • Any feature creating unnecessary blocks, such as highway ramps, traffic circles, or cul-de-sacs shown as open circles or “lollipops” in the Census geospatial files, and similar features.
Be aware that assigning a “Do Not Hold” flag to a feature that is a 2030 planned block boundary may not be honored if that boundary is needed to meet other Census criteria or program needs. For example, if a “Do Not Hold” flag was placed on an incorporated place boundary, the “Do Not Hold” would not be honored.
To assign a “Do Not Hold” flag, participants must edit the linear feature update shapefile as described in section 2.3:
    • To assign a “Do Not Hold” on an existing feature: BBSP_2030=2, CHNG_TYPE=CA.
    • To assign a “Do Not Hold” flag on a feature that should be deleted: BBSP_2030=2, CHNG_TYPE=DL.
        2.9 Block Area Grouping Delineation
The Block Area Grouping (BAG) layer participants create must be submitted back to the Census Bureau in a participant created shapefile named bbsp27_<ssccc>_BAG_changes. See section 3.4 for details on submitting the file.
During the 2030 Census block creation, the Census Bureau will automatically group islands to form a single block if they have no road features and the islands fall within a 5-kilometer radius. Participants may also choose to group specific islands to create a single 2030 Census block, called a BAG.  The criteria for creating a BAG are as follows:
    • BAG must consist of two or more islands.
    • BAG perimeter must be entirely over water.
    • BAGs cannot overlap.
    • BAGs cannot cross the boundary of other tabulation geographies, such as county or incorporated place boundaries.
BAG delineation is optional, and most appropriate for states with hydrographic areas that contain many islands.
            2.9.1 Creating the Block Area Grouping
Grouping selected islands to create a unique block identification is done by delineating a polygon around the selected islands. When creating a BAG, digitize the polygon around the set of desired islands making sure not to cross any land areas. If the polygon crosses any other tabulation areas, it will be split along that line as well.
To make BAG updates, participants must create a separate BAG update layer called bbsp27_<ssccc>_BAG_changes. The Census Bureau recommends making a copy of the Census Bureau BAG shapefile layer for editing and creating updates for submission. 
            2.9.2 Required Attribution for Block Area Groupings
The shapefile should have three text fields: BAGCE (length of 3), CHNG_TYPE and MTFCC (length of 5). When creating BAGs, provide each with a number in the BAGCE field. Start with 001 and increment by 1 for each BAG created. The change type field (CHNG_TYPE) must be populated with an “E” for each new BAG. The MTFCC should always be G5035. 
Table 11: Required Attributes for Block Area Groupings
Action
BAGCE
CHNG_TYPE
MTFCC
New BAG
X (001, 002, …)
X (E)
X (G5035)
        2.10 Block Boundary Review
All block boundary suggestions should be reviewed before submitting an updated county to the Census Bureau. During BBSPV, block boundary suggestions made during the initial BBSP phase can also be verified.
            2.10.1 Performing Verification
Linear features flagged as a “Must Hold” or “Do Not Hold” in the initial BBSP phase can be verified during the block boundary review process. 
During BBSP, any edges that were flagged as “Must Hold” were assigned a value of BBSP_2030=1 and any edges flagged with a “Do Not Hold” were assigned a value of BBSP_2030=2. During processing at Census, the BBSP_2030 values were copied to the CBBFLG field and the BBSP_2030 field was cleared. 
Verification updates allow for “Must Hold” or “Do Not Hold” flags to either be removed or replaced, by recording the new flag (including no flag, or a null value) in the BBSP_2030 field. Participants do not need to re-flag their edges with the same flag (i.e., select all the current edges with a “Must Hold” flag and flag them with “Must Hold” flags again).
Any updates to these flags during BBSP Verification will be written to the BBSP_2030 field and the CBBFLG field will be updated during Census processing. 
Table 12: Hold Values for BBSP and BBSPV

Set During BBSP
Set During BBSPV
Must Hold
CBBFLG=1
BBSP_2030=1
Do Not Hold
CBBFLG=2
BBSP_2030=2

Table 13: How to Change Previously Set Flags
Situation
Value Present in CBBFLG
Action to Take in BBSPV
Want to Change Previously Set Must Hold Flag to a Do Not Hold
CBBFLG=1
BBSP_2030=2 & CHNG_TYPE = CA
Want to Change Previously Set Do Not Hold Flag to a Must Hold 
CBBFLG=2
BBSP_2030=1 & CHNG_TYPE = CA
Want to Change Previously Set Do Not Hold Flag or Must Hold Flag to <Null> (i.e., remove the previously set flag) 
CBBFLG=1 or CBBFLG=2
BBSP_2030=0  & CHNG_TYPE = CA

        2.11 Validation Checks
The Census Bureau recommends participants check for any non-closed polygons or dangling edges with “Must Hold” flags prior to submitting a county return. A non-closed polygon is a polygon where one or more “Must Hold” block boundary flags have been set on features but the features, when combined with the planned block boundaries, do not close to form a possible census block. A dangling edge is an edge with a “Must Hold” flag that does not connect to an edge at each end point. 
If participants are editing area landmarks or legal entities, the Census Bureau also suggests reviewing the updates to ensure that there are no holes or very small area updates.
        2.12 Submitting Updates to the Census Bureau
The Census Bureau conducts the RDP activities through the official liaison appointed by the governor and legislative leadership of the state. The official liaisons are responsible for making BBSP updates and submitting the projects to the Census Bureau. However, the official liaisons have two options for designating technical liaisons to assist them in making BBSP updates on behalf of the state.
    • Option 1. Official liaisons can formally designate technical liaisons who are able to perform geographic updates and submit completed updates to the Census Bureau on their behalf. Official liaisons should reach out to the RVDO at 301-763-4039 or at <[email protected]> to make technical liaison designations.
    • Option 2. Official liaisons can delegate work to designees who perform the updates and submit the updates back to the official liaison. The official liaison will submit the work to the Census Bureau if they approve the work. If the official liaison determines that BBSP work completed by a designee requires changes or additional work, it is the official liaison's responsibility to decide whether to make the changes or return the project to their designee for further updates.
The liaison responsible for submitting updates to the Census Bureau should submit completed county-level files on a flow basis to the Census Bureau through SWIM. Do not hold files to submit all at once. Submit files as they are completed, especially at the beginning of the update period so that the Census Bureau can provide feedback if there are errors, omissions, or other concerns. 
    SECTION 3. Creating Data Submissions
The Census Bureau requires that the returned shapefiles have specific attributes and characteristics to accept them as legitimate submissions. Any changes made to the partnership shapefiles should be extracted and saved as a change shapefile. Below is a list of change shapefile types and specifications that should be included in the BBSP submission, depending on the type of updates made. A whole entity file is a shapefile that shows the entity being modified in its entirety, (i.e., the new “after editing” boundary). It is not required but assists in the Census Bureau’s research on the change or correction.
All returned shapefiles and whole entity shapefiles, as well as any supporting documentation, should be placed in a .zip file named “bbsp27_<ssccc>_return.zip” prior to submitting the return to the Census Bureau, where <ssccc> is the state and county FIPS code.
        3.1 Submitting Linear Feature Updates/Block Boundary Suggestions
Once all linear feature updates are complete, export the updated linear features (edges) to a shapefile named “bbsp27_<ssccc>_ln_changes.” Perform the following checks on the file.
    • Verify that all block boundary suggestions and feature extensions contain the correct attributes (e.g., BBSP_2030 field populated).
    • Verify that any new linear features, especially S-class features have names. If a road feature does not have a name but is still needed, use the name “BBSP Road”. Your update will be reviewed and adjudicated by Census staff during processing. 
    • Verify that any added lines contain the appropriate MTFCC code (e.g., P0001 for an invisible legal/statistical boundary) and the CHNG_TYPE field is populated. 
The submission file should include:
    • All linear features (edges) where BBSP_2030 field is populated with one of the following:
        ◦ 1 (“Must Hold”).
        ◦ 2 (“Do Not Hold”).
        ◦ 0 (“Remove previously set “Must Hold” or “Do Not Hold” flag).
AND
    • All linear features (edges) where CHNG_TYPE Field is populated with one of the following:
        ◦ AL (Add Line).
        ◦ DL (Delete Line).
        ◦ CA (Change Attribute: for the BBSP_2030, Name, and/or MTFCC fields).

Return File Name: bbsp27_<ssccc>_ln_changes.shp.

        3.2 Submitting Area Landmark Updates
If any updates were completed for area landmarks, export the updated records to a shapefile named “bbsp27_<ssccc>_changes_alndk.” The file should include all area landmark polygons where CHNG_TYPE Field is populated with one of the following:
    • B (Boundary Correction).
    • E (New Landmark).
    • G (Change Name or MTFCC).
    • X (Delete).
Lastly, if there is a shapefile of the whole area landmark, the Census Bureau requests that participants supply a whole entity file to accompany any area landmark updates to assist in making the updates to the MAF/TIGER System.
Return File Name: bbsp27_<ssccc> _changes_aldnk.shp.
Whole Entity File (if available) Name: bbsp27_<ssccc>_complete_alndk.shp.
        3.3 Submitting Legal Boundary Updates
If participants want to report a new county, MCD, incorporated place or consolidated city, or delete an existing one, please contact the RVDO at 301-763-4039 or at <[email protected]>. 
If participants are reporting other legal boundary changes and/or corrections, there are two options to submit boundary updates to the Census Bureau: the BAS Partnership Toolbox for ArcGIS Pro or manually creating the boundary update(s). 
If the updates are created manually, the Census Bureau requests that participants supply a whole entity file to accompany any legal boundary updates or boundary corrections that were made to assist in making the updates to the MAF/TIGER System. If making legal boundary updates, then include the following files in the submission, as applicable to the type of legal boundary update made.
            3.3.1 BAS Partnership Toolbox Submission Files
The BAS Partnership Toolbox zips submission files for all entity types into a file named BAS<yy>_<GOVID>_return.zip. Include this .zip file into the submission detailed in section 3.5.
            3.3.2 Minor Civil Division Change Polygon Shapefile (Manual)
If any updates were completed for MCDs, the changes file, “bbsp27_<ssccc>_changes_cousub.shp”, should include all change polygons where CHNG_TYPE field is populated with one of the following:
    • A (Annexation).
    • B (Boundary Correction).
    • D (Deannexation).
Return File Name: bbsp27_<ssccc>_changes_cousub.shp
Whole Entity File Name (if available): bbsp27_<ssccc>_wholeentity_cousub.shp
            3.3.3 Incorporated Place Change Polygon Shapefile (Manual)
If any updates were completed for incorporated places, the changes file, “bbsp27_<ssccc>_changes_incplace.shp”, should include all change polygons where CHNG_TYPE field is populated with one of the following:
    • A (Annexation).
    • B (Boundary Correction).
    • D (Deannexation).
Return File Names: bbsp27_<ssccc>_changes_incplace.shp
Whole Entity File Name (if available): bbsp27_<ssccc>_complete_incplace.shp
        3.4 Submitting Block Area Grouping Updates
If any BAGs were created, the file, “bbsp27_<ssccc>_bag_changes.shp”, should include all change polygons where MTFCC=G5035, and the CHNG_TYPE field is populated with:
    • E (New Block Area Grouping).
Return File Name: bbsp27_<ssccc>_bag_changes.shp
        3.5 Creating .ZIP File Containing All Change Files
All returned changes shapefiles and whole entity shapefiles, as well as any supporting documentation, should be placed in a single .zip file prior to submitting the return to the Census Bureau. Name the file for submission “bbsp27_<ssccc>_return.zip”. If the return includes a BAS Partnership Toolbox submission, do not zip both files together. Submit both the bbsp27_<ssccc>_return.zip and the BAS<yy>_<GOVID>_return.zip as two separate files within the same SWIM submission.  

    SECTION 4. File Submission through the Secure Web Incoming Module (SWIM)
The SWIM is a tool for Census Bureau partners to send their geospatial data to a secure Census Bureau server. For security reasons, the Census Bureau cannot accept files sent through email or through our former FTP site.
Participants for other Census Bureau geographic programs may use their existing SWIM account to submit files. If a liaison does not currently have a SWIM account, the Census Bureau will provide each official liaison (and technical liaison if applicable) a SWIM token to establish a SWIM account. Once registered, the token is no longer needed to log into the system.
Note: 	For all phases of the RDP, the Census Bureau will only accept files submitted by the official liaison or their designated technical liaison. 
        4.1 Submitting Files Through SWIM
1. Open a web browser window and enter the SWIM URL: <https://respond.census.gov/swim>. SWIM runs on the two most recent versions of each of these major browsers:
• Microsoft Edge®
• Google Chrome®
• Mozilla Firefox®
• Apple Safari®
2. Participants who already have a SWIM account should proceed to step 4 to log in. 
3. Participants who do not have a SWIM account should choose “Register Account:” 
a. Enter the 12-digit token provided by the Census Bureau. 
b. Create a password following the criteria below:
 i. Username and password are case sensitive. 
ii. It must be at least eight characters in length. 
iii. It must have at least one upper case character. 
iv. It must have at least one lower case character. 
v. It must have at least one number. 
vi. It must have at least one special character (valid characters are: #, !, $, &, ?, ~). 
c. Complete the registration information form.
4. Log in to SWIM using the participant’s email address and password. 
5. Upload a BBSP submission:
a. Select the “Start New Upload” button. 
b. Select the “Redistricting Data Program – BBSP-VTD (RDP)” radio button. 
c. Select the State and County. 
d. Select the “+ Add File” button. 
e. Select the .zip file to upload. 
f. Double-click on the .zip file to upload. Add additional .zip files in the same manner. 
g. Add any additional information to the “Comments” field. 
6. Choose “Next.” A “Thank You” screen appears. 
7. Logout of SWIM. 

    Appendix A Partnership Shapefile Data Dictionary
Partnership Shapefiles reflect the legal boundaries and names for all governments, as reported through the previous year’s BAS. Participants can access the partnership shapefiles from two locations: 
    • Download the partnership shapefiles from the Geography Partnership website at:
        ◦ <www.census.gov/geographies/mapping-files/time-series/geo/partnership.html> 
    • Download the partnership shapefiles from the FTP site at:
        ◦ <https://www2.census.gov/geo/pvs/>
Participants should make sure they download the 2027 files from the website, or those files on the FTP site that whose names begin with “partnership_shapefiles_26v2_<ssccc>.zip
Census Bureau files are in GCS NAD83 format and can be projected into any local coordinate system/project. Most GIS software packages will allow users to transform file coordinate systems and projections.
Partnership shapefile technical documentation is available at: <https://www.census.gov/programs-surveys/geography/technical-documentation/complete-technical-documentation/partnership-shapefiles.html>
    Appendix B MTFCC Descriptions
The MTFCC is a 5-digit code assigned by the Census Bureau to classify and describe geographic objects or features. A full list of MTFCC codes and descriptions can be found at <www.census.gov/library/reference/code-lists/mt-feature-class-codes.html>.