When Apaluma links extracted permit records to parcel geometry, it is not working with GeoJSON or a modern parcel database in every case. A meaningful portion of county parcel data in the jurisdictions where we operate exists in formats that predate current open standards by a decade or more. Some of that data is in Esri personal geodatabases, some in older Coverage format exports, some in CAMA system extracts that have never been properly spatially referenced. A smaller but real subset is spatial data stored as coordinate pairs in spreadsheets, with no geometry file at all.
Building an extraction pipeline that can output a parcel-linked GIS layer requires being explicit about what parcel data is actually available and what it takes to work with each format. This is not a glamorous problem, but it directly affects whether a county can use the output of an extraction pipeline without a separate data conversion project.
The formats you actually encounter
ESRI Shapefile remains the most common parcel format in smaller counties across the Mountain West, and it is a known quantity. GDAL/OGR handles Shapefile reliably. The constraints are well-documented: 10-character field name limits, no support for null values in some field types, 2GB file size limit per component file, and the notorious multi-file format structure that breaks when any of the constituent files is missing or misnamed. Shapefiles from county GIS departments frequently arrive with inconsistent coordinate reference system definitions, either missing .prj files entirely or containing projection parameters that do not match the actual coordinate system of the data. The first diagnostic step with any Shapefile is to verify the projection, not assume it from the filename.
Older Esri Coverage format (the predecessor to Shapefile) appears occasionally in archives that predate the early 1990s shift to Shapefile dominance. Coverage format stores feature classes as directories containing separate files for topology, attributes, and geometry in ARC/INFO format. GDAL can read Coverage format, but the topology handling is different from simple Shapefiles: a Coverage stores polygon topology explicitly, including shared edges between adjacent parcels. Converting Coverage to Shapefile or GeoJSON typically means losing the explicit topology information, which is usually acceptable for attribute-join purposes but worth knowing.
Esri File Geodatabase (GDB) format is common in counties using ArcGIS Desktop or ArcGIS Pro actively. GDB is a directory-based format with better support for large datasets, field types, and domains than Shapefile. The open-source OpenFileGDB driver in GDAL provides read access to most GDB content, with some limitations on specific geodatabase features. For extraction pipeline purposes, GDB is a step up from Shapefile and generally imports cleanly.
Personal Geodatabase (MDB format, an Access database underlying structure) is a legacy format from the early 2000s that some counties have not migrated away from. Reading personal geodatabase content requires either Esri software with the appropriate license or GDAL built with MDB support, which has additional dependencies. Personal geodatabases also have a 2GB size limit for the entire database, which some larger county parcel datasets exceed. Counties holding data in personal geodatabase format should be considered candidates for conversion as part of any data infrastructure project.
CAMA system exports and the attribute-geometry separation problem
Computer-Aided Mass Appraisal systems are the authoritative source for parcel attribute data in most counties. CAMA systems contain the assessor's parcel records: ownership, legal description, assessed value, land use code, acreage, and building characteristics. The parcel geometry layer in the county GIS often exists as a separate dataset maintained by a different department (GIS or surveying), synchronized to the CAMA system through the APN as the join key.
When extraction pipelines need to join permit records to parcels, they are sometimes joining to a CAMA export directly rather than to the GIS geometry layer. A CAMA export is typically a flat file (CSV, fixed-width text, or a proprietary format like AS400 flat-file or a dBASE .dbf file) containing attribute records keyed by APN, with no geometry. To produce a spatially enabled output, the pipeline needs to join the CAMA export to the GIS geometry layer using the APN, then join the extracted permit records to the combined dataset.
The three-way join (permit record to CAMA attributes to parcel geometry) is where APN format inconsistency causes the most failures. If the CAMA export uses APN format "070430021000" and the GIS geometry layer uses "07-043-00210," the join fails silently without a normalization step. The permit record may be correctly extracted from the scanned document with APN "07043210" (a third variant), requiring a second normalization step. Handling this triple-format problem requires defining a canonical normalized form and running all three datasets through normalization before any join is attempted.
Spatial data in spreadsheets
Less common but more problematic is parcel data stored as point coordinates in a spreadsheet, typically with columns for APN, address, latitude, and longitude. This format appears in counties that had no GIS capability at the time of data entry and stored parcel reference data in whatever was available, often a shared Excel workbook or a CSV from an early property database.
Point coordinates for parcels are usually centroids geocoded from the parcel address. The coordinate accuracy varies by how the geocoding was done: county-level address geocoding from the late 1990s may have accuracy of several hundred meters, which is adequate for identifying the correct parcel in a non-dense rural area but may be insufficient in a platted subdivision where adjacent parcels are narrow. A coordinate that is 200 meters off may fall on a neighboring parcel rather than the correct one.
For extraction pipeline purposes, point-coordinate parcel data can be used as a fallback join mechanism when APN matching fails. The extracted permit record's address is geocoded, and the resulting coordinate is compared to the parcel centroid coordinates in the spreadsheet. If the geocoded address falls within a reasonable distance of a single parcel centroid, the match is made. If multiple parcel centroids are within that distance, the match is ambiguous and routes to human review.
We would not recommend relying on coordinate-based matching as a primary join strategy for a county that has a proper GIS geometry layer. But for historical records in jurisdictions where the parcel GIS layer coverage is incomplete (pre-GIS era subdivisions, older rural parcels without updated plat records), it is a useful fallback that prevents those records from being dropped entirely.
Coordinate reference system issues in practice
Any GIS data interchange involves a coordinate reference system (CRS), and the most common silent failure mode in parcel data handling is a CRS mismatch that is never detected because no visual check is performed. Parcel data arrives in a projection, and the extraction pipeline outputs data in a projection. If those projections differ and the mismatch is not caught, the output layer and the parcel layer will be offset from each other on the map, sometimes by a small amount that looks like precision error, sometimes by thousands of meters.
Mountain West counties use a mix of geographic coordinate systems (GCS: NAD83 or older NAD27) and projected coordinate systems (State Plane with county-specific zones, UTM zones 12 and 13, or county-specific local projections defined decades ago). NAD27 and NAD83 differ by a shift of up to approximately 200 meters depending on location, which is enough to cause visible offset on a parcel map. A parcel boundary layer in NAD27 that is displayed over aerial imagery in NAD83 will appear shifted.
The correct handling is to identify the CRS from the source data's .prj file or metadata, reproject explicitly to a defined output CRS (WGS84 for GeoJSON delivery, or a specified state plane zone if the county requests delivery in a local projection), and verify the result by spot-checking a known location. This is a step that should be documented in any extraction pipeline configuration rather than assumed to be handled automatically.
What to ask for when requesting parcel data from a county
When working with a county to configure an extraction pipeline, the parcel data request should be specific. "The county parcel layer" is ambiguous. What you actually need is: the most recent parcel polygon layer with APN attributes, in the county's native GIS format and coordinate reference system, along with the .prj file if Shapefile, plus the CAMA attribute export keyed by APN if the GIS layer's non-spatial attributes are incomplete. Requesting the data dictionary or schema documentation for both layers simultaneously prevents a separate follow-up request.
Not every county GIS department has this data in a single place or in a readily exportable form. Some have the geometry layer maintained by one department and the CAMA export accessible only through a different department's IT contact. Mapping these data ownership questions at the start of a pilot setup is less interesting than working on extraction itself, but it is the step that determines whether the output layer is actually deliverable. Format translation is solvable. Data that does not exist or cannot be obtained is not.