School District Review Program
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 MAFTIGER 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.	Level  The participant reported classification of school district type; elementary, secondary, or unified.

4.	Grade Range  The high and low grades the school district is financially responsible for educating.

5.	Boundary Correction  A change to the areal extent of a school district that is done to correct a misrepresentation or to add area to a district when not performing a complex dissolution or a simple consolidation.

6.	Consolidation  The process of merging two or more school districts, in their entirety.

7.	Complex Dissolution  The process of dissolving a school district and transferring its area to 2 or more other districts.

8.	Local Education Agency (LEA)  The organizations that are responsible for providing public education or services that support it

9.	LEA Code  The 5 digit code assigned as a unique, within state, identifying number for a Local Education Agency

10.	Submission Log -- Unique to the School District Review Program, this is a critical document/table that records all the changes that occur to each district in the state. 

	

	




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 and display data files for use as a reference when delineating their school districts.
a.	Shapefiles
b.	Spatial Data Transfer Standard (SDTS) files
c.	Digital Line Graphs (DLGs) 
d.	Imagery files
e.	Other standard geographic file formats

	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.)

	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 
d.	Incorporated Place 
e.	American Indian reservations and off reservation trust lands 
f.	American Indian tribal subdivisions 
g.	Hawaiian home lands 
h.	Alaska Native Regional Corporations  
i.	School Districts:
i.	Elementary 
ii.	Secondary 
iii.	Unified 
j.	D class area landmarks
i.	Military installations
ii.	State and national parks
k.	Area Hydrography
l.	Point Landmarks 

	8. Allow users to:

	a. Add (and then delete, if participant added) school district boundaries.

	b. Suggest edits (rename or add) to the names of pre-existing features and store them in a comments table that can be related back to the original feature.
 
	c. Edit (rename or add) names to features they have newly added themselves.

d. School District participants should not be allowed to delete, move, or reshape features that are not classified, based on their CFCC/MTFCC, as School District boundaries.  An explanatory message should appear when the user tries to edit features in a way not allowed.  When users add or edit lines, they should have the ability to submit additional comments in a comment table. This table should retain enough information that it can be related back to the feature once the files are returned to the U.S. Census Bureau.

e. 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.) 
i.	county or equivalent area
ii.	MCD
iii.	incorporated place
iv.	state legislative district
v.	congressional district
vi.	school district
vii.	military/park boundary
viii.	roads
ix.	hydrography (streams and area water bodies)	

f. 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.)

9. Allow users to:
a.	import their own state and county level shapefiles
b.	display their own state and county level shapefiles along with the data delivered by Census with the application.

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. School Districts Update module:

	A. Initial View
1.	State-level school district layer(s) and all county boundaries for the state.
a.	The state level view should give the user the ability to select the active working area by clicking on the desired county in this map view.

2.	A legend that can be toggled on and off or can be minimized.

3.	Default display/line-style for SD boundaries should allow for the viewing of the 3 different levels of SD geography with unique symbology for each.  All levels should be able to be viewed simultaneously, and with clarity so that overlapping and neighboring types can be easily distinguished.
a.	Provide the option for the active school district layer to be displayed with a shaded color fill where no like colored districts are touching.
b.	Show all features regardless of which district display method is chosen.

4.	A menu to select the active working area for beginning work. (This is an alternate method to Business Rule II-1-a to select the active area.)

B. Analysis

1.	The user should be able to do a comparison between their school district files and the school district files provided by Census. This comparison should use the LEA codes as the common link between the participants and the Census provided data. The comparison should allow the user to:
a.	identify districts not found in Census data
b.	identify districts not found in participant data
c.	find differences in area, between districts found in both files, in acres and sq. miles
d.	zoom to a district by selecting it from the comparison table/s
e.	allow the user to sort the comparison table/s on any of the fields

2.	Participants at the state-level need to be able to easily generate/create high-quality, thematic school district-based maps (letter size and large format E size plot) for printing and/or email distribution to local school district superintendents.  
a.	Maps should display date of creation.
b.	Maps should display, in the title, the program years and name, such as 2009-2010 School District Review Program 
c.	Maps should display the LEA code of the district being mapped.
d.	Maps should display the name of the school district. 
e.	Maps should have a legend 
f.	Map extents should be based on the current view in the application.

