Data was the biggest issue needing addressed within the County GIS, as I am sure it is in most places; more especially at the County and small municipal level. In short, it was a disaster. Data was inconsistent, without structure, had no restraints to ensure integrity. There was no architecture. There was no maintenance or adherence to best practices associated with maintaining a geo-database, or any sort of database really.
The extent of the damage necessitated quite a bit of rebuilding and will need discussed through multiple postings. Irritated by the revolving door associated with GIS positions at the County, that is where the inconsistency began. The recent departure of the previous GIS Manager and GIS Coordinator at approximately the same time compounded the problem, along with generally uncaring and incompetent GIS analysts. One of the stories told to me, was of a previous GIS analyst simply guessing the location to draw new parcels. This individual manually drew parcels on top of parcels, vaguely resembling the original survey drawing, and only generally in the correct area. He got it in the right County, at least.
Defining a framework was the first order of business. ArcGIS was the platform, the architectural choice rather simple. I was already familiar with the title by Nancy von Meyer, “GIS and Land Records: The Parcel Data Model.” It was the first book purchase I made after accepting the position. I did not have any experience with Land records outside of academia, but was very interested in the topic, and that book turned out to be the perfect starting point. Indeed, it referenced the ArcGIS Land Parcel Data Model, which I quickly located on the Library of Libraries, the Internet. With a plotter at my disposal, I printed a gigantic poster of the model for further study.
Upstairs at home with a whiteboard, the poster, and a lot of spare time in the evenings, I examined this poster in detail and made extensive notes. It was not the most efficient structure or architecture, but that was easily remedied, drawing on prior experience managing data structures. The main thing that I found so astonishing was that the model recommended defining nearly every data type as a string. Why would anyone in his or her right Database Administrator mind do that, except when necessary?
After I worked everything out on paper, I set about defining the first task. Each of the layers recommended required a definitive framework from which to base any sort of delineation, and that framework required control points to justify and maintain its position and integrity. The Office of the Recorder had all of the records related to Land Corner surveys, but a solid reference would be needed to ensure horizontal and vertical accuracy. Accessing the Missouri Spatial Data Information Service (MSDIS), I acquired the most recent Ground Control Points layer, a recently published layer for the Public Land Survey (PLSS), and was ready to begin creating new GIS data.
There was no need to change anything in the Ground Control Points layer, so it was imported to the database as is. The Land Corners layer was another story. The documents at the Office of the Recorder provided most of the information needed to accurately locate each of the Land Corners; although not all. The State of Missouri had been promoting restoration and location of Land Corners for a few years, and some of them contained true GPS coordinates. Those restoration and re-establishments done prior to 2000 rarely had them though, but did contain enough information to plot them with relative accuracy. The older documents were no help at all though, as they relied on measurements from odd little landmarks like bushes and trees.
The final structure of the Land Corners layer for the Geodatabase was relatively simple and contained seven essential fields for each record, and customized to ensure minimal space usage in the database. CORNERTYPE uses a numeric value and a Coded Value Domain (i.e., a Lookup Table) to restrict the naming possibilities and ensure continued integrity; as well, requiring uniqueness in some cases, and not permitting <NULL>. Most other fields for this feature are numeric too; even that for the Missouri Department of Natural Resources (MoDNR) Document Number. It is only a number after all. There are only two text fields (CORNERINDEX and CORNERNAME) in this layer, since the data would be a mix of alphanumeric characters derived from the Corner Master Index Grid diagram (left). These fields were limited to the number of characters permitted though. More information about the file layout is in the Metadata. That was the final touch, to begin documentation on all of this new and improved data and using Content Standard for Digital Geospatial Metadata as outlined by the Federal Geographic Data Committee. The final resting place for the feature would be within a Feature Dataset dedicated to Public Land Survey System data only and updated only when provided new information from MoDNR or associated filings by surveyors at the Office of the Recorder.
After creating the new feature, the only thing left to do was add the points through ArcGIS Map, using the data provided on the MoDNR document. This enabled me to move to the next phase of correcting the PLSS downloaded from MSDIS; that is for another post though.
Below are links to access the two new features created out of this process; the beginning points, as it were.
Ground Control Points Feature (KML)
- Info Sheet for Ground Control Points Metadata
- Info sheet for Land Corners Metadata
Coming next in the series … more data restructuring and implementation related to the Public Land Survey System.