utah-plss-point-gcdb: _700 columns labeled _100

[jidanni]

The western edge of a PLSS township has PLSS point IDs _100, and the eastern edge are _700.

Thus https://opendata.gis.utah.gov/datasets/utah-plss-point-gcdb/explore data has a big bug. The 7 loops back around to 1 just a little too fast.

ogr2ogr bad.csv -dialect SQLITE -sql \
   'SELECT XCOORD,POINTID FROM PLSSPoint_GCDB
   WHERE POINTID LIKE "UT260060S0020E0__00400"
   ORDER BY XCOORD' UtahPLSSGCDBPoints_7983.gdb.zip
cat bad.csv
XCOORD,POINTID
-111.75200536,UT260060S0020E0_200400
-111.73299682,UT260060S0020E0_300400
-111.67550572,UT260060S0020E0_600400
-111.65744916,UT260060S0020E0_100400 #Wrong.

That last line should be

-111.65744916,UT260060S0020E0_700400

which is often, but not always, the same as

-111.65744916,UT260060S0030E0_100400

And that's only checking one of the four sides of one township. I.e., I fear it is only the tip of the iceberg.

[seanfernandez]

I'm looking into this and will provide more information when available. Thanks

[seanfernandez]

I received this statement back from a BLM representative to help answer your question.

No issues with the "Utah PLSS Point GCDB." It's normal to see it loop back to 100's, that's how its been set up, however, if you look at township corners, there is a field "First PLSS Point Alternative Name" where you'll find the point ID with 700's. The alternative name is usually where you'll see the 700's. Like the example below, the point is for the SE corner of t07s04e and the NW corner of t08s04e. Again only for township corners.

Working with a single township would be another example of when the 700's are on the eastern edge (screenshot below).

If you have additional questions about BLM naming please reach out to Cal Norton cnorton@blm.gov Thanks!

[seanfernandez]

This is a follow up from Cal. I said only township corners have alternate names in the previous email. I was wrong, all points along townships boundaries should have alternate names with 700's. There will be times where they didn't get updated.

[stdavis]

@jidanni I'm assuming that this answers your question. Feel free to reopen this issue or open a new issue if you have further questions.

[jidanni]

That giant matrix picture you posted of quarter mile points is perfect!

In it please have a look at the position of these points, here in a simplified version of the table I posted earlier.

XCOORD,POINTIDbackpart -111.75200536,200400 -111.73299682,300400 -111.67550572,600400 -111.65744916,100400

You just can't have it both ways. You just can't have a constantly increasing X coordinate, and somehow say the final item on the list above should be called 100400, when 100400 is clearly to the left of even 200400, in the image you posted.

The PLSS point system is a very beautiful system and it's not hard to understand at all if you look at those basic materials that they provided.

Yes, points on edges of townships have two possible names, and on corners have four possible names.

But my SQL query was limited to the same single township.

[stdavis]

Thanks for the feedback, @jidanni. BLM is the steward of this data. We just distribute it. These types of questions will best be addressed by reaching out to the BLM contact that @seanfernandez posted above: Cal Norton cnorton@blm.gov.

[jidanni]

Alas I cannot

reopen the issue

because I'm a mere user.

And it's been five days and cnorton@blm.gov hasn't responded to my email. It probably went into the spam bucket.

So I think somebody else needs to try to get in touch with him for me.

Just ask him to have another look at this issue. Thanks.

[steveoh]

@seanfernandez do you mind making contact?

[steveoh]

@jidanni do you mind giving sean a phone call https://gis.utah.gov/contact/#meet-our-team

[jidanni]

Erg, I'm not in the United States so phone calls are a hassle. However, @seanfernandez: no rush. I just want to confirm to myself that I am not getting fuzzy about grids yet. (And of course save future generations from digesting erroneous data.)

(Here I am back looking at https://opendata.gis.utah.gov/datasets/utah-plss-point-gcdb/explore?location=40.291163%2C-111.691929%2C-1.00 Above this point it says is 600500. Everybody knows that 600500 couldn't be above 100440, unless 100440 is really 600440! Heading south we encounter 600400, and then 100340! (100? don't you mean 600?) And then where x00300 is, is a point with no label. Our adventure for today stops here. (But not the bad points, alas.)

Sure, you might say, "100 is an alias for..." 700 yes sometimes, but never ever 600.)

[jidanni]

@seanfernandez, here's what Cal emailed me:

Hi Dan,

Sorry for the delayed response. I looked at the PLSS points in T. 6 S., R. 2 E., SLM, more specifically, the point ID for 100440 (the one you posted a screenshot of) and it looks like there are no PLSS points in that part of the township in the BLM data (screenshot below). The only PLSS points within this township is to the west (sections 16 thru 21, 28 thru 30, 32, and 33).

That portion that you are looking at, is most likely "alternate source data," meaning the BLM didn't collect that portion of the township. I don't know the history of how this was accomplished but it looks like it needs to be updated. Because it's non-federal land, the BLM would not be able to update that portion of the township. Sean Fernandez, whom you have contacted, would be a good start to look into this.

Below is a screenshot of a row of PLSS point between sections 16 and 21, of the same township. The coordinates look legitimate.

I hope this clears things up for you.

Thanks,

[cid:9998d3b2-4f04-40b6-88c0-a9e6ece382f8]

Calvert Norton

Land Surveyor/PLSS Dataset Manager

BLM, Utah State Office

440 W. 200 S., Suite 500

Salt Lake City, UT 84101

Phone: 801-539-4140

Email: cnorton@blm.gov

[stdavis]

@jidanni Did that email from Calvert answer your original question? I'm wonder if this issue can be closed.

[steveoh]

It reads to me like we should be correcting points in that area? What do you make of it?

[stdavis]

Ping @seanfernandez

[seanfernandez]

Hello Dan, thanks for bringing these errors to our attention. A little background on the data processing that may provide some explanation to these errors and others found throughout the state of Utah PLSS data naming. Specifically in Utah County in the area you mentioned, which is an area where we (UGRC) received local section corner data from the County Surveyor and requested that the BLM include this local data in the GCDB data, which is processed and managed by the BLM. They agreed to add the data and generated the BLM point ID's to this data, which UGRC then published and is the data in question. UGRC has never made any changes to the point naming of any of these points and any errors that are found have been shared with the BLM. Each year the BLM selects specific areas to focus on fixing data and these errors are fixed at that time and a new version of the PLSS is then delivered to the UGRC to be published. We will share your findings with the BLM and encourage them to make these changes and hopefully get a new data set to publish on our site soon. We appreciate your input and will get the ball rolling. Thanks! Sean

[jidanni]

OK thanks @seanfernandez !