This task tests whether the agent can run a full CRS round-trip workflow over live Overpass data. The prompt asks for "the regional metric coordinate system" without naming an EPSG; the canonical answer is JGD2011 / Japan Plane Rectangular Zone IX (EPSG:6677), the conformal national grid covering Tokyo, and any other choice on the four engineering layers fails their per-layer CRS subchecks plus the coordinate-envelope check. The hidden gotcha sits one level deeper than picking the right code: planar buffers and area calculations have to happen in the projected frame, so an agent that calls set_crs(6677) without to_crs(6677) leaves geometries in lon/lat and produces 50-degree-wide buffers that cover half of Asia.
Approach
Query Overpass for Tokyo's 23 special wards as admin_level=7 boundary relations inside the Tokyo Metropolis area, and for the drivable road network (motorway through living_street, no service or footway or cycleway or path) in their bounding box.
Reproject both layers into JGD2011 / Japan Plane Rectangular Zone IX (EPSG:6677) before doing any geometric work, so distances and areas are in honest metres.
Find each point where a road LineString crosses a ward boundary, keeping the source ward's id and name alongside each crossing.
Build a 50 m planar buffer around each crossing point, then clip each buffer to the ward whose boundary produced it.
Compute crossings_per_km2 per ward as crossing_count divided by ward area in km², and reproject only the density layer back to WGS84.
Write all five layers into a single GPKG, with the four engineering layers in EPSG:6677 and the density layer in EPSG:4326.
Pitfalls
Stamping CRS metadata on the layer without actually calling to_crs leaves the geometry in lon/lat, so the 50 m buffer becomes 50 degrees wide and area calculations are off by roughly a factor of 10^10.
Reading "the regional metric coordinate system" as Web Mercator (EPSG:3857) instead of JGD2011 Plane IX (EPSG:6677) passes the buffer-area sanity check but fails the wards_jgd coordinate-envelope subcheck.
Fetching every highway=* tag (including footway, cycleway, path, service) overshoots the reference crossing count by enough to break the ±15% tolerance, and may also exceed Overpass' practical response time.
Using the intersects predicate instead of crosses double-counts roads that run along the ward boundary, inflating the crossing count.
Buffering each road segment instead of each crossing point makes the buffer count equal to the road count (~85k, not ~5k) and the per-buffer area enormous.
Populating crossings_per_km2 with the raw crossing count instead of dividing by ward area flips the top of the dashboard list, because Tokyo wards span roughly ten-to-one in area.
Forgetting to reproject the final density layer back to WGS84 fails the dashboard CRS subcheck.
Selecting admin_level=8 instead of admin_level=7, or matching the Tokyo area by name instead of name:en, only assembles a couple of ward polygons, which fails the ward-count subcheck and leaves almost no matched wards for the density comparisons.