Gemeindegrenzen am Seerhein: Uferlinie oder alles im Fluss? (Bund vs. Kanton und Gemeinde)

Liebe Community, euer Rat wird mal wieder gebraucht! Ich habe gestern Gemeindegrenzen am Seerhein korrigiert. Hierbei ist es interessant anzumerken, dass sich die Datensätze von Bund sowie Kanton TG und Gemeinde unterscheiden, ja gar widersprechen.

Der bundesweite Swisstopo-Datensatz weist die Gemeindegebiete bis zur Uferlinie aus. Die Wasserfläche an Untersee und Seerhein ist dabei als eine eigene „Fake-Gemeinde“ (bfs_nummer=9329) kartiert, um das ganze Kantonsgebiet mit Gemeindegeometrien auszufüllen (… wir erinnern uns, siehe hier)

Die Datensätze des Kanton Thurgau sowie auch weitere Quellen der Gemeinden Gottlieben, Eschenz und Tägerwilen weisen die Gemeindegrenzen dieser drei Gemeinden jedoch einschliesslich der Wasserfläche aus (Bei Eschenz nur der Abschnitt ab dem Eschenzerhorn Richtung Stein). Im Unterschied zu den übrigen thurgauischen Gemeinden am Untersee befinden sich diese drei Gemeinden am Seerhein bzw. am flussartig verengten Rheinsee. Ist also gewässertechnisch mehr Fluss als See.

Die übrige Wasserfläche des Untersees zwischen Eschenzerhorn und Triboltingen ist dagegen nicht kommunalisiert, die Gemeindegebiete enden hier an der Uferlinie. Die bundesweiten Swisstopo-Daten widersprechen hier nicht.

Nun haben hier schon einige Mapper verlautbaren lassen, dass die kantonalen Quellen vertrauenswürdiger seien als die bundesweiten Datensätze.

Ich habe diese Grenzverläufe von Gottlieben, Eschenz und Tägerwilen dahingehend korrigiert und die Landgrenzen über die Wasserflächen hinaus extrapoliert.

Dennoch hat ein nicht unbekannter User meine Änderungen sehr schnell rückgängig gemacht. Besonders lustig finde ich, dass er zuvor in einer Diskussion angeführt hat, dass der Umstand, „ob Wasserflächen zu dem Gemeindegebiet dazu gehör[en] oder nicht vom jeweiligen Kanton bestimmt“ wird. Und dennoch trotz meiner Belege die Änderung rückgängig gemacht hat. Mit swisstopo als Quelle. Die Umfangsgrenze des Bezirkes Kreuzlingen hat er dabei auch noch ordentlich zerschossen.

Ich möchte darum bitten, dass hier jemand diesen Sachverhalt fachlich und sachlich einordnet. Aus welchem Grund weist ein Kanton Gemeindegebiet über die Gewässerfläche hinaus aus, während das Bundesamt die entsprechenden Daten abweichend führt? Welche Daten sind dabei der Darstellung in OSM vorzuziehen?

Darfst dich beruhigen ich hab beim Kanton Thurgau offiziell angefragt wie sie das sehen mit der Differenz zur swisstopo. Es immerhin nett, dass du jetzt einsiehts, dass ein Diskussion mit der betroffenen Community bevor du eigenmächtig bestimmts bestehendes Mapping und Konventionen umzustossen vielleicht doch nötig ist.

Der Einfachheit halber würde ich es vorziehen, die Grenzen anhand der Gegebenheiten in swissBOUNDARIES3D zu erfassen.
Dies ist auch die Datengrundlage für die Auswertung der Übereinstimmung der Grenzpolygone in OSM mit den offiziellen Daten, die ich in den letzten paar Wochen versucht habe (mit KI-Unterstützung) versucht habe zu generieren: swissBOUNDARIES3D <-> OpenStreetMap

Die Grenze im Wasser wird wohl realistischer sein bezüglich “reality on the ground” als am Ufer. z.B. werden für Fischerei- oder Gewässerschutzvergehen wohl kaum die Gerichte der Gemeinde 9329 zuständig sein.

