County GIS programs have made real progress over the past fifteen years. The parcel base layer, once maintained on paper and updated through hand-drawn revisions, is now a live digital dataset in most county GIS departments. Boundary edits, new subdivision plats, and consolidation orders feed into the parcel layer through established workflows. In many counties, the parcel layer is the most current and most reliable spatial dataset in local government.
The parcel layer knows what the parcel is. It does not know what has happened on it.
The Attribute Gap in the County Parcel Layer
A parcel feature in a county GIS layer typically carries a limited set of attributes: APN, owner name (from the assessor), address, lot size, zoning classification, and possibly assessed value and land use code. These attributes describe the property's current status as a taxable and zoned unit.
What the parcel layer does not carry, in most counties, is any of the following: permit history, violation history, inspection outcomes, or conditional use records. That information exists in county records, but it lives in document management systems, case management databases, and scanned archive files that are not joined to the GIS layer.
The result is a parcel layer that is spatially precise but informationally thin. A planner can click on a parcel in ArcGIS and see the zoning classification immediately. To see whether that parcel has any open violations, they leave the GIS, open the code enforcement system, and run a separate search. If the relevant violation was issued before the code enforcement system was digitized, they open the document archive and run a third search.
Why Local Government Data Silos Form
The structure of local government data mirrors the structure of local government itself. Building permits are issued by the building department, which runs its own permit management software. Code violations are issued by code enforcement, which uses a separate case management system. Inspections are conducted by building inspectors who may record outcomes in a field application that syncs to a server the GIS department does not have access to.
Each department acquired its software for its own operational purpose. The building department's primary concern is permit workflow: intake, review, approval, issuance, inspection scheduling, final close-out. The GIS department's primary concern is spatial data accuracy and the parcel base layer. The assessor's concern is property tax administration. These different operational purposes produce different systems with different schemas and different access models.
Integration across these systems is possible but has historically required custom development work: an ETL pipeline that pulls records from the building department's permit system and joins them to the GIS layer on a regular schedule. This kind of integration is common at larger, better-resourced counties. At smaller and mid-sized counties, the resources for custom integration work are often not available, and the data remains siloed.
What a Permit-Linked GIS Layer Enables
When permit and violation history is available as attributes on the parcel feature, a GIS query becomes capable of answering questions it currently cannot answer.
Suppose a county planning department wants to understand how many parcels in a specific census tract have open code violations that predate a 2018 rezoning. With a permit-linked layer, this is a filter query on parcel attributes: violation date before 2018, status open, parcel geometry within the census tract boundary. The result is a selection set that can be exported, mapped, or used as the basis for a compliance review.
Without permit-linked attributes, answering this question requires a manual cross-reference between the GIS layer and the code enforcement database, or a records request, or a time-consuming manual search. The question is answerable in principle but not practically answerable without hours of work.
The same applies to questions that arise constantly in planning department operations: which parcels in a proposed development area have unresolved stop-work orders? Which parcels along a corridor have permits that were issued but never finally inspected? These questions require the intersection of spatial data and document data, and that intersection currently requires manual effort at most counties.
The Archive Integration Problem
For current permits, the data integration problem is tractable: the building permit system generates structured digital records, and an ETL pipeline can join them to the GIS layer on a nightly or weekly schedule. Some counties have this working.
For historical permits, the problem is different. Permits issued before the department's current software was deployed exist only in the archive, as scanned PDFs. They do not appear in the permit management system. They do not appear in a GIS layer query that joins against the permit management system. The historical record is absent from the integrated view.
This is the archive integration problem: the integration of current records into the GIS layer is an engineering problem of moderate difficulty. The integration of historical records requires first extracting structured data from scanned documents, then joining that extracted data to the parcel layer. The first step is the hard part.
Geometry Versus Attribute Joins
Adding permit history to a parcel GIS layer is an attribute join, not a spatial join. The permit record is linked to a specific parcel by APN (or by address, if APN is absent), not by spatial geometry. The geometry of the parcel is already known from the parcel base layer. What the permit record adds are non-spatial attributes: permit number, issue date, type, status, and so on.
This distinction matters for schema design. An attribute join adds columns to the parcel feature's attribute table. If a parcel has multiple permits, this becomes a one-to-many relationship: one parcel row to many permit rows. This requires a related table structure rather than a flat attribute addition, because a flat attribute structure can only hold one value per attribute per parcel row.
In practice, this means the GIS implementation uses a related table for permits and violations, linked to the parcel feature class by APN. A GIS user clicking on a parcel sees the summary attributes in the main feature, and can open the related table to see the full permit and violation history. This is standard GIS database design and works in both ArcGIS and QGIS without custom development.
What This Requires on the County Side
To receive a permit-linked GIS layer as a deliverable, a county needs its parcel layer available in a standard format (GeoJSON, Shapefile, or similar) for matching the extracted permit records. The parcel layer's APN field needs to be current: an outdated parcel layer with stale APNs will produce join failures for recent permit records that use updated APNs.
For a pilot evaluation, the requirement is a current parcel GeoJSON or Shapefile export of the target area, plus access to the document archive files for the permit and violation records in scope. The extraction and join runs against those inputs. The output is a related table in the county's preferred format (GeoJSON with related tables, or a geodatabase if the county uses ArcGIS as its primary platform), ready to load into the existing parcel map.
This is not a replacement for the county's permit management system. The permit management system handles workflow: intake, review, approval, active case management. The extracted archive layer handles history: making the pre-digital record visible and searchable within the GIS environment. The two serve different purposes and coexist.