Top-down tiles — new sets + how to read the new geoshift

2026-07-14 · for the tiles/Rhino/Dataset-Sorter workflow · response to HANDOFF_tiles_status.md

Summary

1. The sets you classified as “broken placeholder/atlas coordinates” (Abschnitt_1_long, Abschnitt_1_short, old local 4_5) are almost certainly not corrupt — they use the pipeline’s new per-tile km-snap geoshift convention, which your reader interprets with the old shared-geoshift assumption. World position = (x, y) + that tile’s own geoshift.

2. Either way, you don’t need the old snapshots anymore: complete, fresh Step-4 tile exports for all four Abschnitte (from the 2026-07 production runs) are now on the shared drive, including the segments your Abschnitt 3 set was missing (121–137 and 158+ — the current set is gap-free, segments 0–310).

How to fix the reading

The rasterizer changed its geoshift convention (mid-2026, AI3D-226 era). There are now two kinds of sidecar JSON in the wild:

	Old convention (your “good” sets)	New km-snap convention (your “broken” sets + all current exports)
`x, y`	continuous, km-scale local coords	sub-km residuals (≈0–1000 m) that wrap at every km boundary
`geoshift`	one shared value per branch (e.g. 702 168 / 725 769)	per-tile km-cell origin (multiples of 1000; differs tile-to-tile by design)
world position	`(x,y) + shared geoshift`	`(x,y) + this tile’s geoshift`

Proof from the current Abschnitt 2 sidecars (real values) — note the y “wrap” 982→37 exactly when geoshift.y steps by +1000, and how per-tile reconstruction stays continuous:

seg 010: x=375.4  y=982.0  geoshift=(-3000, -6000)  → world=(-2624.6, -5018.0)
seg 011: x=409.7  y= 37.3  geoshift=(-3000, -5000)  → world=(-2590.3, -4962.7)
seg 012: x=441.5  y= 78.8  geoshift=(-3000, -5000)  → world=(-2558.5, -4921.2)
seg 013: x=471.6  y=120.2  geoshift=(-3000, -5000)  → world=(-2528.4, -4879.8)

Concretely, in your tooling (tile_bounding_boxes.py, notes_to_segments.py, raster_tile.py usage):

Compute the tile footprint as SW = (x + geoshift.x, y + geoshift.y), span width_m × height_m — always using that tile’s own geoshift, never a folder-shared one.
Remove the SKIP_WRAPPED heuristic (“raw span < 1100 m over ≥15 tiles ⇒ broken”). On km-snap tiles this flags perfectly valid data — sub-km raw spans are now normal.
Don’t treat tile-to-tile geoshift differences as damage; in the new convention they are expected. A quick validity check instead: geoshift.x % 1000 == 0 and geoshift.y % 1000 == 0 and the per-tile reconstructed footprints form a continuous ribbon.
Convention detection, if you need to support both: new-schema sidecars carry extra keys (branch_id, segment_key, segment_index, geoshift_source, …). Old minimal schema + shared geoshift ⇒ old convention.

Note on your “applying geoshift explodes the extent to ~700 km” test on Abschnitt_1_long/short: that suggests those particular May-era exports may mix frames (some tiles UTM-scale, some local/zero). If per-tile (x,y)+geoshift still doesn’t form a ribbon there, don’t spend time on them — the replacement below supersedes them completely.

Where the new tiles are

Everything below is inside the shared project drive (ioProperty_projects) — on our machines it’s mounted as N:; on yours the drive letter may differ but the structure below 02_Modelling is identical. Root:

N:\02_Modelling\05_Rink\02_AI 3D modeling\03_Working folder\

Dataset	Path (under the root above)	Contents
Abschnitt 1 complete	`260702_ML_Abschnitt_1\260714_step4_topdown_tiles\`	`branch_000\` (131 segments) + `branch_001\` (11 segments); intensity + rgb PNG + JSON sidecar per segment. Replaces the broken `260611_Abschnitt_1_long/short`.
Abschnitt 2 complete	`260702_ML_Abschnitt_2\260714_step4_topdown_tiles\`	`branch_000\`, 253 segments (same count as your snapshot, but new-schema sidecars).
Abschnitt 3 gap-free 0–310	`260703_ML_Abschnitt_3\260714_step4_topdown_tiles\`	`branch_000\`, 311 segments (000–310), no holes — includes your missing 121–137 and everything past 157.
Abschnitt 4/5 2026-07-12 run	`260713_ML_Abschnitt_4_5\260714_step4_topdown_tiles\`	143 segments, flat (no branch folder; names `segment_NNN_{intensity,rgb}.png` + `segment_NNN.json`). Newer than the 2026-05-21 ACC export you recovered.

Already delivered alongside (same Abschnitt folders, 260713_step7_xml_overlays\): the Step-7 lane XML + control-plot PDFs and the Step-7C overlay tiles/collages from the new segmentation-model production, if you want to review lines on top of the tiles.

Details

Mapping your old snapshot → the new sets

Your set (260611 snapshot)	Status	Replacement
Abschnitt_1_long (100) / _short (42)	old export, unusable per your analysis	`260714…\branch_000` / `branch_001` (131 + 11). Note the split differs — branches are pipeline branches of the 2026-07 run, not the old long/short dataset split.
Abschnitt_2 (253)	usable, old convention	same coverage, new schema — switch when you adopt the reader fix.
Abschnitt_3 (141 unique + holes)	incomplete merge of two partial runs	311 segments, 0–310, single run (`source_files_20260609…` job, rasterized 2026-07-02).
Abschnitt_4_5 ACC recovery (144 + 40)	usable, May run	143 segments from the 2026-07-12 local production (new segmentation model run).

New sidecar schema (what you can rely on)

Keys present in the current exports: x, y, width_m, height_m, geoshift{x,y,z}, geoshift_source, branch_id, branch_index, segment_index, segment_key, segment_name, pixel_x, pixel_y, pixels_per_meter, adaptive_resolution_applied, color_modes, file_prefix, …

File naming (Azure sets): <job_id>_branch_NNN_segment_NNN_intensity.png / _rgb.png / …segment_NNN.json. The 4/5 local set uses plain segment_NNN_* names.

Caveats / verification

The copy to the shared drive was still syncing when this page was written (Google Drive upload queue). If a folder looks partial, re-check after a while; expected file counts: A1 ≈ 426 (two branches), A2 ≈ 760, A3 ≈ 933, A4/5 = 429.
Coordinates in the new sets are in the project-local frame (geoshifts are small negative km multiples, e.g. −3000/−6000), not raw UTM — consistent within each dataset; reconstruct with per-tile geoshift and everything lines up.
One known content gap unrelated to tiles: Abschnitt 3 lane lines (Step-7 XML/overlays) are missing for segment_145 — a Step-6 OOM at the road junction, being fixed separately. The Step-4 tiles for segment_145 are present and fine.