Die Gemeinden neben zu haben aber unbestritten die Grenze am Ufer und keine ausufernde deliktische Tätigkeit im Wasser (hint: Kantonsgebiet ist es so oder so).

Es geht hier lediglich um a) die Differenz zu der swisstopo die wir als Referenz verwenden für die QA, und b) ob die 3 Wasserstücke in diesen 3 Gemeinden vom Kanton Thurgau tatsächlich anders behandelt werden als die entsprechenden Stücke an anderen Teilen des Bodensees.

Gottlieben und Tägerwilen liegen am Seerhein, der streng genommen gar nicht zum Bodensee gehört. Der Bodensee besteht faktisch aus zwei getrennten Seen – Obersee und Untersee –, die durch den kurzen Flussabschnitt des Seerheins miteinander verbunden sind. Warum also sollte der Kanton die Gemeindefläche von Tägerwilen anders behandeln als zu Beispiel die von Diessenhofen (dort fliesst nämlich das gleiche Wasser vorbei).

Gut möglich, dass man im entfernten Wabern diesen Sachverhalt nicht ganz so differenziert einordnet und einfach mal pauschal alle Wasserflächen zwischen Stein am Rhein und Konstanz von den Thurgauer Gemeinden ausgestanzt hat.

Ich hab’ keine Ahnung wieso die Grenzen aus dem Zonenplan der Gemeinden und die Grenzen von swissBOUNDARIES3D nicht dieselben sind.

Die Auswertung auf http://boundaries.osm.ch/ (neue Webadresse, BTW) ist nicht machbar, wenn wir für jede Gemeinde den Zonenplan raussuchen müssen, oder Spezialfälle implementieren sollen.

Mal abgesehen davon das der Zonenplan eben der Zonenplan ist und nicht die aktuell geltenden Grenzen, habe ich wie schon gesagt bei unseren Kontakten bei ThurGis nachgehakt und werde wenn ich eine Antwort habe berichten.

So oder so die swisstopo verifiziert die Grenzen mit dem jeweiligen Kanton und passt sie in ihrem Datensatz jeweils an, siehe die mehreren anderen Threads zum Thema. Da diese keine originäre OSM Daten sind die wir selbst erhoben haben gibt es auch keinen Grund einfach ohne die Konsequenzen genau zu bedenken eine andere Quelle zu verwenden, und manchmal gibt es keine wirklich befriedigende Lösung. Siehe z.B. die Grenze nach Italien wo die swisstopo Daten grössere und kleinere Differenzen zu den offiziellen Italienischen Quellen haben.

2 Likes

I wonder what happens when a municipality that is on the river merges with one that is on the lake. Do they keep the old borders or consider it all river ? Triboltingen is that river or lake?

Friendly reminder, dass sich die Grenzen aus den Zonenplänen der angesprochenen Gemeinden und jene des kantonalen Verwaltungsgrenzendatensatzes nicht widersprechen.

Die du weder noch als Quelle deiner Edits angegeben hast.

source=* ist auf 255 Zeichen beschränkt, die 3 Links gingen sich einfach nicht aus.

Ich denke es war eher so, dass du (wie ja auch schon für andere Quellen) die Zulässigkeit der Zonenpläne als Quelle nicht überprüft hast, die ist übrigens auch weiterhin unklar. Der Kanton Thurgau hat seit ein paar Jahren eine sehr gute Opendata Politik, die Grenzen von dort hätte man also beziehen und mit einem (1) Hinweis der locker in 255 Buchstaben gepasst hätte dokumentieren können, aber wie schon gesagt es ist sinnfrei ohne Absprache einfach die Quelle für so was zu ändern.

Und nicht zuletzt: du machst die Kraut- und Rüben Changesets, die wie dir schon wiederholt gesagt wurde, zu gross und nicht nachvollziehbar sind (auch von den Quellen her wie man sieht). Es zwingt dich niemand dazu.

Und die Antwort ist da (für bessere Lesbarkeit etwas umformatiert):

Sehr geehrter Herr Poole

Ihre Anfrage wurde an mich weitergeleitet.

