The Buffer That Overcounted

Root cause 1 - units. The CRS is in US feet, but the analyst entered 500 with no unit specified. The Buffer tool interprets the distance in the linear unit of the input's coordinate system, so 500 feet ≈ 152 m was buffered, not 500 m. The measured buffer width (~1,640 ft) confirms the buffer is in feet, not meters. A 500 m buffer should be ~1,640 ft - wait, that matches; the colleague's smaller count implies the colleague buffered 500 feet, not 500 m. So the analyst's 500-unit buffer is actually 500 ft (~152 m), and the colleague's is smaller still, or the colleague used a different unit. The key point: the distance value was unitless and the two runs used different units, producing different buffers and different counts.

Root cause 2 - geometry/selection. Select Layer By Location with 'intersect' counts points touching the buffer polygon. Points exactly on the boundary, duplicate stacked points, and lake points all affect the count. The 40 coincident points are counted as 40 households when they may be one; the 15 lake points are physically implausible households but still selected.

Root cause 3 - CRS mismatch risk. If any layer were in a different CRS, buffer distances would be wrong; here all are State Plane feet, so the unit confusion is the dominant factor.

Corrected workflow:

1. Fix units explicitly. Either (a) buffer in the layer's native feet: 500 m × 3.28084 = 1,640.42 ft, entered as 1640.42; or (b) project the main line to a metric CRS (e.g., a UTM zone) and buffer 500 m there. Never leave the distance unitless when the target unit differs from the CRS.
2. Set the buffer to the correct geometry. Use a line buffer with flat or round end caps as appropriate; for a main line, round caps are usual. Confirm the output width by measuring the buffer polygon.
3. Handle duplicate points. The 40 coincident points are a data artifact. Decide with the data owner whether they represent 1 household or 40; if 1, dissolve by coordinate or by a household ID before counting, or deduplicate. Report the deduplicated count and disclose the adjustment.
4. Handle lake points. 15 points in a lake are implausible households; either correct their locations or exclude them with a selection (e.g., erase by a water polygon), and document the exclusion.
5. Use 'within' or 'intersect' deliberately. For 'within 500 m,' use within a distance semantics (Select By Location 'within a distance' of the line with 500 m) rather than buffering then intersecting, which avoids boundary ambiguity - or keep the buffer but use 'intersect' consistently and state the boundary rule.
6. Report the count with method notes: unit used, deduplication, exclusions, and the buffer geometry. The defensible number is the one whose method is documented, not necessarily the larger or smaller one.

The gap is too large to be explained by boundary effects alone. A 55% difference indicates a systematic methodological difference (units, buffer width, or selection predicate), not random noise. This means the original 3,180 figure is not reliable and should not be published as-is; it is the product of an undocumented unit assumption.

Communication:

• State the corrected count with the method: 'Households within 500 m of the proposed main, buffered in feet (1,640.42 ft), using Select By Location (within a distance), after removing 40 duplicate records and 15 points in water: N households.'
• Disclose the sensitivity: the count changes materially with buffer width and deduplication, so present a range or a small table (e.g., 500 m vs 500 ft; with/without duplicates) rather than a single number.
• Flag the data-quality issues to the data owner (duplicate coordinates, points in water) so they are fixed at the source.
• Avoid presenting the number as precise to the household; round and label it as an estimate.

The judgment: a result whose method cannot be reproduced is not evidence. The analyst should own the error, publish the corrected method, and let the range speak.