Sharing property data as a shapefile: an export checklist
Keep parcel fields understandable when sharing a shapefile. Check shortened names, missing values and companion files with a copyable handoff worksheet.
Before sending a property shortlist as a shapefile, reopen the exported package and check its fields against the original. Agree on short field names, explain missing values, and include the companion files. A map that opens successfully can still have attributes that no longer mean what the recipient expects.
This guide is for acquisitions teams passing preliminary property research to a GIS analyst or civil consultant. The worksheet below is an editorial handoff tool, not a survey standard or a claim about any particular product's export behavior.
Agree on the receiving workflow
Ask which application and format the recipient can use. Also ask what they need to do with the data: identify candidate parcels, reproduce a filter, or join research notes to another table. That answer determines which fields must survive the exchange.
If both applications support it, consider GeoPackage. OGC describes it as an open, SQLite-based container for geospatial data, including vector features. A different container still needs an import check; support for a format does not guarantee that every application preserves every attribute or presentation choice. OGC GeoPackage
Keep an untouched copy of the original research export. Make the delivery package separately so a recipient's compatibility requirement does not alter your working source.
Give short field names explicit meanings
Shapefile attribute names have a ten-character limit. Esri documents that long names are truncated on export. Do not assume a shortened name is self-explanatory or predict how a particular exporter will resolve similar names. Inspect the actual output. Esri field-name guidance
For example, two source fields called assessment_year and assessment_date need distinct meanings in the receiving table. The following is a proposed mapping for a hypothetical shortlist, not output from a tested export:
parcel_identifierbecomesparcel_id: source parcel identifier, stored as text.assessment_yearbecomesassess_yr: year associated with the assessment record.assessment_datebecomesassess_dt: date supplied by the source, if available.research_notebecomesnote_ref: reference to a separate note in the delivery package.
The last mapping changes what the field contains. Document that choice and provide the referenced notes. Do not put a long note into a shorter field and assume the recipient received the full explanation.
Check values as well as headers
Esri's shapefile-output documentation describes limitations involving nulls, date/time values and numeric attributes. Some ArcGIS geoprocessing conversions substitute zero for missing numeric values; other cases use different substitutes. Check the tool and output instead of treating every zero as a measured value. Esri output considerations
For this handoff, choose sample records deliberately: one with a missing value, one with a long note, and any record whose interpretation drives the shortlist. Write down what each should contain before export, then compare after reopening.
A missing improvement value, for example, should remain distinguishable from a recorded zero. If the delivery format cannot preserve that distinction directly, agree on a separate status field and its definitions. Keep the original value in the source archive. Neither value alone establishes whether a building exists or what a property is worth.
Send the package and a small acceptance record
A shapefile consists of companion files. The core geometry, index and attributes are stored in .shp, .shx and .dbf; coordinate-system information can accompany them in .prj. Package the related files together rather than sending only the .shp. Esri component reference
Copy this worksheet into the delivery folder:
Property shortlist handoff
Project:
Source agency or supplier:
Source URL / dataset version:
Retrieval date:
Export date, application and version:
Receiving application:
Coordinate reference system:
What one row represents:
Stable record identifier:
Source row count:
Export row count:
Reason for any count change:
Field mapping file:
Missing-value definitions:
Units for numeric fields:
Separate notes file and matching key:
Sample records checked after reopening:
1. Identifier / expected value / observed value:
2. Identifier / expected value / observed value:
3. Identifier / expected value / observed value:
Known omissions or unresolved differences:
Recipient import checked by / date:
Count differences need an explanation. A deliberate subset is fine; an unexplained loss needs investigation before the shortlist is used. Ask the recipient to confirm both the map location and the sample attributes in their application.
Keep this export check alongside the desktop site-screening checklist. Where acreage matters, retain the source and definition for each area field using the deeded-versus-GIS acreage guide. The next person should be able to trace a number without reconstructing your research from the map image.