3.	State-level participants should be able to distribute the data and application to local School District Superintendents or county officials.  Local users should have the ability to make updates to the data for which they are responsible. If updates are made at this local level, the state participant should have the option to:
a.	analyze, review, and integrate multiple locally-submitted changes into a single state-level submission, or
b.	review/analyze the local submission and forward it to the U.S. Census Bureau as a partial submission (when deadlines are looming we need to be able to acquire changes on a flow basis rather than waiting for the entire state to be complete).

C. Participant Data Edit Functionality

1.   The user should be able to easily generate and record all the different types of edits and corrections that are part of the School District Review Program. (A sample of the instructions for the 2005-2006 program is located here: http://ftp2.census.gov/geo/sd2005_rev/st01_alabama/files/INSTRUCTIONSSD0506.PDF )
a.	Name Change
b.	Grade Range Change
c.	Level Change
d.	LEA Code Change
e.	Consolidation
f.	Boundary Correction
g.	Complex Dissolution
h.	New Area*
i.	Delete Area*
* These are not actual school district functions but are included as operations for manipulation of the school districts.

2.   Overall, redundancy of input should be eliminated wherever feasible.  If the participant is making changes that are being captured in the map data, then they should not have to key the same changes into the Submission Log.  The submission log should be automatically updated to reflect those changes.

3.   The application should allow for inter-level functionality when performing edits and corrections.

D. Submission Log

1.	As the participant uses the application to identify, correct, and update various aspects of the School District Review Program data, it will help the user to create or fill/in a Submission Log which has a single line/row for each individual change that the participant identifies, even when it takes them multiple attempts to fully create that change. Ideally, some fields of information in the submission log will be filled in automatically, as the participant points and clicks, to describe changes.  At a minimum, the application should remind the user to fill all details into the submission log as they are made.

2.	The Submission Log will be empty unless the participant finds errors, omissions, corrections, or updates that need to be submitted as part of the School District Review Program.

3.	This log should pop-up as each change is input into the MTPS.

4.	Submission Log Data Fields
a.	Type of Change
i.	As far as functionality of this field within the MTPS, these legal values should be part of a dropdown selection, so that this field does not need typed input, and so that the type of change entry is limited to only these defined types.
a.	NAME
b.	GRADE RANGE
c.	LEVEL
d.	LEA CODE
e.	CONSOLIDATION
f.	BOUNDARY
g.	COMPLEX DISSOLUTION
h.	NEW AREA
i.	DELETE AREA
b.	LEA of change  LEA code of the principal school district (SD) of change.
i.	Legal values are 5 digit codes that are included in the SDLEA field(s) of SD shapefile(s).
c.	Old Name  For name change, the NAME field (from .shp)	
d.	New Name  For name change the new name (typed in by participant)	
e.	Old GR low  For grade range change, LOGRADE field (from .shp)	
f.	Old GR high  For grade range change, HIGRADE field (from .shp)	
g.	New GR low  For grade range change, the new GR low (typed by participant)
i.	Legal values for all GR fields: PK K, 1, 2, 3, ....12.
h.	New GR high  For grade range change, the new GR low (typed by participant)
i.	Legal values for all GR fields: PK K, 1, 2, 3, ....12. 
i.	Old Level  For level change, from the shape name (elsd, scsd, unsd) (from .shp) 
i.	Legal values: E, S, U(Elementary, Secondary, and Unified)	
j.	New Level  For level change, the new level (typed by participant)
i.	Legal values: E, S, U (Elementary, Secondary, and Unified)	
k.	Old LEA  For LEA change, the old LEA code in SDLEA  
i.	Legal values are the same as those for LEA of change. 	
l.	New LEA  For performing a LEA code change, the new LEA code. (typed in by participant)	
m.	Consolidation1 LEA  For consolidation, LEA code of the first SD	
n.	Consolidation2 LEA  For consolidation, LEA code of the second SD
o.	Consolidation3 LEA  For consolidation, LEA code of the third SD. (not required)
p.	Consolidation4 LEA  For consolidation, the LEA code of the fourth SD. (not required)	
q.	Consolidation New LEA  For consolidation, the LEA code of the resulting new SD.
r.	Added Area LEA  For boundary change, the LEA code of the SD gaining area. For delete area, None entered to indicate the area has been moved to unassigned.	
s.	Lost Area LEA  For boundary change, the LEA code of the SD losing area.
t.	Deleted LEA  For complex dissolutions, the LEA code of the SD that no longer exists. Conditional for delete area, the LEA code of the deleted district if the participant deletes it completely using the delete area tool.	
u.	Narrative/Description  For detailed description of the change, what the change is attempting to represent, any particular details, and any other descriptions that may help to explain or convey the situation.
v.	Polygon ID  auto-generated unique ID created when a boundary change is input into the MTPS.

Column in Form	Length	Character Type	Legal
Values	Required
Type of
Change	25	String	NAME,
GRADE RANGE,
LEVEL,
LEA CODE,
CONSOLIDATION,
BOUNDARY,
COMPLEX DISSOLUTION, NEW AREA, DELETE AREA
(drop-down list)	Y
LEA of Change	5	String	Populated by a drop down list from the SDLEA field in the shapefile attribute table with an option to manually enter the code if its not present in the list.	Y
 Old Name	120	String	Populated from the NAME field in shapefile attribute table	Y (if a name change)
New  Name	120	String	Undefined String (Input by participant)	Y (if a name change or a consolidation)
Old GR Low	2	String	Populated from the LOGRADE field in shapefile attribute table	Y (if a grade change)
Old GR High	2	String	Populated from the HIGRADE field in shapefile attribute table	Y (if a grade change)
New GR Low	2	String	KG, PK, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12	Y (if a low grade change)
New GR High	2	String	KG, PK, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12	Y (if a high grade change)
Old Level	1	String	Populated based upon which shapefile (ELSD, SCSD, or UNSD) the school district appears in. Legal values = (E, S, U)	Y (if a level change)
New Level	1	String	E, S, U 
(Input by participant.)	Y (if a level change)
Old LEA	5	String	Populated from the SDLEA field in the shapefile attribute table.	Y (if LEA code change)
New LEA	5	String	Undefined Integer (Input by the participant)	Y (if LEA code change)
Consolidation1 LEA	5	String	Populated by a drop down list from the SDLEA field in the shapefile attribute table.	Y (if performing a consolidation)
Consolidation 2 LEA	5	String	Populated by a drop down list from the SDLEA field in the shapefile attribute table.	Y (if performing a consolidation)
Consolidation 3 LEA	5	String		
Consolidation 4 LEA	5	String		
Consolidation New LEA	5	String	Undefined Integer or Unknown (Input by the participant)	Y (if performing a consolidation)
Added Area LEA	5	String	Populated by a drop down list from the SDLEA field in the shapefile attribute table with an option to manually enter the code if its not present in the list.	Y (if boundary change or complex dissolution  also populated with none when delete area is used)
Lost Area LEA	5	String	Populated by a drop down list from the SDLEA field in the shapefile attribute table with an option to manually enter the code if its not present in the list.	Y (if boundary change or complex dissolution)
Deleted LEA	5	String	Populated by a drop down list from the SDLEA field in the shapefile attribute table.	Y (if complex dissolution or delete area)
Narrative/Description	500	String	Undefined String	Y ( if complex dissolution) and encouraged but optional for all other operations
Polygon ID	4	Integer	Auto-Fill	Y (except for name, grade range, level, and code change)




E. Type of Change descriptions 
(Note: The Type of Change field should always be populated for all submission log entries.)

1.	Name Changes.  
a.	Within the School District shapefile(s), one field will be the name of the school district.
b.	Participant should have the ability to review these names, and create/submit changes/corrections to the names.  
c.	Along with changing the attributes of the shapefile, the MTPS should allow/assist/prompt the participant to update the Submission Log summary table with an entry for each name change instance.  
d.	Preference would be for the MTPS to fill in appropriate fields with known <selectable> values automatically.
e.	Required Submission log entries for a Name Change:
i.	LEA of change  the LEA of the school district whose name is being changed
ii.	Old Name  the current name from which the school district is being changed
iii.	New Name  the new name to which the school district is being changed

2.	Grade Range Changes.
a.	Within the School District shapefile(s), two fields will have the lower and upper grade ranges representing the fiscal responsibility for each school district.  
b.	Participant should have the ability to review these grade ranges, and create/submit changes/corrections to the lower and/or upper grade range.  
c.	Along with changing the attributes of the shapefile, the MTPS should allow/assist/prompt the participant to update the Submission Log summary table with an entry for each grade range change instance.
d.	 Preference would be for the MTPS to fill in appropriate fields with known <selectable> values automatically.
e.	When finished making a grade range change, the participant should be asked if they also want to change the school district level. 
i.	If they do they should be taken to the level change function.
ii.	Otherwise, they should continue working normally.
f.	Required Submission log entries for a Grade Range Change:
i.	LEA of change  the LEA of the school district whose grade range is being changed
ii.	Old GR low  the current low grade from which the school district is being changed
iii.	Old GR high  the current high grade from which the school district is being changed 
iv.	New GR low  the new low grade to which the school district is being changed
v.	New GR high  the new high grade to which the school district is being changed

3.	Level Changes
a.	Each School District shapefile represents a different level of school district.  The three levels of school districts are:
i.	Unified
ii.	Elementary
iii.	Secondary
b.	Three combinations of school districts levels are found in states across the country:
i.	Unified only school districts 
ii.	Unified, Secondary, and Elementary level school districts 
iii.	Unified and Elementary level school districts
c.	For any given School District, the participant must have the ability to review the levels associated with the school districts, and create/submit changes/corrections to the level categorization.
d.	The MTPS should allow/assist/prompt the participant to update the Submission Log summary table with an entry for each grade range change instance.
e.	Preference would be for the MTPS to fill in appropriate fields with known <selectable> values automatically.
f.    When finished making a grade range change, the participant should be asked if they also want to change the school district level. 
i.	If they do they should be taken to the level change function.
ii.	Otherwise, they should continue working normally.
g.   When a level change occurs, the user should be able to select the district from its old level and then pick the level to which it is going. This should cause the software to remove the district from the old level and insert the district into the new level shapefile with minimal additional interaction from the user. The submission log should still be appropriately updated.
h.   Required Submission log entries for a Level change:
i.	LEA of change  the LEA of the school district whose level is being changed
ii.	Old Level  the current level from which the school district is being changed
iii.	New Level  the new level to which the school district is being changed

4.	LEA Code Changes
a.	Within the School District shapefile(s), one field will contain the Local Education Agency (LEA) code.  Each school district has an LEA, which may change, especially if the School District has changed name, or its territory of financial responsibility.
b.	Along with changing the attributes of the shapefile, the MTPS should allow/assist/prompt the participant to update the Submission Log summary table with an entry for each LEA code change instance.
c.	Preference would be for the MTPS to fill in appropriate fields with known <selectable> values automatically.
d.	Required Submission log entries for a LEA Code change:
i.	LEA of change  the LEA of the school district whose code is being changed (this will be the same as the Old LEA entry)
ii.	Old Lea  the current LEA code of the school district whose LEA code is being changed 
e.	New Lea  the new LEA code of the school district whose LEA is being changed.

5.	School District Consolidation
a.	One of the most common types of change submitted in the School District Review Program involves a simple merging of two school districts into one.  In some cases, the name and LEA code of one of the existing school districts will be kept and applied to the area for the new school district.  More often the resulting school district post-consolidation will have a new name and new LEA code.  The name is usually known by the participant, but the new LEA is sometimes known and sometimes not. School Districts can be consolidated within a single level, between levels, or both in the case of a 3 or more district consolidation.
b.	The MTPS should guide the participant through the SD consolidation process in a very easy manner.  
c.	If the participant indicates that this is a simple School District consolidation, the MTPS should prompt the user to click on the map, or select from a dropdown the two or more school districts that need to be consolidated. These school districts may, or may not, be of the same level. These school districts may, or may not, end up in a different level after consolidation. The user should be able to indicate all of this in a single transaction.
d.	Once the consolidating districts are identified, the MTPS should zoom to the area which includes these consolidating districts plus a small buffer.
e.	The MTPS should ask if the resulting SD has a new name.  If so, the MTPS should collect the new name (typed by participant).
f.	The MTPS should then ask the participant to input the new LEA code, if it is known. 
g.	The MTPS should ask the participant to input the new Grade Range. 
h.	The MTPS should ask the user at what level the newly consolidated district will reside and set it at that level when the consolidation is complete.
i.	Once all these inputs are collected, the geography data displayed in the MTPS should reflect the change in coverage caused by this consolidation, and the Submission Log summary table should be updated with a line to represent all of the details which have been input to describe the consolidation. 
j.	A Consolidation should be given a CHNG_TYPE code of E if it is given an LEA code that wasn't pre-existing or a B if it has a pre-existing LEA code. (If it has a new LEA it should be a new entity and if it keeps the LEA information from one of its consolidating districts then it is a boundary correction.)
k.	Required Submission log entries for a Consolidation:
i.	New Name  the new name to which the school district is being consolidated
ii.	Consolidation1 LEA  the LEA code of the first of the school districts being consolidated
iii.	Consolidation2 LEA  the LEA code of the second of the school districts being consolidated
iv.	Consolidation3 LEA  the LEA code of the third of the school districts being consolidated (optional, only used if more than 2 districts are being consolidated into one)
v.	Consolidation4 LEA  the LEA code of the fourth of the districts being consolidated (optional, only used if more than 3 districts are being consolidated into one)
vi.	Consolidation New Lea  the LEA code of the newly consolidated school district (if this is unknown at the time of submission the user should input an N followed by numeric digits starting at 0001 and incrementing by 1 for each new consolidation.)

6.	Boundary Change to an existing school district (aka annexation)
a.	The other common type of geographic coverage change submitted in the School District Review Program involves the transfer of some amount of territory to one school district from one (or more) adjacent school districts.  This can be complicated when the transferred territory is moving between school districts of different levels, but it usually involves transferring from one SD to another within the same level. 
b.	The MTPS should provide the functionality necessary to add area to a selected school district, and as with some other programs such as PSAP and VTDs/SLDs, the MTPS should also automatically take away area from an existing school district within the same level (for example, two elementary school districts should not be allowed to cover the same area).
c.	The MTPS should allow the participant to add new features to form the boundary of this change in coverage.  In all cases, the new feature will be an invisible school district boundary (F81), so this should be the only MTFCC for newly added lines in the SDRP.
d.	In some cases, where there are multiple boundary corrections between two adjacent SDs, this will mean that the Submission Log summary file will need to have multiple records with the same basic data (We should have a unique polygon ID for each change polygon, and have that ID put in the Submission Log, but this polygon ID does not need to be viewed or seen by the participant).
e.	Required Submission log entries for a Boundary change:
i.	LEA of change  the LEA of the school district that is adding area
ii.	PolyID  a unique 4 digit number assigned to the polygon representing the specific area that is being moved from the losing school district to the gaining school district. 
iii.	Added Area Lea  the LEA code of the school district that is gaining area
iv.	Lost Area Lea  the LEA code of the school district that is losing area
f.	In cases where the boundary change involves the adding of coverage into one SD level from another SD level, the MTPS should give the participant a message that says that the change they are submitting may be creating a coverage overlap between SDs of different levels, and that they should carefully examine and change the overlapping SDs of the different levels appropriately.

7.	Complex Dissolutions
a.	In these cases, a single SD will be dissolved into 2 or more adjacent SDs regardless of level. This does not necessarily need to be a wholly separate functionality because the boundary change functionality will allow the participant to add to the area of the adjacent SDs which are absorbing the various parts of the dissolving SD. What is unique here is that the participant needs to be able to know that the entire SD has been dissolved and no piece of it is left.
b.	Once a SD has been fully dissolved the participant should be made aware of this and the submission log should be updated with the deleted LEA associated with the boundary change that deleted the SD. 
c.	The user should be able to pick complex dissolution. If the user picks complex dissolution they should be prompted to continue assigning the remainder of the district being dissolved until it is no more (but not prevented from doing other work if they dont want to finish the dissolution at that time).
d.	Required Submission log entries for a Complex Dissolution: (this change type should only be used if the school district that is losing area is being completely dissolved and is giving its area to two or more other school districts. If the district is being dissolved and is giving all of its area to a single district, it is considered a consolidation and not a complex dissolution.)  This means that there will be, at a minimum, 2 entries for a complex dissolution, one entry for the first school district that is adding area, and another entry for the second. Additional entries are needed if additional school districts are absorbing area from the same dissolved school district.)
i.	LEA of change  the LEA of the school district that is adding area
ii.	PolyID  a unique 4 digit number assigned to the polygon representing the specific area that is being moved from the dissolved school district to the school district in the Added Area LEA field. 
iii.	Added Area LEA  the LEA code of the school district that is gaining area
iv.	Lost Area LEA  the LEA code of the school district that is losing area
v.	Deleted LEA  the LEA code of the school district that is being dissolved
vi.	Narrative/Description  a very brief description of the complex dissolution

