geo-l2-nyc-park-symdiff

Rerun

Let me start by understanding the problem and the data available. I need to:

1. Read the GeoPackage `nyc_parks.gpkg` to see its layers
2. Understand the layers (official parks and OSM-derived parks)
3. Find areas where only one side claims park land (disagreement)
4. Merge adjacent disagreement patches
5. Create a MultiPolygon per merged group with a `source` attribute
6. Create label-anchor points strictly inside each group's geometry

Let me start by exploring the data.

Let me understand the problem:

1. We have two layers: `parks_official` and `parks_osm` from the GPKG.
2. We need to find areas where they disagree - i.e., areas claimed by exactly one side.
3. Adjacent disagreement patches should be merged if they are adjacent (touching).
4. Each merged group gets a `source` attribute: `parks_official`, `parks_osm`, or `both`.
5. For each group, we need a label-anchor point strictly inside the group's geometry.

Wait, let me re-read. The task says:
- "Every patch claimed by exactly one side" - so areas that are in official but not in OSM, OR in OSM but not in official.
- "adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two"

So if a park polygon is shifted, the area that was in official but not OSM (loss) and the area that's in OSM but not official (gain) are adjacent (they share a boundary). We need to merge adjacent disagreement patches even if they come from different sources.

So the approach:
1. Compute the symmetric difference: areas that are in official xor osm.
2. But actually we need to identify patches. Let me think more carefully.

Actually, let me think about what "disagreement" means. If a park is in official but not OSM, that's a disagreement (source=parks_official). If a park is in OSM but not official, that's a disagreement (source=parks_osm). If both agree, that's not a disagreement.

But the key wrinkle: "adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two." So if park A in official is shifted relative to park A in OSM, then:
- The area in official but not OSM is a patch (source=parks_official)
- The area in OSM but not official is a patch (source=parks_osm)
- These two patches are adjacent (touching)

These adjacent patches should be merged into one feature. But what source do they get? The instruction says the source attribute should be exactly one of the three values. If we merge an official-only patch with an OSM-only patch, that merged area is claimed by both? No, it's claimed by exactly one side in each part. But merged together...

Hmm, let me re-read: "One MultiPolygon per merged group with a source attribute whose value is exactly one of parks_official, parks_osm, or both"

So for a merged group that contains both official-only and OSM-only patches, the source would be... both? But the merged group is the union of disagreement patches. If we merge an official-only patch with an adjacent OSM-only patch, the merged polygon has parts that are official-only and parts that are OSM-only. The group as a whole would have source "both" since it has areas from both sides.

Wait, but the task says "every patch claimed by exactly one side" and then merge adjacent ones. So the result should be a set of merged groups, where each group might contain patches from one or both sources.

Let me think step by step:

1. Compute the symmetric difference: `off.difference(osm)` gives official-only areas. `osm.difference(off)` gives OSM-only areas.
2. These are individual polygons. Adjacent ones (regardless of source) should be merged.
3. Each merged group gets a MultiPolygon geometry and a source attribute.

What about areas claimed by both? Those are not disagreement patches. But if a merged group contains both official-only and OSM-only patches adjacent to each other, the merged group's source is "both" because it has contributions from both sides.

Actually, let me re-read more carefully:

"I need every patch claimed by exactly one side, with adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two."

So the basic unit is a "patch claimed by exactly one side." These patches are then merged if adjacent. The merged result should be "one MultiPolygon per merged group."

"source attribute whose value is exactly one of parks_official, parks_osm, or both"

So for a merged group:
- If all original patches in the group are official-only → source = "parks_official"
- If all original patches in the group are OSM-only → source = "parks_osm"
- If the group contains both official-only and OSM-only patches → source = "both"

Let me implement this.

Approach:
1. Compute `off_only = off.difference(osm)` → polygons only in official
2. Compute `osm_only = osm.difference(off)` → polygons only in OSM
3. For each, explode into individual polygons (or multipolygons)
4. Merge adjacent polygons across both sets
5. Assign source attribute

Let me use geopandas and shapely for this.

Actually, a simpler approach using overlay/dissolve:

1. Compute off_only = gpd.overlay(off, osm, how='difference') → areas only in official
2. Compute osm_only = gpd.overlay(osm, off, how='difference') → areas only in OSM
3. Label each: off_only['source'] = 'parks_official', osm_only['source'] = 'parks_osm'
4. Combine them into one GeoDataFrame
5. Dissolve/st_union adjacent polygons... 

For merging adjacent polygons, I can use `dissolve` with a connectivity graph. Or I can buffer by 0, then use unary_union... but that loses attributes.

Better approach: 
- Compute the unary_union of all disagreement polygons
- Then explode the result into individual polygons (multi -> single)
- For each resulting polygon, check if it intersects any off_only and osm_only to determine source
- But this loses the adjacency merging across different sources

Actually, the simplest approach for merging adjacent polygons while preserving multi-source info:

1. Compute off_only and osm_only as above
2. Combine them into one GeoDataFrame with a 'source' column
3. Use spatial clustering to find groups of adjacent polygons
4. For each cluster, union the geometries and determine the aggregated source

Let me use the `dissolve` approach with a custom function, or use `unary_union` and then spatial join back.

Another approach using `shapely` and `topology`:
1. Compute the unary union of all disagreement patches
2. Explode into individual polygons
3. For each resulting polygon, check what source(s) contributed to it
4. If a single polygon has both sources, that means the original polygons from different sources overlapped? No, off_only and osm_only should be disjoint (they come from difference operations).

Wait, off_only and osm_only are disjoint by definition - off_only is in official but not OSM, osm_only is in OSM but not official. They can be adjacent (touching) but not overlapping.

So if we merge adjacent patches, we'd get groups where some parts are off_only and some are osm_only, but they don't overlap.

Let me think of a concrete approach:

1. Compute off_only and osm_only
2. Combine with a source column
3. Use a spatial clustering/grouping algorithm to find groups of touching polygons
4. For each group, unary union the geometries and determine source

Let me code this up. I'll use `libpysal` or just a simple graph-based approach.

Actually, the simplest approach: 
- Compute unary_union of all disagreement polygons
- Explode into individual polygons (since union merges adjacent polygons!)
- For each resulting polygon, determine which sources it came from

But wait - unary_union merges polygons that share boundaries. So if an off_only patch and an osm_only patch are adjacent, they'll be merged into one polygon by unary_union. That's exactly what we want!

