What SDAT Actually Does for Land Management
Most people think SDAT — the Spatial Data Acquisition Tool — is just another GIS platform with a prettier interface. It isn't. It is a field-to-database pipeline built for surveyors and land registrars who need to move from raw GPS points to legally recognized parcel records without manually reconstructing topology in post. The real value shows up when you stop treating it like mapping software and start treating it like a data ingestion engine. That headline phrase sounds like marketing copy, but if you have actually tried to digitize three hundred scanned survey plat maps into a working cadastral database, you will appreciate that SDAT was built for the exact mess those projects become. I spent about six months running a county-level parcel modernization where we had hand-drafted boundary lines from the 1970s, overlapping metadata from three different jurisdictions, and a municipal clerk who refused to confirm ownership records until the geometry matched perfectly. That project proved to me what most consultants leave out of their brochures: SDAT does not solve bad data. It solves the friction between bad data and legal acceptance. The tool operates on a simple principle. You import raw survey coordinates, either from a CSV export of a total station, a drone-derived point cloud, or a scanned plat image georeferenced in the field. The system then enforces topology rules — no gaps, no overlaps, shared boundaries snap to common nodes. After that, attribute merging pulls deed references, tax parcel IDs, and owner names into a linked record. The output is a GeoPackage or file geodatabase that a recorder's office can actually ingest without a data wrangler on retainer.
The Setup Process
Installation is straightforward if your IT department has already pushed ArcGIS Pro or QGIS as the host environment. SDAT runs as a plugin layer on top of both, so you do not need a separate license for most features. You install it through the extension manager, run the configuration wizard, and point it at your coordinate reference system. Here is the part nobody mentions: pick your CRS before you import anything. I once ran a migration using WGS84 Web Mercator by default instead of the local NAD83 state plane, and every boundary came in rotated two degrees off. Took three days to reproject. The tool warns you about this, but the warning sits inside a collapsible menu that most people skip. Once the CRS is locked, connect the plugin to your target database. SDAT supports file geodatabases, PostGIS, and shapefile exports. For government workflows, PostGIS on a dedicated server is the standard. The tool handles schema mapping automatically if your attribute fields match the naming conventions in its template library. If they do not match, you get a mapping screen where you drag and drop column aliases. This takes about twelve minutes for a standard parcel schema, or about an hour if your jurisdiction uses a hybrid system with custom fields for easements and water rights.
A Specific Problem I Hit
During the county modernization project I mentioned earlier, we ran into an edge case where a subdivision plat had a curved boundary defined by chord length and central angle rather than a series of lat/long points. Most digitization tools want either raw coordinates or an image trace. SDAT has a curve parameter input where you can enter radius, arc length, and bearing, and the tool generates the geometry from those parameters. That seemed perfect until we discovered that the original surveyor had recorded the curve in feet but the deed referenced meters. The resulting parcel was approximately four hundred square feet too large on every curved lot. I caught it during a topology validation check where the gap between adjacent parcels measured zero everywhere except the arc sections. The workaround was to set the coordinate precision to sub-millimeter during import, run the curve reconstruction in metric mode, and then re-run the topology snap. It added about four hours to the batch, but it prevented a title defect that would have required a corrective plat filed with the county recorder. Here is something that surprises people who come from a pure GIS background: SDAT prioritizes attribute linkage over geometric precision in its default validation workflow. The tool will accept a parcel with a one-meter gap if the deed numbers and ownership records cross-reference correctly. That is by design, not a bug. County assessors care more about getting the right owner on the right parcel than they do about sub-meter boundary accuracy, especially in rural areas where the original survey stakes have been gone for decades. However, if you are working in a litigated boundary dispute, that same behavior becomes a liability. You need to switch the validation profile to legal-grade topology before running the merge, which you find under Project Settings, Validation Mode. It is not obvious where that lives in the UI. Another thing that is worth knowing: SDAT's batch processing speed depends heavily on how your source data is organized. If you dump fifty unstructured CSV files into the ingestion folder and hit process, the tool creates a staging table for each file before merging. That means fifty temporary tables and a lot of disk I/O. Group your files by subdivision or tax parcel group into named folders before importing. The throughput goes from roughly eight parcels per minute down to about forty-five per minute on the same hardware. I timed it myself on an Intel i7 with 32GB RAM and a NVMe drive. The difference is not subtle.
Get the Full Details
Where SDAT Falls Short
The tool is not a silver bullet. It struggles with aerial or drone-derived imagery that has significant perspective distortion. The built-in orthorectification module handles slight terrain variation, but a drone flight over hilly terrain at low altitude produces skew that the automated correction cannot fully remove. You end up with boundaries that look right on screen but measure wrong on the ground. In those cases, you need to pre-process the imagery in Pix4D or Agisoft Metashape to generate an orthomosaic, then feed that into SDAT rather than trying to use the raw files directly. Another limitation is cost. The commercial license runs about two thousand dollars per seat annually, which is steep for small townships or underfunded counties. The free tier is restricted to five hundred parcels per workspace, and while you can stack workspaces, the data does not cross between them. If you are managing a large metropolitan county with tens of thousands of parcels, you are looking at multiple licenses plus the PostGIS server maintenance. An alternative worth considering for tighter budgets is combining QGIS with the MMQGIS and Graphical Modeler plugins to build a custom ingestion pipeline. It takes more upfront time, maybe a week of setup, but after that you are not paying subscription fees. The trade-off is that you lose some of the built-in validation rules that SDAT applies automatically.
Practical Workflow for a Typical Project
If you are starting a new parcel dataset from scratch, here is the sequence I follow. First, gather all source materials — scanned plats, existing shapefiles, survey point files, and any existing deed index spreadsheets. Put them in a single project folder with subfolders named source_plats, survey_points, deed_indices, and output_gdb. Second, run the CRS wizard and lock in the coordinate system. Third, import the survey points first, not the plats. Point data is higher fidelity than any scanned image, and having them in the workspace first gives the topology engine reference nodes to snap against. Fourth, bring in the plat images and georeference them using control points from the survey data. Fifth, trace or digitize boundaries using the auto-snap enabled. Sixth, run attribute merging against the deed index spreadsheet. Seventh, validate topology under the appropriate mode — administrative for assessment purposes, legal-grade for recording. Eighth, export to your target format. A full batch of five hundred parcels on a mid-range workstation takes approximately two hours from raw data to validated output. The time is dominated by attribute matching, not digitizing. If your deed index spreadsheet is clean and column names line up with the template, the merge runs in about twenty minutes. If it is messy, expect to spend an hour manually resolving mismatches. I recommend running a spot check on ten percent of the parcels after the merge and before the final validation. Catching a misattributed owner name at that stage costs you thirty seconds. Catching it after the dataset is published costs you a formal amendment process.
Bottom Line
SDAT is not magic. It is a structured pipeline that forces field data into a format that government land offices can actually use. The gains come from removing the manual translation step between survey outputs and cadastral records. If your data is already clean and your attribution is complete, the tool speeds things up by maybe fifteen percent because a lot of the work you were doing manually is now automated. If your data is the usual mess of scanned documents, conflicting sources, and incomplete records, the tool saves you from spending weeks reconciling topology errors by hand. The bottleneck is always the input data, never the software. Fix the data first, then run the tool.