8.	New Area
a.	In addition to the typical school district operations, the user will need the ability to create new districts or new in county areas of districts.
b.	If the newly created area takes area away from other school districts, there needs to be an entry in the submission log for each of those districts that is losing area. Ex. New District is created from part of D1, part of D2, and some unassigned area.  There should be 3 entries in the submission log. One with D1 as the Lost Area LEA, another with D2 as the Lost Area LEA, and a third with none as the Lost Area LEA.
c.	Required Submission Log entries for a New Area:
i.	LEA of change  the LEA of the school district/area that is being created
ii.	New Name  the name the new school district/area is being given.
iii.	New GR low  the low grade the new school district/area is being given.
iv.	New GR high  the high grade the new school district/area is being given.
v.	New Level  the level the new school district/area is being given
vi.	New Lea  the LEA code the new school district/area is being given.
vii.	Added Area LEA  the LEA code the new school district/area is being given.
viii.	Lost Area LEA  the LEA code of the school district that is losing area or none if coming from unassigned area.
ix.	PolyID  a unique 4 digit number assigned to the change polygon representing the specific area that is being created.  
x.	Narrative/Description  a listing of affected school districts from all levels as supplied by the participant.

9.	Delete Area
a.	In addition to the typical school district operations, the user will need the ability to delete area from districts.
b.	A warning should be displayed that states This tool is for deleting parts of school districts that cannot be deleted through the use of other tools. If you can perform your work using the Boundary Correction, Complex Dissolution, or Consolidation tool, please do so.
i.	This warning should have a toggle that allows the user to prevent its display when invoking the tool in the future.
ii.	This warning should be displayed again if the participant tries to delete the last area of a pre-existing district and also notify them that they are about to completely delete it. 
c.	There needs to be an entry in the submission log for each district that is losing area. Ex. Area is deleted from part of D1 and part of D2.  There should be 2 entries in the submission log, one with D1 as the Lost Area LEA, another with D2 as the Lost Area LEA.
d.	Required Submission Log entries for a Delete Area:
i.	LEA of change  the LEA code of the school district that is having area deleted
ii.	Added Area LEA  the word none to indicate the area has been moved to unassigned.
iii.	Lost Area LEA  the LEA code of the school district that is having area deleted
iv.	PolyID  a unique 4 digit number assigned to the change polygon representing the specific area that is being created.
v.	Deleted LEA (conditional)  If the participant deletes the last area of a pre-existing district, then this field should be populated with that districts LEA code. Otherwise, do not populate this field.

