Public Land Survey (PLS) to Feature Class

Converts a file of Public Land Survey (PLS) descriptions into a shapefile or geodatabase feature class, as points or polygons.

Discussion

FEATURE LOCATION - One {POINT | POLYGON} is generated from the PLS location described in each record in <in_file>. This is done by:

SELECT POLYGON - Selecting the first polygon encountered in <pls_fc> whose <pls_field> value is the same as the township/range/section ID in <in_file>.

CALCULATE SUBDIVISION POLYGON - (for POLYGON option) Calculating from the selected polygon the subdivision identified by the subdivision ID in <in_file>. In other words, if the subdivision ID is SW, then calculating the southwest quarter of the polygon. If the subdivision ID is blank, then the whole polygon is taken. NOTE - Calculation is done by means of PROPORTIONAL SUBDIVISION, see below.

CALCULATE SUBDIVISION POINT - (for POINT) Calculating the centerpoint of the subdivision polygon. In other words, if the subdivision ID is SW, then calculating the centerpoint of southwest quarter of the selected polygon. NOTE - Calculation is done by means of PROPORTIONAL SUBDIVISION, see below.

PROPORTIONAL SUBDIVSION - The selected <pls_fc> polygons are proportional subdivided to create subdivision points and polygons. This is done by:

LOCATE POLYGON CORNER POINTS - The 4 polygon corners are defined as the vertices of the polygon which are closest to the corners of its MBR (minimum bounding rectangle.)

CALCULATE EXTERNAL SUBDIVISION CORNER POINTS - The 4 sides formed between the 4 polygon corners are proportionally subdivided along their lengths to determine the location of the external subdivision corners, those which fall along the perimeter of the polygon. For example, if the subdivision ID in the <in_file> is SW, then the midpoint of the 4 sides is calculated to determine the location of the external quarter-section corners.

CALCULATE INTERNAL SUBDIVISION CORNER POINTS - Lines are formed between the external subdivision corners on opposite sides of the polygon, and these lines are intersected to determine the location of the internal subdivision corners. For example, if the subdivision ID is SW, then 2 lines are formed, one between the quarter-section corners on the north and south sides of the polygon, and the other between the quarter-section corners on the east and west sides. Then these lines are intersected to locate the internal quarter-section corner. Likewise, the intersection of the lines formed between external quarter-quarter-section corners are used as the internal quarter-quarter-section corners, and so on.

USE INTERNAL CORNERS AS SUBDIVISION POINTS (for POINT, and POLY label points) - The internal subdivision corners are used as the subdivision points. For example, if no subdivision ID is given (thus defaulting to the whole selected polygon), then the internal quarter-section corner is used as the centerpoint of the polygon. Likewise, if the subdivision ID is SW, then the quarter-quarter-section corner in the southwest quarter-section of the polygon is used as its centerpoint.

CONNECT CORNERS TO FORM SUBDIVISION POLYGONS (for POLYGON option) - The subdivision corners are connected to form the subdivision polygons. For example, if the subdivision ID is SW, then the SW polygon corner, the west quarter corner, the center quarter corner, and the south quarter corner are connected to form a polygon around the southwest quarter of the section. NOTE - subdivision polygons on the edge of the polygon incorporate the boundary of the polygon into their boundaries. For example, if there are intermediate vertices between the SW polygon corner and the west quarter corner, then these vertices are included in the southwest quarter-section polygon when it is constructed.

NOT ALWAYS LEGALLY CORRECT - Proportional subdivision is not always the 'legally' correct way of subdividing sections. For instance, sections along the north and west sides of townships are usually not exactly 640 acres in size and 'legally' should not be proportionally subdivided. The quarter-quarter sections along the north and west sides of the township are usually 'lots' and are usually not the same size as the other quarter-quarter sections, otherwise known as aliquot parts.

However, PLSARC is designed not to follow 'legal' rules, but instead to mimic how most people have used the PLS system as a general locational tool, as apposed to a legal tool.

Command line syntax

plsarc <in_file> <out_path> <out_fc> <point | polygon> <pls_fc> <pls_field> {reject_file1} {reject_file2}

Parameters

