857121e5fb37546ec54515ea8f70fb4c4dca34c4
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  knsoandClaude Sonnet 5
|
22ac8f530c |
fix(extract): Polygonlöcher im Chunk-Payload erhalten, split_by_chunk_all abdecken
Ruling 34 (Important, Fix-Runde 1 zu Aufgabe 6): _ring() verwarf jedes Loch eines Polygons (nur poly.exterior wurde in Weltkoordinaten -> three.js uebertragen). Vor dem Chunk-Zuschnitt war das meist harmlos, weil das groesste Loch die Bucht selbst ist und beim Zuschneiden ohnehin herausfaellt - danach blieb es aber ein echter Datenverlust: ein von Strassen umschlossener Block wurde zu Asphalt, ein Innenhof zu Gebaeudemasse, ein Teich im Park zu Wiese. Gemessen an echten Daten: 120 Strassen-Chunk-Stuecke (449.876 m2), 127 Stadtflaechen-Stuecke (208.657 m2 wobei 1 weiteres Park-Stueck), 30 Land-Stuecke (11.402 m2) und mindestens 75 Gebaeude-Stuecke trugen ein verworfenes Loch. _ring() wird _rings(): liefert [poly.exterior, *poly.interiors] in derselben Transformation, Aussenring zuerst. Payload-Schema aendert sich entsprechend fuer land/surfaces/roads/buildings von einem flachen Ring zu einer Liste von Ringen; centerlines und palms sind unveraendert (keine Polygone). Task 7s extrudePolygons() ruft ShapeUtils.triangulateShape(ring, []) bereits mit einem (bisher leeren) Loecher-Array - die Aenderung passt jetzt durchgehend, bevor Aufgabe 7 gebaut wird. write_debug_png() zeichnet weiterhin nur den Aussenring (poly[0]), Loecher werden im Debug-Bild nicht dargestellt. Neuer Test test_polygon_holes_survive_into_the_payload prueft das direkt an einem Block mit Loch; die Koordinaten wurden vor dem Festschreiben gegen die tatsaechliche chunk_payload()-Transformation nachgerechnet (uv run python, nicht nur von Hand). test_coordinates_are_chunk_local_three_js musste auf das neue [0]-Aussenring-Indexing angepasst werden. Ruling 35 (Important): split_by_chunk_all() - die Variante, die run.py tatsaechlich benutzt, nicht das getestete split_by_chunk() - hatte einen MultiPolygon-Zweig ohne jede Testabdeckung. Neuer Test mit einer Klammerform (Steg ausserhalb der Chunk-Zelle, zwei Zinken je einmal hineinreichend) trifft genau diesen Zweig gezielt; er war schon vor der Aenderung gruen - bestaetigt als Abdeckungsluecke, nicht als Bug. uv run pytest -v: 36 passed (34 zuvor + 2 neu). Pipeline (run.py) am gecachten Mosaik neu durchlaufen: weiterhin 144 Chunk-Dateien, public/data/vice-a/ jetzt 2,7 MB (zuvor 2,5 MB; +0,2 MB fuer die erhaltenen Loecher). Insgesamt tragen jetzt 415 Chunk-Stuecke mindestens ein Loch: Land 30/213, Stadtflaechen 127/1145 (+1 Park-Flaeche), Strassen 120/953, Gebaeude 137/2859 (80 global-eindeutige Gebaeude vor Chunk-Duplizierung). Land/Strassen/Stadtflaechen treffen die oben genannten Referenzwerte exakt; bei Gebaeuden weicht die Stueckzahl vom Review-Befund (75) ab. Stichprobe der vier flaechenmaessig groessten Gebaeude-Loecher (Debug-PNGs chunk_8_0, chunk_2_10, chunk_5_11 sowie ein viertes) zeigt plausible echte Ring-Bauwerke (ein stadionartiger Rundbau, eine Wendel-Parkrampe) statt offensichtlicher Fehlklassifikation - die verbleibende Abweichung duerfte an der bereits im Task-6-Bericht offengelegten Restunsicherheit der Gebaeude-Ueberlappungsrekonstruktion liegen (263 vs. 258 spekulative Gebaeude), nicht an dieser Aenderung; im Fix-Bericht dokumentiert. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
knsoandClaude Sonnet 5
|
ce90ea1d5f |
feat(extract): Chunk-Ausgabe, Manifest und Ablaufsteuerung
Task 6: leonida/emit.py (chunk_box, split_by_chunk, chunk_payload und die
Chunk-lokalen three.js-Koordinaten, write_chunks, write_debug_png) sowie
run.py als Ablaufsteuerung, die alles aus den Tasks 3-5 zu 144 Chunk-Dateien
und einem Manifest unter public/data/vice-a/ zusammenfuehrt.
Zwei Abweichungen vom Referenzcode der Aufgabe, beide durch Gegenrechnen
gegen die dort genannten Realwerte gefunden:
- test_emit.py::test_coordinates_are_chunk_local_three_js gab im Original
das ungeschnittene BIG (spannt vier Chunks) direkt an chunk_payload();
chunk_payload() clippt selbst nicht (das tut in run.py split_by_chunk_all
vorher), darum lag der Rand bei x=300 statt <=250 und der Test schlug mit
dem gegebenen Code fehl. Fix: BIG vor dem Aufruf mit split_by_chunk auf
Chunk (0,0) zuschneiden, wie es run.py fuer "land" ohnehin tut.
- run.pys Filter "Gebaeude, die zu >50% in einem Strassenpolygon liegen,
gelten als Strasse" pruefte im Original ALLE rohen Gebaeude gegen
road_polygons(labels) direkt. road_polygons() zaehlt "spekulativ" selbst
zu den Strassenklassen (ROAD_CLASSES) und schliesst zusaetzlich mit
disk(3) gegen Strassennamen; ein isoliertes "spekulativ"-Gebaeude
ueberlappt sich darueber praktisch mit sich selbst. Ergebnis am realen
Mosaik: von 267 rohen spekulativen Gebaeuden ueberlebten nur 3 (statt der
in der Aufgabe genannten Groessenordnung von 258), und die Schliessung
riss zusaetzlich 211 gewoehnliche graue Gebaeude mit heraus, die die
Notiz aus Task 5 ausdruecklich nicht meinte ("die ROTEN Flaechen ...
werden abgezogen"). Fix: eigenes, unzweideutiges Strassenmass nur aus
"strasse"/"weg" (ohne "spekulativ", ohne Namens-Schliessung), Pruefung
nur auf spekulative Kandidaten begrenzt. Ergebnis: 2.348 Gebaeude, davon
263 spekulativ (Aufgabe: 2.352 bzw. 258) - Wahrzeichenhoehen (68 Stueck,
31-248 m) und Palmenzahl (2.133) treffen die genannten Referenzwerte exakt.
Pipeline-Lauf am gecachten Mosaik: 144 Chunk-Dateien + Manifest, 2,5 MB
gesamt (Budget 10 MB), groesste Datei chunk_9_1.json/chunk_10_1.json mit
je 40 KB. Alle drei Toleranzgrenzen (wasser/strasse/gebaeude) eingehalten.
Debug-PNGs stichprobenartig gesichtet: Kuestenlinie, Strassennetz
(inklusive Kreuzungen und einer Auffahrt-Rampe) und ein Strand mit
Palmenreihe liegen deckungsgleich auf dem Mosaik; der wasserreine Chunk
(4,10) zeigt korrekt keine Vektoren.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|