geo-l1-cairo-multipoint-hull

Analyst notes

Description

This task checks whether the agent applies convex hull per row instead of collapsing all stations into a single hull, and whether it carries the bilingual name columns through the geometric operation without mangling the Arabic strings. The prompt names the operation because the task is L1, but it stays silent about the input geometry type (the agent has to open the file to see each row is a MultiPoint) and about the output CRS, which GeoJSON pins to WGS84 by convention.

Approach

1. Open `cairo_metro_stations.geojson` and confirm each feature is a MultiPoint of entrance points with both name columns.
2. Compute the convex hull on each row independently, keeping the row order so the names stay paired with their geometry.
3. Keep `station_name_en` and `station_name_ar` verbatim, including the Arabic diacritics, and drop nothing else.
4. Write the result to `cairo_metro_hulls.geojson` with one Polygon per station, leaving the coordinates in WGS84 as GeoJSON expects.

Pitfalls

• Calling `convex_hull` on the unioned geometry collapses 20 stations into one polygon, which fails the heavily weighted row-count subcheck.
• Reaching for `shapely.unary_union` to merge geometries drops the attribute columns and breaks the bilingual name preservation.
• Round-tripping the Arabic names through a CSV or Latin-1 encoding mangles the diacritics and trips `arabic_names_match` even when the geometry is correct.
• Returning the axis-aligned bounding box of each MultiPoint instead of the convex hull inflates the polygon by roughly 30 percent and drops `hull_iou_against_reference` below 0.95.
• Reprojecting to a metric CRS for the hull computation and forgetting to project back to WGS84 docks the two CRS subchecks even when the geometry itself is fine.

Map

Recent runs task v2