Does anyone use TRS (Township, Range, Section) data?

The primary industry that uses this is the real estate industry, and planning and government. The TRS system is the basis for the legal descriptions that describe the locations of land parcels in most of the United States.

Legal Description - Wikipedia

There are a number of ways that the bounds of a land parcel may be described, but at some point, whether at the parcel level, or subdivision level, it is tied back into the TRS system. The caveat to this is that it mostly applies to land west of the Mississippi aside from Texas, the states bordering the Great Lakes, and the southern states aside from Georgia.

There are likely other uses, but I think this is the primary, and most critical in the context of property ownership rights in the US.

There are a number of industries that use PLSS data. Russell mentions the Real Estate market, but also the Energy/Resources and Utilities industries as well. In my current applications we provide interfaces for companies to report to us the location of assets/resources based on their Township/Range/Section/Quarter/QuarterQuarter as many areas do not have a hard address that you can geocode a location too.

I've developed tools for petroleum landmen that allow them to create polygons of leases based on PLSS legal descriptions in a spreadsheet.

The first tool lives within Excel and is used to export legal descriptions of leases from the spreadsheet into an xml file. The workbook contains VBA which references a data transfer class. The class is written in .NET with a COM callable wrapper. The excel technician wrote the code that loops through rows in the spreadsheet, instantiating lease objects. One of the attributes of the lease object is well formed legal description. It might describe something like the N half of the SE quarter section of Section 21 Township whatever Range whatever. Oil leases can get nested pretty deep - down to 1/128th of a section as I recall. The collection of leases is then serialized to an xml file.

The second tool lives in Arcmap. The user first loads a PLSS polygon layer into the map (downloaded from BLM). He then clicks a command and is prompted for an xml file and an output folder. The command uses the same dll to deserialize the xml file into a collection of lease objects. It then uses the legal descriptions on those leases to find the appropriate Section polygon, then recursively divides and subdivides it as needed. These polygons are written to a shapefile along with attributes that were originally in the excel spreadsheet.

I know of no standardized grammar for these legal descriptions, so the excel custodian and I worked together to make one up. (If anyone knows of one please chime in!). Normally geocoding is thought of as a process to generate point locations. This use-case illustrates a situation where geocoding produces polygons. Interpolation plays a role in both forms of geocoding. With linear geocoding points are interpolated along a line. With PLSS based geocoding sub-sections, sub-sub-sections and so on are found by interpolating along the sides of polygons to create cutting lines. Finding the corners of a polygon can be tricky - a polygon often has more than 4 vertices. Using an origin at the centroid of the polygon I found the vertex in each quadrant that is farthest from the origin.

If a standardized grammar could be established some place like the BLM could publish a geoprocessing (GP) service that converts legal descriptions into polygons. This GP service could then be used by others to write web apps that, for example, allow users to copy and paste a legal description into a text box, push a button and have a polygon appear on a map.