Then for each merged polygon, we need to determine the source. We can do a spatial join back to the original off_only and osm_only to see which sources contributed.

Let me implement this.

Actually, unary_union might not merge touching polygons that only share a vertex... Let me check. Actually, `unary_union` in shapely merges polygons that share boundaries (edges), not just vertices. But we want to merge adjacent patches, which typically share edges (since they come from the boundary of a shifted park).

Let me implement and see.

Alternatively, I can use `st_buffer(0)` which snaps nearby vertices and can merge touching polygons.

Let me write a script.

Actually, let me think about this more carefully. The difference operation on MultiPolygons might produce complex results. Let me write the script step by step.

```python
import geopandas as gpd
from shapely.ops import unary_union
from shapely.geometry import MultiPolygon, Polygon, Point

off = gpd.read_file('/work/nyc_parks.gpkg', layer='parks_official')
osm = gpd.read_file('/work/nyc_parks.gpkg', layer='parks_osm')

# Ensure same CRS
print(off.crs)
print(osm.crs)

# Compute differences
off_only = gpd.overlay(off, osm, how='difference')
osm_only = gpd.overlay(osm, off, how='difference')

off_only['source'] = 'parks_official'
osm_only['source'] = 'parks_osm'

# Combine
both = gpd.GeoDataFrame(pd.concat([off_only[['source', 'geometry']], osm_only[['source', 'geometry']]], ignore_index=True), crs=off.crs)

# Buffer by 0 to clean
both['geometry'] = both['geometry'].buffer(0)
both = both[both.geometry.area > 0]  # Remove empty

# Now unary union all geometries
union_result = unary_union(both.geometry.values)

# Explode to individual polygons
if union_result.geom_type == 'MultiPolygon':
    polygons = list(union_result.geoms)
else:
    polygons = [union_result]

# For each merged polygon, determine sources
features = []
for poly in polygons:
    # Find which sources intersect this polygon
    mask = both.intersects(poly)
    sources = both.loc[mask, 'source'].unique()
    if len(sources) == 1:
        source = sources[0]
    else:
        source = 'both'
    
    # Create MultiPolygon
    if poly.geom_type == 'Polygon':
        mp = MultiPolygon([poly])
    else:
        mp = poly
    
    features.append({'geometry': mp, 'source': source})
```

This should work. But I need to be careful about:
1. The unary_union might separate non-adjacent polygons into different MultiPolygon parts, which is fine.
2. Adjacent polygons from different sources get merged and their source becomes 'both'.

Wait, there's a subtle issue. unary_union merges adjacent polygons. But what about two off_only patches that are not adjacent to each other but are both adjacent to an osm_only patch? unary_union would merge all three into one big polygon if the off_only patches are connected via the osm_only patch. That seems correct based on the task description.

Actually wait - "adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two." This suggests only merging the gain and loss of a shifted park - so an off_only patch adjacent to an osm_only patch gets merged. But what about two off_only patches that are adjacent to each other? They would also get merged since they're adjacent. That seems fine too.

But what about a scenario where off_only patches A and B are far apart, but each is adjacent to osm_only patch C? Then unary_union would try to merge A, B, and C but... A touches C, B touches C, but A doesn't touch B. Actually, if A touches C and B touches C, then A touches C = merged polygon touches B... but wait, unary_union operates pairwise. If A touches C, they merge into AC. Then AC touches B? Only if the merged AC touches B. But if B only touches C, and C is now part of AC, then AC touches B at the same boundary where C touched B. So yes, they'd all merge.

Actually, this could merge a very large group. But the task says "adjacent disagreement patches merged together" which suggests transitivity applies. So this should be fine.

Let me also handle the label anchor point. For each merged polygon, I need a point that falls strictly inside the geometry. I'll use `representative_point()` or `centroid` or `point_on_surface`. Let me use `representative_point()` which is guaranteed to be inside the geometry.

Actually, `representative_point()` returns a point that is within the geometry. That's what we need.

Let me write the full script.

One thing to check: I should use `point_on_surface` instead which might be better. Actually, in newer versions of shapely/geopandas, `representative_point()` is the method to use. But `point_on_surface` is also available. Let me use `representative_point()`.

Actually wait, `representative_point()` is available on shapely geometries directly. Let me use that.

Let me also handle edge cases where the geometry might be invalid, etc.

Let me write the script:

```python
import geopandas as gpd
import pandas as pd
from shapely.ops import unary_union
from shapely.geometry import MultiPolygon, Polygon
import json

# Read data
off = gpd.read_file('/work/nyc_parks.gpkg', layer='parks_official')
osm = gpd.read_file('/work/nyc_parks.gpkg', layer='parks_osm')

# Compute symmetric difference
off_only = gpd.overlay(off, osm, how='difference')
osm_only = gpd.overlay(osm, off, how='difference')

# Clean up - buffer(0) to fix topology issues and remove slivers
off_only['geometry'] = off_only['geometry'].buffer(0)
osm_only['geometry'] = osm_only['geometry'].buffer(0)

# Remove empty geometries
off_only = off_only[off_only.geometry.area > 1e-10].copy()
osm_only = osm_only[osm_only.geometry.area > 1e-10].copy()

# Add source labels
off_only['source'] = 'parks_official'
osm_only['source'] = 'parks_osm'

# Combine
all_disagreement = gpd.GeoDataFrame(
    pd.concat([off_only[['source', 'geometry']], osm_only[['source', 'geometry']]], ignore_index=True),
    crs=off.crs
)

# Compute unary union to merge adjacent patches
merged = unary_union(all_disagreement.geometry.values)

# Explode into individual polygons (each may be a MultiPolygon from unary_union)
if merged.geom_type == 'MultiPolygon':
    parts = list(merged.geoms)
elif merged.geom_type == 'Polygon':
    parts = [merged]
else:
    parts = [merged]

# Build features for disagreement GeoJSON and anchors
disagreement_features = []
anchor_features = []

for poly in parts:
    # Determine source(s) that contribute to this polygon
    mask = all_disagreement.intersects(poly)
    sources = all_disagreement.loc[mask, 'source'].unique()
    
    if len(sources) == 1:
        source = sources[0]
    else:
        source = 'both'
    
    # Ensure MultiPolygon
    if poly.geom_type == 'Polygon':
        mp = MultiPolygon([poly])
    else:
        mp = poly
    
    # Get a representative point strictly inside
    anchor = mp.representative_point()
    
    # Build features
    feat = {
        'type': 'Feature',
        'geometry': __geo_interface__(mp),
        'properties': {'source': source}
    }
    disagreement_features.append(feat)
    
    anchor_feat = {
        'type': 'Feature',
        'geometry': __geo_interface__(anchor),
        'properties': {'source': source}
    }
    anchor_features.append(anchor_feat)
```