Expression Explanation
<in_file>

The input text file that contains PLS descriptions.

Each record in this file must contain 3 items: township/range/section, subdivision, and a user ID. For example:

  • "0040N0020W20","SWSW",1
  • 0040N0020W20,nenwnwsene,owl0001
  • "0040N0020W20","",3

The three items must be comma delimited. They can, but do not have to be, quoted.

township/range/section - this item can be in any format and contain any information (need not be township, range, and section), so long as it matches the <pls_field> data in the <pls_fc>.

subdivision - this item must contain 0 to 7 quarter codes (14 character maximum.) Valid quarter codes are NE, NW, SE, and SW. (They may be lowercase.) The quarter codes are read from left to right, i.e. SWNWNE is the southwest 1/4 of the northwest 1/4 of the northeast 1/4 of the section.

user ID - this can be anything (30 character maximum.) It will be used to identify the feature in the <out_fc>. The user ID will be used to populate a field named DATA.

<out_path>

The path of the folder or geodatabase in which the <out_fc> is to be created.

This folder or geodatabase must already exist.

<out_fc>

The name for the output shape file or geodatabase feature class.

If the <out_path> is a folder, then the <out_fc> will be a shape file. (There is no need to enter the .shp extension.)

If the <out_path> is a geodatabase, then the <out_fc> will be a geodatabase feature class.

The <out_fc> can not already exist.

<point | polygon>

The shape type for the <out_fc>.

POINT - the output is points. One point is generated at the center of the PLS location described in each record in the <in_file>.

POLYGON - the output is polygons. One polygon is generated to encompass the PLS location described in each record in the <in_file>.

<pls_fc>

The shape file or geodatabase feature class that contains the section polygons.

The coordinate projection of the <pls_fc> determines the projection of the <out_fc> results.

The polygons in <pls_fc> don't need to be square, rectangular, or even 4-sided. WARNING - But if they have concave sides, e.g.:

then the results may be undesirable. This is because features generated from such a polygon may fall outside of the polygon, and, in the case of generated polygons, may also be topologically incorrect.

<pls_field>

The field of the <pls_fc> table that identifies the township, range, and section number of each polygon.

The <pls_field> provides the link between the township/range/section ID in the <in_file> and the coordinate system of the <pls_fc>. Therefore, the contents of the <pls_field> must be in the same format as those of the township/range/section ID. However, the contents can be anything; they don't have to be township, range, and section.

{reject_file1}

The name of the text file which will contain any records from the <in_file> whose township/range/section ID did not find a match in the <pls_field>, i.e. are outside of the <pls_fc>.

If the full pathname for the {reject_file1} is not specified, then the file will be created in the folder that contains the <in_file>.

If the {reject_file1} isn't specified, then it will be named the same as the <in_file> with a '.rej1' extension and placed in the same folder.

If there are no rejected records, then the {reject_file1} will not be created.

{reject_file2}

The name of the text file which will contain any records from the <in_file> with invalid subdivision ID's, eg. SWSS.

If the full pathname for the {reject_file2} is not specified, then the file will be created in the folder that contains the <in_file>.

If the {reject_file2} isn't specified, then it will be named the same as the <in_file> with a '.rej2' extension and placed in the same folder.

If there are no rejected records, then the {reject_file2} will not be created.

Command Line Example

plsarc "C:\Documents and Settings\dchatfie\My Documents\plsarc\in_file" "C:\Documents and Settings\dchatfie\My Documents\plsarc" junk40.shp polygon "C:\Documents and Settings\dchatfie\My Documents\plsarc\testdb.mdb\plss3_polygon" trs
Executing (plsarc_3): plsarc "C:\Documents and Settings\dchatfie\My Documents\plsarc\in_file" "C:\Documents and Settings\dchatfie\My Documents\plsarc" junk40.shp polygon "C:\Documents and Settings\dchatfie\My Documents\plsarc\testdb.mdb\plss3_polygon" trs # #
Start Time: Thu Feb 02 18:24:36 2006
Running script plsarc...
Creating keyfile from input file...
Reselecting PLS with keyfile...
Converting legal descriptions to coordinates...
Finding polygon with same subject...
Checking aliquot part and determine position...
Subdividing polygon...
Outputing feature...
Done running plsarc
Completed script plsarc...
Executed (plsarc_3) successfully.
End Time: Thu Feb 02 18:25:01 2006 (Elapsed Time: 25.00 secs)

