Reading a CRS Verification Report: A 3-Minute Walkthrough

What the report is for

Every FieldIntel design-partner engagement has the same Day-7 deliverable: a verification report that proves the auto-detected CRS configuration actually transforms the customer’s archive correctly. Not “should work in theory.” Actually does work, on real points from their real archive, plotted on a real map.

The report exists because “we’ll auto-detect your coordinate reference system” is only a defensible promise if it’s testable. Surveyors are appropriately skeptical of automated CRS detection – they’ve seen too many “modern surveying software” tools confidently produce points 800 ft offset from where they should be. The verification report is the proof the auto-detection actually worked, with the exact tolerance and the exact failure mode visible.

The report is generated by FieldIntel on the customer’s own install: built-in commands pull a random 50-point sample from their archive, auto-classify each point against its project boundary, and render both a print-ready PDF and an interactive HTML map. What used to be an afternoon of hand-run queries and screenshots is now a quick, repeatable pipeline – which is how we can put this report in front of every engagement without it slowing the timeline.

Page 1: Summary cards

The first page is the headline. Big number block: “47/50 PASS, 1/50 APPROXIMATE, 2/50 LOCAL_GRID, 0/50 FAIL.” That’s the customer-facing answer to “did the CRS profiling work.”

The four statuses, in plain language:

PASS – the point’s WGS84 lat/lon (after the auto-detected EPSG transform) lands inside the project’s polygon, with a 5-foot buffer around the polygon edge. This is the acceptance bar for state-plane archives. If 90+ percent of EXACT-tagged points pass this, the configuration is correct.

APPROXIMATE – the point is in the right area but not within 5 feet of the polygon. Three causes: the project’s KML boundary is loose (KMLs are commonly digitized to ±50 ft); the classifier put the point at the project’s centroid as a fallback when the per-point CRS couldn’t be determined; or the project has no extent polygon at all in the source data, so the point can’t be precisely verified. APPROXIMATE is not a failure – it usually means the customer’s KML data is imprecise rather than the CRS detection being wrong.

LOCAL_GRID – the point is in a coordinate system with no real geographic datum. Correctly tagged. Not plottable on the map. See the local-grid post from earlier this month for context. These appear in the table only.

FAIL – the point landed somewhere that has no plausible relationship to the project. Wrong state, wrong county, the middle of an ocean. A single FAIL is grounds for rejecting the configuration and iterating Phase 3 of the CRS detection. Don’t ship a verification report with FAILs in it.

The acceptance gate is built in: if any FAILs are present, or the PASS rate on EXACT-tagged points falls below 90 percent, the command flags it. The customer-facing PDF still renders, but the operator sees that warning before the report ever goes out – a deliberate stop sign against shipping a configuration that hasn’t earned it.

Page 2: The overview map

A single full-page map showing all mappable points colored by status, with project polygons overlaid as navy outlines, on an OpenStreetMap basemap. LOCAL_GRID points are excluded from the map by design – they have no real datum and including them would mislead.

What to look for, in order of importance:

1. Are the points where they should be? This is the headline visual. Smith Farm points should be at Smith Farm. Hopewell South points should be at Hopewell South. If the points are in the right town, you have CRS mostly right; if they’re in the wrong state, you have something fundamentally broken.

2. Are points clustered correctly by job? Each project should have its own visible cluster. If the points from one job are smeared across miles of the map, the file is probably hybrid – some points in state plane, some in local grid, the classifier averaged them.

3. Are polygon boundaries visible and tight against the points? If the navy polygon outlines surround their respective point clusters with reasonable margin, the customer’s KML data is good. If polygons are huge boxes that barely correlate with the points, the KML data is loose, which produces a lot of APPROXIMATE classifications even though the CRS itself is fine.

4. Are there any orange (APPROXIMATE) points outside their polygons? This is the most common pattern. Usually means either a loose KML boundary or a point with PROJECT_CENTROID location_type (the classifier punted on per-point CRS and fell back to the project centroid). The right remediation depends on which.

5. Are there any red (FAIL) points anywhere? A red point in the wrong state means there’s a CRS misclassification somewhere – probably an EPSG code mixup. Iterate Phase 3 before delivering the report.

Page 3: The per-point table

Six columns: Pt #, Job #, Original (E,N), WGS84 (Lat, Lon), Distance to polygon (m), Status. Status column is color-coded with the same palette as the map.

Useful patterns to look for:

All points from one job are APPROXIMATE. Usually that job has a loose or missing KML. Check the customer’s source data; consider asking for a tighter project boundary if available.

All points from one job are FAIL. That job’s CRS was misclassified. Reconcile the classifier’s detected_epsg with what the customer’s CAD records say the job actually was.

Points are spread across PASS and APPROXIMATE within one job. Often a custom-scale-factor case. Some points are close to the project origin (PASS) and some are far from it (APPROXIMATE because the scale factor compounds with distance).

Distance values bunched around a specific number. If every APPROXIMATE point is exactly 12.4 meters from its polygon, that’s a translation – a fixed offset in N or E or both. Often a units mismatch (US Survey Foot vs International Foot) or a state-plane datum mixup (NAD27 vs NAD83). Reconcile and re-run.

Distance values proportional to point’s distance from project centroid. That’s a scale factor. Custom Helmert pair territory. See post 1.

Page 4: Caveats + Next steps

The boilerplate page. Three caveats are always there:

• Local-grid jobs are correctly tagged but don’t appear on the map.
• DWG files (if any in the archive) are not yet ingested.
• Project boundaries come from KML files; loose KMLs can produce APPROXIMATE statuses on points that are absolutely correct.

These are not failure modes; they’re known limitations the customer needs to know about up front. We document them so there’s no surprise later.

The “Next steps” section is the call-to-action. Customer signs off (or pushes back) within 3 business days. If sign-off, the configuration is deployed to the production install and the first weekly check-in is scheduled for Day 14 of the engagement.

The companion HTML view

Alongside the PDF, the same cohort renders to a self-contained HTML file with an interactive Leaflet map. Customer opens it in any browser; pans and zooms freely, clicks individual points to see WGS84 + original coords + status, clicks project polygons to see job number + name. The HTML is ship-it-and-forget – one file, includes a copy of all the cohort data, no API key needed.

Most customers we’ve worked with prefer the HTML companion for the “show this to my partner” conversation and the PDF for the “save it in the project file” archival use case. We send both.

Acceptance criteria, restated

Before sending this report to the customer:

• Zero FAILs across all 50 points.
• 90+ percent PASS on EXACT-tagged points (the LOCAL_GRID and PROJECT_CENTROID points are excluded from this denominator – they aren’t testable against polygons).
• The map looks reasonable – points are in their projects’ towns, polygons are visible, no obvious clustering anomalies.
• Per-point table doesn’t have systematic patterns suggesting an undetected transformation.

If any of those fail, iterate the configuration before delivering. The customer’s first impression of FieldIntel is whether the CRS profiling actually worked. A report that says “47/50 PASS, 0 FAIL” is a different sales conversation than “32/50 PASS, 4 FAIL.”