F. Interactive Validations 

1.	Once a participant has input a change to the geography of a SD, or at anytime during the process, the participant should have the ability to run different types of validations that check geographic data integrity, topology, and area relationships.  The user will have to input details, but validation tools should be able to check for:
a.	Gaps and overlaps within each layer and between the layers.
i.	Overlaps (Grade Range)  No grade should be represented by more than a single district. Ex. A Face that is covered by a grade range of PK to 7 in an elementary layer and a grade range of 6 to 12 in a secondary layer would fail.  The face has an overlap of grades 6 & 7.
ii.	Gaps (Grade Ranges)  This is covered by the complete coverage check. 
b.	Nesting relationships (user will have to input layers and parameters from dropdown selections. Partial nesting is when the area(s) that nest within another area do not cover that other area completely. Complete nesting is when the area(s) that nest within another area do cover that other area completely.)
i.	The (choose one or more School districts) nest within (choose an incorporated place, MCD, or a county) partially.
ii.	The (choose one or more School districts) nest within (choose an incorporated place, MCD, or county) completely.
iii.	The (choose one or more incorporated places, MCDs, or a county) nest within (choose a School district) partially.
iv.	The (choose one or more incorporated places, MCDs, or a county) nest within (choose a School district) completely.
c.	Contiguity, including the contiguity of unassigned areas to allow a search for unassigned holes within districts.
d.	Complete coverage. (every polygon should be covered by a LOGRADE of PK, K, or 01 through a HIGRADE of 12 )
e.	Complex dissolutions complete -- This validation should check to see if there are any remaining parts to a district that was supposed to have been completely dissolved due to its participation in a complex dissolution.  The user should be given the opportunity to complete the reassignment of the remaining pieces, leave the remaining pieces but change those areas that are no longer part of that district to boundary corrections instead of complex dissolutions, or to do nothing. The failure of this validation should not prevent submission.