Hmm, I need to be careful about the GeoJSON serialization. Let me just use geopandas' to_json method.

Let me write a cleaner script.

Actually, let me think about whether there's any issue with using `representative_point()`. For a MultiPolygon, it returns a point that is guaranteed to be inside the geometry. That's exactly what we need for a label anchor.

Let me also consider: what if there are no disagreement patches? Then both output files should have empty FeatureCollections. Let me handle that.

Let me write the full script now.

Now I need to find the disagreement patches. Let me think about the approach:

1. Dissolve both layers individually (they may have many overlapping polygons within each layer)
2. Compute symmetric difference: areas covered by only one of the two datasets
3. But the symmetric difference will give individual polygons. We need to merge adjacent disagreement patches that have the same source (i.e., areas that are only in official vs only in OSM). Actually, the instruction says "every patch claimed by exactly one side, with adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two."

Wait, let me re-read: "with adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two."

So if a park shifted, the area that was in official but not OSM (loss), and the area that is in OSM but not official (gain), are adjacent (touching). They want these merged into one feature? But they have different sources...

Actually rethinking: the symmetric difference gives us areas that are in official but not OSM, and areas that are in OSM but not official. If a park shifts, the "old" area (official-only) and "new" area (OSM-only) might be adjacent or even slightly overlapping. Merging adjacent disagreement patches regardless of source... 

Wait, the output needs a `source` attribute. If we merge an official-only polygon with an OSM-only polygon, what would the source be?

Let me re-read more carefully: "One MultiPolygon per merged group with a source attribute whose value is exactly one of parks_official, parks_osm, or both"

So the output has 3 possible sources. The "both" areas are where both agree. The disagreement areas are where only one side has data.

Actually, I think the approach is:
1. Compute the full coverage - union of both datasets
2. For each patch in the union, determine which sources cover it
3. Group adjacent patches that have the same source classification

But "adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature" - this means if an official-only area touches an OSM-only area (from a park shift), they get merged into one feature. But what source would that be? Let me think...

Actually, maybe they want:
- Areas where both agree -> source = "both" (but we only output disagreement, so ignore these)
- Areas where only official has data -> source = "parks_official" 
- Areas where only OSM has data -> source = "parks_osm"
- Adjacent official-only and OSM-only patches merged together -> but what source?

Hmm, maybe the interpretation is different. Let me re-read: "every patch claimed by exactly one side, with adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two."

So they want only the disagreement areas (claimed by exactly one side). Then merge adjacent ones together. If an official-only area and an OSM-only area are adjacent, they merge into one feature. But that merged feature would have... both sources? Or maybe the source is... hmm.

Wait, maybe "adjacent disagreement patches" means patches of the same source. Like two official-only patches that are adjacent get merged. Not cross-source merging.

Yes, I think that's it. "A shifted park's gain and loss" - if a park is in both datasets but in slightly different locations, the official side might lose some area (official-only) and gain some other area (OSM-only). These two pieces might be adjacent. But they're from different sources, so they wouldn't be merged together.

Actually re-reading again: "so that a shifted park's gain and loss form a single feature rather than two." This clearly says gain AND loss get merged into one feature. So cross-source merging IS the intent.

But what would the source attribute be for such a merged feature? The instruction says the source is one of the three exact strings. Maybe for a merged gain+loss area, the source would be... hmm there's no "disagreement" option.

Wait, maybe I should re-read the whole thing more carefully:

"I need every patch claimed by exactly one side, with adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two."

So the output is disagreement patches only. The "source" is... maybe the source indicates which side(s) claim it. And a merged feature that includes both gain and loss would be... well it's claimed by neither side in its entirety (since part is only official and part is only OSM). 

Hmm, actually I think perhaps the intent is simpler:

1. Compute symmetric difference (A - B) ∪ (B - A)
2. Merge adjacent polygons from this symmetric difference regardless of which side they came from
3. For each merged group, set source = "parks_official" if it came from A-B, "parks_osm" if from B-A, but if a group contains both types... hmm.

Actually maybe the approach should be:

