geo-l2-nyc-park-symdiff

Analyst notes

Description

This task tests a multi-step geometric-ops chain on two polygon layers stored in a single GeoPackage. The agent has to compute a symmetric difference, cluster the resulting patches into connected components so that adjacent gain/loss pairs from a single shifted park merge into one group, classify each group by which side(s) contributed, and emit a label anchor that is guaranteed to fall inside the group's geometry. The hidden gotcha is that the input GeoPackage is in a projected metric CRS (NY State Plane) while GeoJSON output must be WGS84 by RFC 7946, so the agent has to do area math in the projected CRS but reproject before writing.

Approach

1. Open the GeoPackage and read both park layers, noting that they share a projected metric CRS.
2. Compute the symmetric difference between the two layers and break it into connected components, with a small buffer-merge if needed to bridge sub-metre topology gaps along shifted-park boundaries.
3. Classify each component by which side contributed to it (`parks_official`, `parks_osm`, or `both`) and collect each component into a single MultiPolygon.
4. Compute a label-anchor point per group using a representative-point method that is guaranteed to lie inside the geometry, not a plain centroid.
5. Reproject both feature collections to WGS84 and write them as GeoJSON with the `source` column and matching row order across the two files.

Pitfalls

• Reaching for `geometry.centroid` instead of a representative-point method, so anchors of concave or multi-part clusters land outside their parent geometry and the anchors-inside check fails.
• Skipping the cluster-collect step and emitting one row per individual symdiff polygon, which roughly triples the row count and fails the heavily weighted cluster-count subcheck.
• Computing only `A.difference(B)` (or only `B.difference(A)`) and missing one side of the symdiff, which collapses count, area, and IoU subchecks together.
• Mislabelling the `source` attribute, for example tagging every cluster as `both`, which fails the source-distribution subcheck.
• Writing GeoJSON in the projected CRS (EPSG:6539) instead of WGS84, which docks the CRS subchecks when the CRS is declared, and fails the area and IoU subchecks outright when the projected coordinates are written with no CRS member at all.
• Forgetting to coerce single Polygon clusters to MultiPolygon, which fails the geometry-type subcheck.

Map

Recent runs task v3