spa-l1-capetown-hospital-nn

Analyst notes

Description

Tests whether the agent independently recognises that nearest-neighbour distance on WGS84 inputs has to be computed in a projected CRS to come out in metres. The prompt deliberately omits any mention of CRS, projection, or units beyond asking for metres, so the agent has to notice on its own that the two GeoParquet files are lat/lon and that sjoin-nearest on them returns degrees.

Approach

1. Read both GeoParquet files and confirm their geometries and CRS so it is clear that the inputs sit in WGS84 lat/lon.
2. Reproject both layers to a metric CRS that is appropriate for Cape Town, such as the local UTM zone, before measuring any distances.
3. Run a nearest-neighbour join from each address to the hospitals layer and pull across the hospital name and the straight-line distance in metres.
4. Keep one row per input address with the original address geometry and the columns `address_id`, `nearest_hospital_name`, and `distance_m`.
5. Write the result to `nearest_hospital.gpkg` as a GeoPackage.

Pitfalls

• Running the nearest-neighbour join directly on the WGS84 inputs produces a `distance_m` column whose values are in degrees and are off by roughly five orders of magnitude, which the grader's distance subcheck catches cleanly.
• Reprojecting to Web Mercator (EPSG:3857) to get metres looks plausible but inflates distances by about 1/cos(34 S) at Cape Town's latitude, so distances drift past the 50 m tolerance even though the nearest hospital is usually still correct.
• Dropping `address_id` or renaming it in the output breaks the join back to the address master and tanks the address-set subcheck.
• Writing GeoJSON or Parquet instead of GeoPackage fails Gate 1 outright.
• Reporting `distance_m` in kilometres, feet, or as a stringified number fails the distance subchecks even when the hospital assignment is right.

Map

Recent runs task v2