G. Reporting to Census

1.	The Complex Dissolution, Discontiguity, and Overlaps & Gaps verifications are required to run before the user can report the changes to Census.
a.	When first invoking the Report Changes command, a message should appear that lists each of the pre-submission required verifications and explains that they are required to be run before submitting changes.  (Preferably, this message would also ask if they wanted to run these now. If they answered Yes, it would open the verification tool window or run them automatically for them.)
b.	Subsequent use of the Report Changes command should cause a message to be displayed that lists each of the required verifications and the last date and time it was run. (Preferably, this message would also ask if they wanted to run these now.  If they answered Yes, it would open the verification tool window or run them automatically for them.)

H. Output to Census

1.	Data output from the application shall include one file (.dbf  or Excel) per county (and school district level) formatted as a Submission Log summary table that: 
a.	itemizes each of the School District Review Program changes
b.	identifies the individual School districts affected by the change
c.	identifies the category or type of change
d.	contains a column for free text that allows the participant to enter a detailed description or explanation of the change.
e.	contains data as specified in section D & E above.
f.	The submission log files will follow the naming convention of: sdrpyryr_ssccc_xxsd_log.*  (programyear1year2_statecounty_schooldistrictlevel_log.*) 
<There is an example submission log at the end of this document>

2.	Boundary change data shall be in a format consistent with the shapefile specifications provided.
a.	The polygon files will follow the naming convention of: sdrpyryr_ssccc_xxsd_changes.* ; sdrpyryr_ssccc_xxsd_whole.*  ; sdrpyryr_ssccc_xxsd_complete.* (program_year1year2_statecounty_schooldistrictlevel_changes.* ; program_year1year2_statecounty_schooldistrictlevel_whole.* ; program_year1year2_statecounty_schooldistrictlevel_complete.*)
The changes will be the change polygons and the overlapping whole entity polygons of those entities that had changes, the whole will be the whole entities of just those entities that had changes, and the complete will be the complete coverage of the new post update layer.
b.	The changed lines file will follow the naming convention of: sdrpyryr_ssccc_ln_changes.*
c.	The changed lines comment file will follow the naming convention of: sdrpyryr_ssccc_ln_changes_comments.*