Die Ursache des unterschiedlichen Datenstandes liegt darin, dass im Bereich 
des Untersees noch kein Staatsvertrag über den rechtsgültigen Verlauf der 
Landesgrenze zwischen Deutschland und der Schweiz existiert. Die 
Vernehmlassung CH zu einem solchen Vertrag fand im Sommer 2025 statt. 
Die Rückmeldungen aus der Vernehmlassung befinden sich seitdem in 
der Konsolidierungsphase. Der aktuelle Stand der deutschen Kollegen entzieht 
sich meiner Kenntnis. Das Bundesamt für Landestopografie swisstopo, Bereich 
Vermessung, ist seitens Bund hierfür zuständig und könnte weitere Auskünfte 
erteilen.

Sobald der Staatsvertrag ratifiziert wurde, könnte grundsätzlich eine 
flächendeckende Bereinigung der Daten in Betracht gezogen werden. Darüber 
hätte swisstopo in Rücksprache mit den betroffenen Kantonen zu entscheiden. 
Zum gegenwärtigen Zeitpunkt besteht infolge der vorliegenden Rechtsunsicherheit 
allerdings (noch) kein Bedarf.

Sprich im Augenblick gibt es da keinen definitiven Grenzverlauf, wenn der besteht werden die Daten bereinigt. IMHO heisst das sinnvollerweise für uns wir bleiben bis zu dem Zeitpunkt bei den gleichen Grenzdaten wie für den Rest der Schweiz, und mit dem QA Prozess der jetzt täglich läuft besteht auch keine Gefahr mehr, dass wir eine allfällige Änderung verpassen.

Wenn das die Quintessenz der ganzen Debatte ist, kannst auch eigentlich gleich irgendwo ins Wiki schreiben, dass Swisstopo der Heilige Gral ist und kantonale Quellen für die Tonne sind. Dann brauchst du beim nächsten Mal keine unnötige Diskussion mehr anzetteln.

Hast du einen anderen Vorschlag, damit “wir” als Schweizer Community alle Gemeindegrenzen im Rahmen einer Qualitätssicherung mit http://boundaries.osm.ch “überwachen” können?

Dort taucht nämlich Relation: ‪Eschenz‬ (‪1684518‬) | OpenStreetMap als einzige Gemeindegrenze auf, die sich im letzten Monat gegenüber den offiziellen swisstopo-Daten verschlechtert hat.

Es ist noch gar nicht so lange her, da wurden nach einer Forendiskussion zwei admin_level=8-Seeflächenrelationen aus OSM gelöscht, weil in dem einen Teil vom See die Grenzen nicht geregelt sind.

Diese Fake-Gemeinden sind mit ihrer Geometrie und BFS-Nummer Bestandteil des landesweiten Swisstopo-Datensatzes, den du in deinem automatisierten QS-Workflow herangezogen hast. Was ich sagen will: Wir sind jetzt schon dabei, dass wir den Datenbestand von Swisstopo in OSM gar nicht eins zu eins abbilden.

Ich finde es sehr gut, dass dein Projekt eine automatisierte Kontrollinstanz für den OSM-Datenbestand schafft und sich jemand proaktiv darum kümmert. Warum kann man nicht einfach Ausnahmen für diese 3 Gemeinden definieren oder die KI zusätzlich mit thurgauischen Daten füttern (sofern Lizenzen das erlauben)? Meiner Meinung nach sollte OSM die realen Gegebenheiten abbilden und nicht staatstheoretische Grenzfälle wie im oben genannten Beispiel reproduzieren.

Klar kann “man” das.
Machst du das?
Der Code dazu ist offen verfügbar: GitHub - habi/swissboundaries: Vibe-coding to match boundaries from swissBOUNDARIES3D to OpenStreetMap. · GitHub

Wie sind die thurgauischen Daten verfügbar?

The question appears to be if we want Swisstopo or local mappings. We could do a poll on that.

See the answer from the canton Thurgau. The question is more is there any reason we can’t wait till swisstopo and the canton have figured this out, or do we have to do extra, and in this case pointless (there is literally nothing that is better, just worse) work just to make one mapper happy.

1 Like