Scripting syntax

plsarc (in_file, out_path, out_fc, shape_type, pls_fc, pls_field, reject_file1, reject_file2)

Parameters

Expression Explanation
in_file (Required)

The input text file that contains PLS descriptions.

Each record in this file must contain 3 items: township/range/section, subdivision, and a user ID. For example:

  • "0040N0020W20","SWSW",1
  • 0040N0020W20,nenwnwsene,owl0001
  • "0040N0020W20","",3

The three items must be comma delimited. They can, but do not have to be, quoted.

township/range/section - this item can be in any format and contain any information (need not be township, range, and section), so long as it matches the <pls_field> data in the <pls_fc>.

subdivision - this item must contain 0 to 7 quarter codes (14 character maximum.) Valid quarter codes are NE, NW, SE, and SW. (They may be lowercase.) The quarter codes are read from left to right, i.e. SWNWNE is the southwest 1/4 of the northwest 1/4 of the northeast 1/4 of the section.

user ID - this can be anything (30 character maximum.) It will be used to identify the feature in the <out_fc>. The user ID will be used to populate a field named DATA.

out_path (Required)

The path of the folder or geodatabase in which the <out_fc> is to be created.

This folder or geodatabase must already exist.

out_fc (Required)

The name for the output shape file or geodatabase feature class.

If the <out_path> is a folder, then the <out_fc> will be a shape file. (There is no need to enter the .shp extension.)

If the <out_path> is a geodatabase, then the <out_fc> will be a geodatabase feature class.

The <out_fc> can not already exist.

shape_type (Required)

The shape type for the <out_fc>.

POINT - the output is points. One point is generated at the center of the PLS location described in each record in the <in_file>.

POLYGON - the output is polygons. One polygon is generated to encompass the PLS location described in each record in the <in_file>.

pls_fc (Required)

The shape file or geodatabase feature class that contains the section polygons.

The coordinate projection of the <pls_fc> determines the projection of the <out_fc> results.

The polygons in <pls_fc> don't need to be square, rectangular, or even 4-sided. WARNING - But if they have concave sides, e.g.:

then the results may be undesirable. This is because features generated from such a polygon may fall outside of the polygon, and, in the case of generated polygons, may also be topologically incorrect.

pls_field (Required)

The field of the <pls_fc> table that identifies the township, range, and section number of each polygon.

The <pls_field> provides the link between the township/range/section ID in the <in_file> and the coordinate system of the <pls_fc>. Therefore, the contents of the <pls_field> must be in the same format as those of the township/range/section ID. However, the contents can be anything; they don't have to be township, range, and section.

reject_file1 (Optional)

The name of the text file which will contain any records from the <in_file> whose township/range/section ID did not find a match in the <pls_field>, i.e. are outside of the <pls_fc>.

If the full pathname for the {reject_file1} is not specified, then the file will be created in the folder that contains the <in_file>.

If the {reject_file1} isn't specified, then it will be named the same as the <in_file> with a '.rej1' extension and placed in the same folder.

If there are no rejected records, then the {reject_file1} will not be created.

reject_file2 (Optional)

The name of the text file which will contain any records from the <in_file> with invalid subdivision ID's, eg. SWSS.

If the full pathname for the {reject_file2} is not specified, then the file will be created in the folder that contains the <in_file>.

If the {reject_file2} isn't specified, then it will be named the same as the <in_file> with a '.rej2' extension and placed in the same folder.

If there are no rejected records, then the {reject_file2} will not be created.

Script Example

import plsarc
plsarc.main("C:\Documents and Settings\dchatfie\My Documents\plsarc\in_file", \
"C:\Documents and Settings\dchatfie\My Documents\plsarc", "junk40.shp", "polygon", \
"C:\Documents and Settings\dchatfie\My Documents\plsarc\testdb.mdb\plss3_polygon", "trs")