3.	Coding Explanations  We are expecting the following codes to be returned in the CHNG_TYPE field of the change polygon shapefile. 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, H, X, D)




Code	Explanation
B	Boundary (refers to Boundary in Type of Change in Submission Log)
H	Complex Dissolution (refers to Complex Dissolution in Type of Change in Submission Log)
E	New Area (Refers to New Area in Type of Change in Submission Log)
D	Delete Area (Refers to Delete Area in Type of Change in Submission Log when correctly used for only a partial district deletion)
X	Delete Area ( Refers to Delete Area in Type of Change in Submission Log when it is used incorrectly to completely delete a district.
Note: Mapping by these codes will not be necessary as the user should be trying to minimize the difference between their boundary file and that of census rather than track the changes by type.






SHAPE FILE SPECIFICATIONS
Shapefile	Fields	Field Length	Description	Editable?	Expected Values
ELSD	STATEFP	2	Current State FIPS Code	N	Unchanged
	COUNTYFP	3	Current County FIPS Code	N	Unchanged
 	SDLEA	5	Current ELSD Local Education Area (LEA) Code	N	Unchanged
 	NAME	100	Current ELSD Name	N	Unchanged
 	LSAD	2	Current 2000 Legal/Statistical Area Description Code	N	Unchanged
 	HIGRADE	2	Highest Grade	N	Unchanged
 	LOGRADE	2	Lowest Grade 	N	Unchanged
 	PARTFLG	1	Part Flag Indicator	N	Y, N
 	POLYID	4	Record ID for each ELSD Update for linking to the Submission Log	AUTO	Undefined String
 	CHNG_TYPE	2	Type of Area Update	Y	B, H, E, D, X
 	EFF_DATE	8	Effective Date or Vintage	Y	Date (yyyymmdd)
 	RELATE	120	Relationship Description	Y	Undefined String
	FUNCSTAT	1	Functional Status	N	Unchanged
	VINTAGE	2	Vintage of the data	N	Unchanged
SCSD	STATEFP	2	Current State FIPS Code	N	Unchanged
	COUNTYFP	3	Current County FIPS Code	N	Unchanged
 	SDLEA	5	Current SCSD Local Education Area (LEA) Code	N	Unchanged
 	NAME	120	Current SCSD Name	N	Unchanged
 	LSAD	2	Current 2000 Legal/Statistical Area Description Code	N	Unchanged
 	HIGRADE	2	Highest Grade	N	Unchanged
 	LOGRADE	2	Lowest Grade 	N	Unchanged
 	PARTFLG	1	Part Flag Indicator	N	Y, N
 	POLYID	4	Record ID for each SCSD Update for linking to the Submission Log	AUTO	Undefined String
 	CHNG_TYPE	2	Type of Area Update	Y	B, H, E, D, X
 	EFF_DATE	8	Effective Date or Vintage	Y	Date (yyyymmdd)
 	RELATE	120	Relationship Description	Y	Undefined String
	FUNCSTAT	1	Functional Status	N	Unchanged
	VINTAGE	2	Vintage of the data	N	Unchanged
UNSD	STATEFP	2	Current State FIPS Code	N	Unchanged
	COUNTYFP	3	Current County FIPS Code	N	Unchanged
 	SDLEA	5	Current UNSD Local Education Area (LEA) Code	N	Unchanged
 	NAME	120	Current UNSD Name	N	Unchanged
 	LSADC	2	Current 2000 Legal/Statistical Area Description Code	N	Unchanged
 	HIGRADE	2	Highest Grade	N	Unchanged
 	LOGRADE	2	Lowest Grade 	N	Unchanged
 	PARTFLG	1	Part Flag Indicator	N	Y, N
 	POLYID	4	Record ID for each UNSD Update for linking to the Submission Log	AUTO	Undefined String
 	CHNG_TYPE	2	Type of Area Update	Y	B, H, E, D, X
 	EFF_DATE	8	Effective Date or Vintage	Y	Date (yyyymmdd)
 	RELATE	120	Relationship Description	Y	Undefined String
	FUNCSTAT	1	Functional Status	N	Unchanged
	VINTAGE	2	Vintage of the data	N	Unchanged
 
Submission Log Example