War ein anderes Projekt-KBS als das des Verfahrensgebiets eingestellt, entstand das Drucklayout mit leerer Karte und falschen Koordinaten: Die Ausdehnung kam im Layer-KBS (25833), die Layoutkarte rechnete im Projekt-KBS. Die Hauptkarte bekommt jetzt das KBS des Verfahrensgebiet-Layers (ohne Verfahrensgebiet das Projekt-KBS), und alle Druckbereiche werden dorthin umgerechnet. Das gezeichnete Druckrechteck wird vor dem Speichern in das KBS seines Layers umgerechnet. Neu sind die Funktionen transformiere_rechteck und zoom_auf_layer, die der Zoom-Fix in Verfahrensgebiet nutzt. Issue: #99
Wie geprüft
python scripts/run_tests.py sn_basis --baseline: GRÜN 475/475, unverändert gegenüber Baseline (11 neue Tests in tests/test_druck_kbs.py)
sn_plan41: unverändert gegenüber Baseline. sn_verfahrensgebiet: siehe PR dort.
Ohne die Korrektur sind die neuen Tests rot, schon weil transformiere_rechteck/zoom_auf_layer fehlen. Die Umrechnungsrichtung (Quell- → Ziel-KBS) prüfen die Tests einzeln je Druckbereich.
PrintLayout.create_single_page_layout(..., crs=None) und PrintLayoutBaufreigabe.create_baufreigabe_layout(..., crs=None): neuer optionaler Parameter, setzt das KBS der Hauptkarte vor der Ausdehnung
PrintLogic._resolve_extent(..., druck_crs=None), _store_druckrechteck(..., quell_crs=None): optionale Parameter, ohne sie bleibt das Verhalten wie bisher
druckrechteck_xmin/… stehen jetzt im KBS des Druckrechteck-Layers
Dokumentiert in schnittstellen.md Abschnitt 2a (Projektwissen-Branch docs/99-druck-kbs)
Übergabenotiz
Stand: fertig bis auf den QGIS-Test. Branch bugfix/99-druck-kbs (1 Commit). Gehört zusammen mit Plugin_SN_Verfahrensgebiet:bugfix/99-zoom-kbs; dieser PR zuerst.
Ursache: Dasselbe Muster an drei Stellen: Ausdehnungen wurden ohne Umrechnung zwischen Layer-KBS und Projekt-/Kartenansicht-KBS weitergegeben (Zoom in Verfahrensgebiet, Layoutkarte, Druckrechteck). Die Basemap-Legende stimmte, weil basemap_legende.auswertegeometrie schon umrechnet.
Entscheidungen (mit Daniel abgestimmt): Die Layoutkarte steht im KBS des Verfahrensgebiets, nicht im Projekt-KBS. So stehen Randkoordinaten, Gitter (500 m) und Maßstab immer im amtlichen KBS. Die allgemeine Prüfung des Projekt-KBS mit Vorschlag des amtlichen KBS nach Länderkennung wird ein eigenes Issue (Entwurf entwuerfe/20261005-221544-issue-Plugin_SN_Basis.md).
Im QGIS-Test zu prüfen (Projekt-KBS z. B. auf EPSG:3857 stellen):
Verfahrensgebiet laden (ALKIS und Shape): Die Karte springt auf das Gebiet (braucht auch den Verfahrensgebiet-PR).
§ 41-Vorlage mit Druckbereich „Verfahrensgebiet“: Die Karte ist gefüllt, die Randkoordinaten stehen in UTM 33 (sechs- bzw. siebenstellig), der Maßstab stimmt.
Dasselbe mit „wie Kartenfenster“, „Auswahl“ und „Rechteck“ (Rechteck neu zeichnen: Der Layer „Druckrechteck“ liegt deckungsgleich unter dem Gezeichneten).
Baufreigabe-Layout und Atlas einmal durchspielen.
Gegenprobe mit Projekt-KBS 25833: alles wie vorher.
Bekannte Restpunkte (nicht geändert): Ohne Verfahrensgebiet-Layer legt print_logic das Druckrechteck und den Atlaslayer mit dem Rückfall EPSG:25832 an (print_logic.py, _create_druckrechteck_layer und Atlaslayer). Für Sachsen wäre 25833 richtig, gehört aber zum Folge-Issue (amtliches KBS nach Länderkennung).
## Was
War ein anderes Projekt-KBS als das des Verfahrensgebiets eingestellt, entstand das Drucklayout mit leerer Karte und falschen Koordinaten: Die Ausdehnung kam im Layer-KBS (25833), die Layoutkarte rechnete im Projekt-KBS. Die Hauptkarte bekommt jetzt das KBS des Verfahrensgebiet-Layers (ohne Verfahrensgebiet das Projekt-KBS), und alle Druckbereiche werden dorthin umgerechnet. Das gezeichnete Druckrechteck wird vor dem Speichern in das KBS seines Layers umgerechnet. Neu sind die Funktionen `transformiere_rechteck` und `zoom_auf_layer`, die der Zoom-Fix in Verfahrensgebiet nutzt. Issue: #99
## Wie geprüft
- `python scripts/run_tests.py sn_basis --baseline`: GRÜN 475/475, unverändert gegenüber Baseline (11 neue Tests in `tests/test_druck_kbs.py`)
- `sn_plan41`: unverändert gegenüber Baseline. `sn_verfahrensgebiet`: siehe PR dort.
- Ohne die Korrektur sind die neuen Tests rot, schon weil `transformiere_rechteck`/`zoom_auf_layer` fehlen. Die Umrechnungsrichtung (Quell- → Ziel-KBS) prüfen die Tests einzeln je Druckbereich.
- QGIS-Test: **steht aus** (siehe Übergabenotiz)
## Änderungen an Verträgen
- Neu: `qgiscore_wrapper.transformiere_rechteck(rechteck, quell_crs, ziel_crs, project=None)`, `qgisui_wrapper.zoom_auf_layer(layer, canvas=None)`
- `PrintLayout.create_single_page_layout(..., crs=None)` und `PrintLayoutBaufreigabe.create_baufreigabe_layout(..., crs=None)`: neuer optionaler Parameter, setzt das KBS der Hauptkarte vor der Ausdehnung
- `PrintLogic._resolve_extent(..., druck_crs=None)`, `_store_druckrechteck(..., quell_crs=None)`: optionale Parameter, ohne sie bleibt das Verhalten wie bisher
- `druckrechteck_xmin/…` stehen jetzt im KBS des Druckrechteck-Layers
- Dokumentiert in `schnittstellen.md` Abschnitt 2a (Projektwissen-Branch `docs/99-druck-kbs`)
## Übergabenotiz
**Stand:** fertig bis auf den QGIS-Test. Branch `bugfix/99-druck-kbs` (1 Commit). Gehört zusammen mit `Plugin_SN_Verfahrensgebiet:bugfix/99-zoom-kbs`; **dieser PR zuerst**.
**Ursache:** Dasselbe Muster an drei Stellen: Ausdehnungen wurden ohne Umrechnung zwischen Layer-KBS und Projekt-/Kartenansicht-KBS weitergegeben (Zoom in Verfahrensgebiet, Layoutkarte, Druckrechteck). Die Basemap-Legende stimmte, weil `basemap_legende.auswertegeometrie` schon umrechnet.
**Entscheidungen (mit Daniel abgestimmt):** Die Layoutkarte steht im KBS des Verfahrensgebiets, nicht im Projekt-KBS. So stehen Randkoordinaten, Gitter (500 m) und Maßstab immer im amtlichen KBS. Die allgemeine Prüfung des Projekt-KBS mit Vorschlag des amtlichen KBS nach Länderkennung wird ein eigenes Issue (Entwurf `entwuerfe/20261005-221544-issue-Plugin_SN_Basis.md`).
**Im QGIS-Test zu prüfen (Projekt-KBS z. B. auf EPSG:3857 stellen):**
1. Verfahrensgebiet laden (ALKIS und Shape): Die Karte springt auf das Gebiet (braucht auch den Verfahrensgebiet-PR).
2. § 41-Vorlage mit Druckbereich „Verfahrensgebiet“: Die Karte ist gefüllt, die Randkoordinaten stehen in UTM 33 (sechs- bzw. siebenstellig), der Maßstab stimmt.
3. Dasselbe mit „wie Kartenfenster“, „Auswahl“ und „Rechteck“ (Rechteck neu zeichnen: Der Layer „Druckrechteck“ liegt deckungsgleich unter dem Gezeichneten).
4. Baufreigabe-Layout und Atlas einmal durchspielen.
5. Gegenprobe mit Projekt-KBS 25833: alles wie vorher.
**Bekannte Restpunkte (nicht geändert):** Ohne Verfahrensgebiet-Layer legt `print_logic` das Druckrechteck und den Atlaslayer mit dem Rückfall `EPSG:25832` an (`print_logic.py`, `_create_druckrechteck_layer` und Atlaslayer). Für Sachsen wäre 25833 richtig, gehört aber zum Folge-Issue (amtliches KBS nach Länderkennung).
## Checkliste
- [x] Nur Änderungen zum Issue
- [x] Keine direkten Qt/QGIS-Importe, keine Debug-`print`
- [x] `changelog.txt` ergänzt
- [x] Wissensbasis nachgezogen (schnittstellen 2a, fallstricke, modulkarte, STATUS, Testkatalog)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Bei anderem Projekt-KBS als dem des Verfahrensgebiets entstand das
Drucklayout mit leerer Karte und falschen Koordinaten: die Ausdehnung kam
im Layer-KBS, die Layoutkarte rechnete im Projekt-KBS. Die Hauptkarte
bekommt jetzt das KBS des Verfahrensgebiet-Layers, alle Druckbereiche
werden dorthin umgerechnet, ebenso das gezeichnete Druckrechteck.
Neue Wrapper-Funktionen transformiere_rechteck und zoom_auf_layer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Daniel
merged commit f07522fbe8 into unstable2026-10-05 20:23:45 +00:00
Daniel
deleted branch bugfix/99-druck-kbs2026-10-05 20:23:45 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Was
War ein anderes Projekt-KBS als das des Verfahrensgebiets eingestellt, entstand das Drucklayout mit leerer Karte und falschen Koordinaten: Die Ausdehnung kam im Layer-KBS (25833), die Layoutkarte rechnete im Projekt-KBS. Die Hauptkarte bekommt jetzt das KBS des Verfahrensgebiet-Layers (ohne Verfahrensgebiet das Projekt-KBS), und alle Druckbereiche werden dorthin umgerechnet. Das gezeichnete Druckrechteck wird vor dem Speichern in das KBS seines Layers umgerechnet. Neu sind die Funktionen
transformiere_rechteckundzoom_auf_layer, die der Zoom-Fix in Verfahrensgebiet nutzt. Issue: #99Wie geprüft
python scripts/run_tests.py sn_basis --baseline: GRÜN 475/475, unverändert gegenüber Baseline (11 neue Tests intests/test_druck_kbs.py)sn_plan41: unverändert gegenüber Baseline.sn_verfahrensgebiet: siehe PR dort.transformiere_rechteck/zoom_auf_layerfehlen. Die Umrechnungsrichtung (Quell- → Ziel-KBS) prüfen die Tests einzeln je Druckbereich.Änderungen an Verträgen
qgiscore_wrapper.transformiere_rechteck(rechteck, quell_crs, ziel_crs, project=None),qgisui_wrapper.zoom_auf_layer(layer, canvas=None)PrintLayout.create_single_page_layout(..., crs=None)undPrintLayoutBaufreigabe.create_baufreigabe_layout(..., crs=None): neuer optionaler Parameter, setzt das KBS der Hauptkarte vor der AusdehnungPrintLogic._resolve_extent(..., druck_crs=None),_store_druckrechteck(..., quell_crs=None): optionale Parameter, ohne sie bleibt das Verhalten wie bisherdruckrechteck_xmin/…stehen jetzt im KBS des Druckrechteck-Layersschnittstellen.mdAbschnitt 2a (Projektwissen-Branchdocs/99-druck-kbs)Übergabenotiz
Stand: fertig bis auf den QGIS-Test. Branch
bugfix/99-druck-kbs(1 Commit). Gehört zusammen mitPlugin_SN_Verfahrensgebiet:bugfix/99-zoom-kbs; dieser PR zuerst.Ursache: Dasselbe Muster an drei Stellen: Ausdehnungen wurden ohne Umrechnung zwischen Layer-KBS und Projekt-/Kartenansicht-KBS weitergegeben (Zoom in Verfahrensgebiet, Layoutkarte, Druckrechteck). Die Basemap-Legende stimmte, weil
basemap_legende.auswertegeometrieschon umrechnet.Entscheidungen (mit Daniel abgestimmt): Die Layoutkarte steht im KBS des Verfahrensgebiets, nicht im Projekt-KBS. So stehen Randkoordinaten, Gitter (500 m) und Maßstab immer im amtlichen KBS. Die allgemeine Prüfung des Projekt-KBS mit Vorschlag des amtlichen KBS nach Länderkennung wird ein eigenes Issue (Entwurf
entwuerfe/20261005-221544-issue-Plugin_SN_Basis.md).Im QGIS-Test zu prüfen (Projekt-KBS z. B. auf EPSG:3857 stellen):
Bekannte Restpunkte (nicht geändert): Ohne Verfahrensgebiet-Layer legt
print_logicdas Druckrechteck und den Atlaslayer mit dem RückfallEPSG:25832an (print_logic.py,_create_druckrechteck_layerund Atlaslayer). Für Sachsen wäre 25833 richtig, gehört aber zum Folge-Issue (amtliches KBS nach Länderkennung).Checkliste
printchangelog.txtergänzt🤖 Generated with Claude Code