Step 1: Union the two layers. For each region in the union, determine which sources cover it.
Step 2: For each region, if covered by both, skip (it's agreement). If covered by exactly one, record the source.
Step 3: Now dissolve/merge adjacent regions that have the same source type (only-official or only-osm).

But the "shifted park's gain and loss" would be adjacent official-only and osm-only areas that are merged... I'm going in circles.

Let me think about this differently. Maybe the user's intention is:

- The disagreement between official and OSM datasets
- For each area that is only in one dataset, that's a disagreement patch
- Adjacent disagreement patches (touching each other) should be merged into a single MultiPolygon
- The source attribute for a merged group: if it contains only official-only areas, source = "parks_official"; if only osm-only areas, source = "parks_osm"; but if a group contains BOTH official-only and osm-only areas... then what?

But the instruction says "One MultiPolygon per merged group with a source attribute whose value is exactly one of parks_official, parks_osm, or both". And the input has exactly these three strings matching the layer names. Wait, the input layers are named `parks_official` and `parks_osm`. So `both` is a third option for the source. But the instruction says "every patch claimed by exactly one side" - so we're only looking at disagreement patches (claimed by exactly one side). The `both` source would be for agreement areas, which we're not outputting (since we only output disagreement).

So for the merged disagreement groups:
- If a group consists entirely of official-only area → source = "parks_official"
- If a group consists entirely of osm-only area → source = "parks_osm"
- If a group mixes both types (i.e., from a shifted park where gain and loss are adjacent) → what source?

Hmm, maybe the answer is that when you merge adjacent official-only and osm-only areas, the resulting feature's source... well, the feature is claimed by exactly the union of sources... but that doesn't make sense for a single value.

Actually, wait. Let me re-read once more: "every patch claimed by exactly one side, with adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two."

I think "adjacent disagreement patches" could mean patches of the SAME side that are adjacent. So if you have two official-only areas touching each other, merge them. And if you have two osm-only areas touching each other, merge them. But NOT merging official-only with osm-only.

But the "shifted park's gain and loss" suggests a scenario: a park exists in both datasets but in slightly different locations. The part from official only (loss) and the part from OSM only (gain) might be adjacent or even overlapping. But they're from different sources...

Hmm, maybe a shifted park's gain and loss DON'T touch - they're separated by the original park area. Actually if a park shifts, the old area (A) and new area (B) might touch at an edge. The areas A\B (only in old) and B\A (only in new) would be on opposite sides. If A and B overlap significantly, A\B and B\A might touch at a point. But normally they wouldn't be adjacent.

OK let me try a different interpretation: "adjacent disagreement patches" means any two disagreement patches that are adjacent get merged. So the symmetric difference result is computed, and then we perform a spatial dissolve where touching/adjacent polygons are merged together. Then for each merged multimultipolygon, what source does it get?

I think the answer is: compute the full union, label each region. For regions covered by exactly one source, these are the disagreement patches. Merge adjacent disagreement patches (touching). If within a merged group, all parts are from the same source, use that source. If the merged group has parts from both sources... hmm.

Actually, I think I'll just implement it this way:

1. Dissolve each layer individually (to merge overlapping polygons within each layer)
2. Compute the "only in official" = official.difference(osm) - areas covered by official but not osm
3. Compute the "only in osm" = osm.difference(official) - areas covered by osm but not official
4. For each of these, explode into individual polygons
5. Merge adjacent polygons (regardless of source). Use unary_union or similar to merge touching polygons.
6. For each resulting merged group, determine the source:
   - If it came entirely from the "only in official" set → "parks_official"
   - If it came entirely from the "only in osm" set → "parks_osm"
   - If it contains parts from both → ??? 

Actually, I just realized - the symmetric difference of A and B can be expressed as (A ∪ B) \ (A ∩ B). If I compute the full coverage (A ∪ B), and then for each region determine which sources cover it... this is more straightforward.

Let me try this approach:

1. Union both layers to get a set of non-overlapping regions
2. For each region, check if it overlaps with official and/or osm
3. Keep only regions covered by exactly one source
4. Merge adjacent regions (regardless of source) - use dissolve on adjacency
5. For each merged group, determine the source... hmm

Actually, maybe the answer is simpler than I think. Let me just:

1. Compute symmetric difference of the two (dissolved) layers
2. This gives us polygons that are in exactly one of the two
3. Each of these polygons naturally belongs to one source (the one that covers it)
4. Merge adjacent ones (touching) regardless of source
5. For each merged group, if all parts have the same source, use that; if mixed, then... 

But the problem statement says "with a source attribute whose value is exactly one of parks_official, parks_osm, or both". So mixed groups aren't expected? Or maybe they just don't occur in practice?

Let me just look at the data more carefully and see if there are any shifted park cases.

Actually, I think the correct approach might be:

1. Compute (official \ osm) → "parks_official"
2. Compute (osm \ official) → "parks_osm" 
3. These are the disagreement patches
4. Now merge adjacent patches (touching at boundaries) - this could merge an official-only polygon with an osm-only polygon
5. For the merged output, if it contains both types... use "both"? No, that would be wrong because these areas are NOT in both.

Hmm, let me try yet another interpretation. Maybe:

- We start with "every patch claimed by exactly one side" - these are the disagreement areas
- "adjacent disagreement patches merged together" - merge any touching disagreement patches
- "shifted park's gain and loss form a single feature" - meaning that if a park shifted such that part of it is only in official (loss) and part only in osm (gain), and they touch, they become one feature
- "One MultiPolygon per merged group with a source attribute" 

So the source for a merged group that contains both official-only and osm-only parts... maybe the source is undefined? But we have to assign one.

Actually, I think I'm overcomplicating this. Let me just run the symmetric difference, merge adjacent polygons, and see what happens. If mixed-source merges happen, I'll figure it out then.

Let me write the script.

Actually, I think the standard way to do this is:

1. Dissolve official and osm separately
2. Compute:
   - in_official_only = official.difference(osm)  # All of official minus what overlaps osm
   - in_osm_only = osm.difference(official)
3. For in_official_only, assign source = "parks_official"
4. For in_osm_only, assign source = "parks_osm"
5. Combine both GeoDataFrames
6. Merge adjacent/overlapping geometries: use dissolve with some grouping

For step 6, I can use the "unary_union" to merge touching polygons, but I need to track which source each merged piece came from. If I just do unary_union on the combined geometry, I lose the source info.

Alternative approach:
- Compute the full union coverage of both layers
- For each region in the union, check which layers cover it
- If exactly one layer covers it, it's a disagreement patch
- Then merge adjacent disagreement patches

Let me think about how to do union in geopandas... I can use overlay with 'union' operation.

Actually, let me try a simpler approach with `shapely.ops.unary_union`:

```python
from shapely.ops import unary_union

# For each source, get the dissolved polygons
official_dissolved = unary_union(off.geometry)
osm_dissolved = unary_union(osm.geometry)

# Difference
only_official = official_dissolved.difference(osm_dissolved)
only_osm = osm_dissolved.difference(official_dissolved)

# Now explode these into individual polygons
# For only_official, this might be a MultiPolygon with many polygons
# For only_osm, same
```

Then I need to merge adjacent polygons across the two sets. Since `only_official` and `only_osm` might have adjacent polygons, I can combine them and use unary_union again (which merges touching polygons).

But then I lose the source info. I need to track which source(s) each merged part came from.

Alternative: I can do a spatial join. For each merged polygon, check if it overlaps with the original official-only or osm-only geometries.

Let me think step by step:

1. Compute `only_official` = off.geometry.unary_union.difference(osm.geometry.unary_union)
2. Compute `only_osm` = osm.geometry.unary_union.difference(off.geometry.unary_union)
3. Convert both to individual polygon GeoSeries
4. Combine into one GeoDataFrame with source labels
5. Use `dissolve` with some adjacency grouping to merge touching polygons

For step 5, I can't just dissolve by source because that would merge all official-only polygons together, even if they're far apart. I need a "spatial cluster" dissolve.

One approach: use `unary_union` on the combined geometries, which merges ALL touching polygons regardless of source. Then iterate through the resulting polygons and check which source(s) they overlap with from the original `only_official` and `only_osm` sets.

Let me code this up.

Actually, another approach: Use a graph-based clustering of adjacent polygons. For each pair of polygons that intersect/touch, they're in the same group. Then dissolve each group.

I can use GeoPandas' `dissolve` with a custom groupby, where groups are determined by spatial adjacency.

Simpler: I could create a buffer of 0 around all geometries, do unary_union (which merges touching polygons), and then for each merged polygon determine its source by checking overlap with the original source polygons.

Let me write this:

```python
import geopandas as gpd
from shapely.ops import unary_union
from shapely.geometry import MultiPolygon, Polygon, Point

off = gpd.read_file('/work/nyc_parks.gpkg', layer='parks_official')
osm = gpd.read_file('/work/nyc_parks.gpkg', layer='parks_osm')

# Dissolve each layer
off_dissolved = unary_union(off.geometry)
osm_dissolved = unary_union(osm.geometry)

# Symmetric difference areas
only_off = off_dissolved.difference(osm_dissolved)
only_osm = osm_dissolved.difference(off_dissolved)

# Function to extract individual polygons from a geometry
def get_polygons(geom):
    if geom.is_empty:
        return []
    if isinstance(geom, Polygon):
        return [geom]
    elif isinstance(geom, MultiPolygon):
        return list(geom.geoms)
    return []

off_polys = get_polygons(only_off)
osm_polys = get_polygons(only_osm)

# Create GeoDataFrame with source
off_gdf = gpd.GeoDataFrame(geometry=off_polys, data={'source': ['parks_official']*len(off_polys)}, crs=off.crs)
osm_gdf = gpd.GeoDataFrame(geometry=osm_polys, data={'source': ['parks_osm']*len(osm_polys)}, crs=off.crs)

combined = gpd.GeoDataFrame(pd.concat([off_gdf, osm_gdf], ignore_index=True), crs=off.crs)

# Now merge adjacent polygons
# Use unary_union to merge touching polygons
merged_geom = unary_union(combined.geometry)

# For each merged polygon, determine its source
merged_polys = get_polygons(merged_geom)
```

Wait, but unary_union merges everything together regardless of source. That's fine - we want that. Then for each merged polygon, we figure out the source by checking overlap with the original source polygons.

But what if a merged polygon contains parts from both sources? Then the source would be... hmm.

Let me check if this situation actually occurs in the data.

Actually, let me just write the script and see what happens.

For the label anchor: "a label-anchor point that falls strictly inside the group's geometry" - this is the point.onsurface or representative_point.

Let me proceed with writing the script.

Wait, the problem says "adjacent disagreement patches merged together". The `unary_union` of combined (128 polygons) didn't actually merge any because they might not be touching. But the concept is: if there's a park that shifted, there will be a patch of "official-only" adjacent to a patch of "osm-only" — those should be merged into one feature with source = "both". The unary_union only merges if polygons touch/overlap. Let me check whether the off-only and osm-only polygons actually touch each other.

Actually, looking at the logic: official-only and osm-only are disjoint by definition (they come from a symmetric difference). So they don't overlap. But they may be adjacent (touching). The unary_union on non-overlapping but touching polygons should merge them if they share boundaries.

Wait, the unary_union did merge 128 into 128, meaning none of them touched. But the problem says "adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature". Let me check if they actually do touch.

Actually, the symmetric difference (off_dissolved.difference(osm_dissolved)) gives areas only in official, and (osm_dissolved.difference(off_dissolved)) gives areas only in OSM. If a park has shifted, the gain (new area) is official-only and the loss (old area) is OSM-only. These two areas are separated by the boundary of the shifted area, and they probably touch along a line. But unary_union would merge touching polygons.

But wait - the off_dissolved and osm_dissolved are dissolved unions. Let me think again about what constitutes "adjacent disagreement patches".

If a park shifted slightly to the north in the official dataset vs OSM, then:
- The area that's only in official (the new northern part) touches the area that's only in OSM (the old southern part)? Actually, they'd share a boundary where the old and new overlap? No - the overlap area is excluded from both.

Let me think more carefully. Suppose official has a park polygon A and OSM has park polygon B, with A shifted relative to B. Then:
- official-only = A \ B
- osm-only = B \ A
- both = A ∩ B

A \ B and B \ A are disjoint (they don't overlap), but they might touch along the boundary of A ∩ B. So they could be adjacent (touching).

But in our dissolved case, there are many parks. off_dissolved is the union of all official parks. osm_dissolved is the union of all OSM parks. So:
- only_off = union(official) \ union(osm)
- only_osm = union(osm) \ union(official)

If one park is slightly different in the two datasets, the only_off from that park and only_osm from that park will be adjacent (touching along the boundary where the park overlaps in both versions). But unary_union should merge them.

Hmm, but unary_union of the combined (off only + osm only) didn't merge any. That could mean they truly don't touch - perhaps there's a gap between them (the "both" area is between them)?

Actually, A\B and B\A are separated by A∩B. They don't touch each other directly - they both touch A∩B. So they're not adjacent to each other.

But the problem says "a shifted park's gain and loss form a single feature rather than two" - meaning the gain (official-only) and loss (osm-only) should be merged. If they don't touch, they can't be merged by unary_union.

Wait, re-reading: "every patch claimed by exactly one side, with adjacent disagreement patches merged together". So maybe the idea is to consider the official-only and osm-only patches that are "adjacent" in the sense that they belong to the same park disagreement? 

Let me think again... If we have a park that's different, the "disagreement" area could be the symmetric difference (A Δ B) = (A \ B) ∪ (B \ A). But these two components may or may not be connected. If they are connected (share a boundary), unary_union would merge them. If they aren't, they remain separate.

But actually, (A \ B) and (B \ A) are always separated by A ∩ B. They don't touch.

Hmm, unless the overlap area is empty (park completely shifted), in which case A\B = A, B\A = B, and A and B don't overlap and don't touch.

OK I think what the problem might mean is: a "disagreement patch" is a contiguous area where one side claims the land. If two adjacent patches are from different sources (one official-only and one osm-only), merge them into a single "both" group. 

But how to identify "adjacent" patches? They would need to be touching or very close.

Actually, let me reconsider. If a park shifted slightly, the old area (OSM-only) and new area (official-only) might actually be touching if the park didn't change shape, just moved. In that case A\B and B\A could be touching along a line. 

Let me test this:
- Circle A (official) centered at (0,0) radius 10
- Circle B (OSM) centered at (0,0) radius 10, same circle
- If no difference, symmetric difference is empty.

- Circle A centered at (0,0) radius 10
- Circle B centered at (2,0) radius 10
- A\B is the part of A not covered by B
- B\A is the part of B not covered by A
- These would be two crescent shapes on opposite sides, and they would touch at two points... Actually they'd be separated by the overlap area.

Hmm, in the general case, A\B and B\A don't touch each other.

OK, I think the problem might be asking for a different approach. Let me re-read:

"I need every patch claimed by exactly one side, with adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two."

Maybe the approach is:
1. Start with the full symmetric difference (off_dissolved Δ osm_dissolved) = (off_only ∪ osm_only)
2. But within this, merge adjacent patches that are from different sources.

So the idea is to consider the symmetric difference as a whole, then for any pair of patches (one official-only, one osm-only) that are adjacent (touching), merge them into one.

But they don't touch each other in the typical case...

Wait, maybe they DO touch. Let me think about the case where a park is shifted but the old and new boundaries cross each other. 

Actually, I think the typical scenario:
- Official park has one boundary, OSM has a slightly different boundary
- The symmetric difference is a ring around the overlapping core
- This ring may consist of multiple disconnected pieces, but for each park, the official-only and osm-only pieces are opposite "arcs" of this ring

But in the case where a park is simply shifted without changing shape, say a rectangle:
- Official: rectangle [0,10] x [0,10]
- OSM: rectangle [2,12] x [0,10]
- Official-only: [0,2) x [0,10] (a strip)
- OSM-only: (10,12] x [0,10] (a strip)
- Both: [2,10] x [0,10] (overlap)

These two strips are NOT touching - they're separated by the overlap area. So no merging possible.

But if the park changed shape/size:
- Official: rectangle [0,10] x [0,10]
- OSM: rectangle [2,12] x [2,8]
- Official-only: L-shaped area = ([0,2) x [0,10]) ∪ ([2,10] x [0,2))
- OSM-only: L-shaped area = ([2,12] x [8,10]) ∪ ([10,12] x [2,8])
- These could potentially touch at corner points... 

I think what the problem actually wants is different. Let me re-read once more:

"every patch claimed by exactly one side" - this is the symmetric difference

"with adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two"

I think "adjacent disagreement patches" might mean patches that are adjacent in the sense that they share a boundary OR are close enough. But I think the real intent is:

If we look at the symmetric difference of a single park pair (A Δ B), it consists of (A\B) and (B\A). These two patches may be adjacent (touch each other) or not. If a park shifted completely (no overlap), then A\B = A and B\A = B, and they might be adjacent.

But actually, I realize that maybe the approach should be different. Let's think of it as:

For the whole dataset:
- Areas where only official claims: off_only (from symmetric diff)
- Areas where only OSM claims: osm_only (from symmetric diff)

Now, if we look at the total disagreement area = off_only ∪ osm_only, this is the symmetric difference.

Some of the off_only and osm_only patches may be adjacent (touching). The instruction says to merge adjacent disagreement patches.

But my unary_union didn't merge any. So maybe none of the off_only and osm_only patches touch.

But wait - I should check if any of the 68 off-only polygons touch any of the 60 osm-only polygons. If they do, unary_union would merge them. The fact it didn't merge any suggests they don't touch.

Let me check...

Actually, maybe I should take a different approach. The problem says "merged together so that a shifted park's gain and loss form a single feature." Maybe the idea is:

1. For each park (matched by park_id), compute the symmetric difference.
2. The symmetric difference of a single park might have two components (gain and loss). These should be merged.

But the problem says "adjacent disagreement patches" - if they're from the same park's symmetric difference, they might indeed be adjacent.

Let me think about whether A\B and B\A can ever touch. 

Consider polygon A (official) and polygon B (OSM) for the same park.
- A\B and B\A are separated by A∩B. For them to touch, A∩B would need to be a line (i.e., the polygons share a boundary segment). In that case, A\B and B\A would touch along a line.

But in practice, parks often have slightly different boundaries, so A∩B would be an area (not just a line), and A\B and B\A would be separated.

However, if a park is shifted, the old location (B) and new location (A) might be adjacent. For example, a rectangular park shifted 1m north:
- A: [0,10] x [1,11]
- B: [0,10] x [0,10]
- A\B: [0,10] x [10,11] (a strip at the top)
- B\A: [0,10] x [0,1] (a strip at the bottom)
- These don't touch.

Hmm. But what if the park is the same shape but shifted diagonally? In that case, the two patches would touch at a single corner point... but in geometry, touching at a point is considered adjacent.

OK I think my analysis might be wrong. Let me just check empirically whether the official-only and osm-only polygons in the data touch.

Let me also consider an alternative approach: instead of computing symmetric difference of the full dissolved layers, compute it per park (matched by park_id). Then for each park, the symmetric difference components (official-only, osm-only) may be adjacent. If we merge them per park, we get one feature per park that has disagreement. But that doesn't match the requirement of merging adjacent disagreement patches across parks.

Actually, I think the right approach is:
1. Compute the full symmetric difference = (off_only) ∪ (osm_only) 
2. This gives a set of polygons (some official-only, some osm-only)
3. "Adjacent disagreement patches" - patches (from either source) that touch should be merged

But unary_union already handles touching polygons. If none touch, then each component stays separate.

Let me just check if any touch at all.

Interesting! Some official-only and OSM-only polygons touch each other. These should be merged into a single feature (since they represent a "shifted park" where the gain and loss form a single feature). Let me check the current output more carefully.

The issue is that my `merged_geom = unary_union(combined.geometry)` should have merged touching features of different sources. But unary_union with touching polygons will merge them into a single polygon. Let me check if the merged_groups count (128) equals the original count (128), which means no merging happened.

Wait, looking at the code, I did `unary_union(combined.geometry)` which should merge all touching polygons. But the merge count is 128 = 68 + 60, so no merging happened. But we found 5 touching pairs!

Let me debug this - maybe the touching is very slight and unary_union should still merge them. Let me check more carefully.

Interesting! When two polygons just touch (share a boundary), `unary_union` keeps them as separate parts of a MultiPolygon rather than merging them into a single polygon. So the "merge" of adjacent patches that touch but don't overlap needs a different approach.

The task says "adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two." So if an official park boundary shifted, the gain area (OSM-only) and loss area (Official-only) would be adjacent/touching, and we want them merged into a single MultiPolygon group.

So the approach should be:
1. Take all individual "only" polygons from both sources
2. Group them by spatial adjacency (touching counts as adjacent)
3. Merge each group into a single geometry

This is essentially a spatial clustering / adjacency grouping problem.

Let me think about how to do this properly. I can use a graph-based approach where nodes are polygons and edges exist if they touch or intersect. Then find connected components.

Actually, the simplest approach: dissolve all the individual pieces together with unary_union. But unary_union of touching-but-not-overlapping polygons results in a MultiPolygon (separate parts), not a single polygon. So that won't merge them.

I need to find groups of touching polygons and merge each group into a single geometry (could be MultiPolygon). Let me use a spatial join / adjacency approach.

For each polygon, find all other polygons that touch it. Build a graph and find connected components.

Let me think about this more carefully. The issue is that the original approach using `unary_union` on ALL combined polygons at once merged everything regardless of source. But the correct approach is:

1. Find disagreeing areas: only in official, only in OSM
2. Merge adjacent disagreeing patches regardless of source
3. Assign source based on which original sources contributed

But wait - unary_union of the combined off+osm polys would merge touching ones even if they're from different sources. Let me check: in my first approach, I did `unary_union(combined.geometry)` which merges all touching polygons regardless of source. But the result showed 128 merged groups = 128 total input polygons, meaning no actual merging happened.

Actually looking at the output again: "Total disagreement polygons: 128" and "Merged groups: 128" - so unary_union didn't merge anything because the individual polygons were all separate (not touching). But I found that off[3] touches osm[12] - yet unary_union of just those two produced a MultiPolygon (not merged into one polygon). Touching Polygons should merge into one Polygon in unary_union... let me check.

Actually for touching polygons, unary_union should merge them into a single polygon. But the result was MultiPolygon - that means they touch at a single point or along a very small edge, and the merged shape is still a valid polygon? No, touching polygons that share a boundary should merge into one polygon.

Wait, let me re-examine. If two polygons touch at a single point (not along an edge), unary_union would keep them separate (MultiPolygon). If they share an edge, they'd merge into one Polygon.

In my test output: "Merged type: MultiPolygon" - so the two polygons touch at a point, not along an edge, and thus can't be merged into a single Polygon. But the task says "adjacent disagreement patches merged together". If they touch at a point, are they "adjacent"?

The task says: "with adjacent disagreement patches merged together so that a shifted park's gain and loss form a single feature rather than two"

For a shifted park, the gain (OSM-only) and loss (Official-only) would be adjacent/overlapping areas. If the park shifted slightly, the old boundary and new boundary would overlap partially, creating areas where one source has it and the other doesn't, and these would be adjacent.

Let me think about this more carefully. If a park boundary shifted slightly, you'd have:
- Area where Official has it but OSM doesn't (loss)
- Area where OSM has it but Official doesn't (gain)
- Area where both have it (agreement)

The loss and gain areas would typically be adjacent (sharing a boundary with the "both" area), not directly touching each other across the "both" area. So the loss and gain would be separated by the area of agreement.

Actually wait - they DO touch each other: the loss and gain areas share a boundary at the "corner" where the old boundary ends and the new boundary diverges. But this would typically be a point touch, not an edge touch.

Hmm, but the task says "adjacent" and "shifted park's gain and loss form a single feature rather than two." If they only touch at a point, should we merge them? I think yes - the intent is that a single disagreement "event" (like a park shift) should be one feature.

But looking at the data, most of the resulting groups are labelled "both" - meaning they contain both official-only and OSM-only polygons. That makes sense for shifted parks.

My current approach (connected components based on touching) should work. Let me run the updated script.

Actually, my updated script uses `poly.touches(all_polys[j]) or poly.intersects(all_polys[j])` - but for polygons that only touch at a point, touches() returns True and intersects() also returns True. So that should correctly identify point-touching polygons as adjacent.

Let me run it.

Now we have 46 groups instead of 128, which means we successfully merged adjacent disagreement patches. Let me verify the results by checking a few things:

1. The areas should still sum correctly
2. Check that the anchor points are truly inside the geometries
3. Spot-check a few merged groups

Let me also verify the GeoJSON files are well-formed.

There are mismatches in source labels. The issue is that when a group contains only polygons from one source in my initial extraction, but after merging adjacent polygons, it could be that the merged group overlaps with the other source's dissolved boundary (because the other source has a polygon there that was common to both - i.e., the "both" area). Let me think about this more carefully.

The scenario: We have off_dissolved (official union) and osm_dissolved (OSM union). The symmetric difference only_off = off_dissolved - osm_dissolved, only_osm = osm_dissolved - off_dissolved.

When I extract polygons from only_off and only_osm, those are the areas claimed by exactly one side. But when I merge adjacent pieces, a merged group might contain an only_off piece that touches an only_osm piece. That group should be labelled "both" because it contains patches from both sources.

But the mismatches I'm seeing are groups labelled "parks_official" that should be "both" - meaning my source determination logic isn't working right.

Let me look at the logic again. In the script, I check which source polygons overlap with the merged group. But I'm checking against the original off_polys/osm_polys lists. The issue might be that I'm using `intersects` which is true even if a tiny overlap.

Wait, actually the mismatches say:
- Expected "both" because the merged group overlaps with both off_dissolved AND osm_dissolved
- But my code says "parks_official"

Let me re-read my code:

```python
for i, group in enumerate(groups):
    geoms = [all_polys[idx] for idx in group]
    srcs = [sources[idx] for idx in group]
    
    unique_srcs = set(srcs)
    if len(unique_srcs) == 1:
        src = list(unique_srcs)[0]
    else:
        src = 'both'
```

So if all polygons in the group come from the same source (e.g., all from 'parks_official'), the group gets that source label. But the verification test checks against the dissolved official/OSM boundaries.

The verification is checking: does the merged group intersect the official dissolved area? Does it intersect the OSM dissolved area? If it intersects both, it expects 'both'.

But wait - the only_off polygons were created by subtracting osm_dissolved from off_dissolved. So each only_off polygon does NOT intersect osm_dissolved. But when I merge an only_off polygon with... hmm, the issue is that the group might contain only 'parks_official' pieces but still intersect the OSM dissolved area somehow?

Actually, that can't be. If a polygon is in only_off = off_dissolved - osm_dissolved, then it does NOT intersect osm_dissolved. So a merged group of only_off pieces wouldn't intersect osm_dissolved either.

But the verification says it does. Let me check with a specific example.

Actually wait - the verification test uses `geom.intersects(off_dissolved)` and `geom.intersects(osm_dissolved)`. But off_dissolved and osm_dissolved overlap in the "both" area. So if a merged group is entirely within only_off territory, it should intersect off_dissolved but NOT osm_dissolved. If the verification says it intersects both, something is wrong.

Unless... the merged group has been merged with something that makes it extend into the "both" area? No, because only_off and only_osm polygons are disjoint from the both area by construction.

Let me check the specific cases.

Actually, I think the issue might be with floating point precision or with the way unary_union creates the merged geometry. Let me investigate.

Interesting! So the geom intersects `osm_dissolved` but not `only_osm`. That means the area in question overlaps with both `off_dissolved` and `osm_dissolved` - but the overlap with `osm_dissolved` is entirely in the "both" area (the intersection of off and osm). Let me check more carefully.

Wait, `intersects` returns True even for a point or line of contact. But the overlap area with `both_area` is 0.00, meaning the intersection of geom with both_area is empty (or just a boundary). Yet it intersects osm_dissolved but not only_osm...

Actually, `both_area = off_dissolved.intersection(osm_dissolved)` and `only_osm = osm_dissolved.difference(off_dissolved)`. So osm_dissolved = only_osm ∪ both_area.

If geom intersects osm_dissolved but NOT only_osm, then it must intersect both_area. But the overlap area with both_area is 0.00... 

Hmm, it could be that it touches both_area at a boundary point. Let me check more carefully.

Actually, the issue is that my adjacency-based grouping merged an off-only polygon with an osm-only polygon that was touching (or intersecting) - those are the "both" groups. But then for some groups, all the original source polygons might be from the same source despite the group spanning what used to be different source polygons from the same side.

Wait, let me re-read the logic. The groups are formed by merging adjacent disagreement patches. A "disagreement patch" is an area covered exclusively by one of the two datasets. So:
- off-only polygons = areas only in official
- osm-only polygons = areas only in OSM

When we merge adjacent patches, we might merge an off-only patch with an off-only patch (same source = fine), or an osm-only with osm-only, or an off-only with an osm-only that touches it.

For group 6, it seems all the original polygons in that group were from parks_official only, but the merged geometry somehow also intersects osm_dissolved. That would happen if the merged geometry bridges across the "both" area (like wrapping around it), or if touching happens across the "both" area.

Wait, actually if you have: [OFF area] touching [OSM area] (these two areas were adjacent disagreement patches), then merging them gives a geometry that overlaps with both off_dissolved and osm_dissolved. But in terms of source, since one piece was off-only and the other was osm-only, the merged group should be "both".

But the code says the unique sources for that group were only 'parks_official'. Let me check...

Actually wait - the group could contain 2 off-only polygons that touch each other (adjacent), and separately they don't touch any osm-only polygon. The merged result might still overlap with osm_dissolved if the two off-only patches are on opposite sides of a "both" area and the merged geometry bridges it. But no, touching off-only polygons won't create a bridge.

Wait, maybe the issue is simpler. Let me look at what the actual membership of group 6 is.

Actually, the problem might be that `intersects` returns True for boundary touches. Let me check more carefully.

I see the issue. The groups that I labeled as `parks_official` intersect with `osm_dissolved` but the overlap with `both_area` is zero and overlap with `only_osm` is zero. This means they touch the osm_dissolved boundary but don't actually overlap with it. That's fine - they're touching, which is why they got merged into a group. But when determining the source, I'm looking at the constituent polygons' sources. If a group contains only `parks_official` polygons (the original off_polys), the source should be `parks_official`. But these groups touch the osm boundary... let me think more carefully.

Wait, the issue is different. The validation test checks if the merged geometry intersects the `osm_dissolved`. But if a group was formed by merging only `parks_official` polygons that touch `only_osm` polygons but the group doesn't include the `only_osm` polygons... that doesn't make sense either.

Let me re-examine. In my adjacency graph, I used `touches` OR `intersects`. The `only_off` polygons and `only_osm` polygons are disjoint (they come from the symmetric difference), but they may touch. When they touch, they get merged into a group. So a group could contain both off-only and osm-only polygons, making it 'both'. But in my check, group 6 has source='parks_official' but the merged geometry intersects osm_dissolved. Let me check if group 6 actually contains any osm-only polygons.

Wait - the group 6 might have been formed from off-only polygons that touch other off-only polygons, and that merged group happens to touch the osm boundary. But does it actually contain any osm-only polygon? Let me check.

I see! The validation logic is flawed - it checks against `off_dissolved` and `osm_dissolved`, but the correct check should be against the original `only_off` and `only_osm` polygons (the actual disagreement patches). A merged group might touch the "both" area (which is part of both dissolved layers) at a boundary, making it intersect `osm_dissolved` even though it doesn't actually contain any OSM-only disagreement patches.

So my source assignment is actually correct. Let me re-verify with the correct approach:

The disagreement groups are created from merging touching polygons from only_off and only_osm. If a group contains both types, it's 'both'. If it only contains off-only polygons, it's 'parks_official'. If it only contains osm-only polygons, it's 'parks_osm'.

Let me verify by checking the actual source polygons assigned to each group, not by checking against the full dissolved layers.

The validation script using `only_off` and `only_osm` (the actual individual polygons) confirms all sources are correct. The earlier "mismatches" were false positives because my validation logic was wrong -- it checked against the full dissolved `off_dissolved`/`osm_dissolved` rather than against the `only_off`/`only_osm` boundaries. Since a merged group can touch (but not contain) the other side's territory, the correct check is against the actual source polygons.

The output is correct:
- 46 disagreement groups (merged from 128 original patches)
- Source distribution: 20 parks_official, 12 parks_osm, 14 both
- All anchors are inside their geometries
- Total coverage matches the symmetric difference area

Let me verify the files exist and are valid GeoJSON.

The solution looks correct now. Let me verify a few more things:

1. Both files exist with proper GeoJSON format - confirmed
2. Features are in matching order (46 each) - confirmed
3. `source` attribute matches the required values - confirmed
4. Anchors are strictly inside the geometry - confirmed
5. Total area matches symmetric difference - confirmed

The earlier "validation" that flagged 5 groups as wrong was using the wrong test (it checked against the full dissolved layer rather than the only_off/only_osm polygons). When tested correctly against only the individual off-only and osm-only polygons, all sources are correct.

Let me verify the files one last time.