Pflege und Korrektur der deutschen Admin-Grenzen

Gehrke wrote:

Dieser Thread widmet sich Themen rund um die deutschen Verwaltungsgrenzen auf allen Ebenen.
Hierzu gehören z.B. erkannte Fehler/Korrekturen im Grenzverlauf, offene Polygone, grundsätzliche Tagging-Fragen usw.

Komplexere Unterthemen wie die Änderung von Gemeindegrenzen 2014 werden weiterhin in separaten Threads behandelt.

Abgeleitet von Thread: OSM Boundary Export

Prima so - bin derzeit ein wenig überfordert überlastet 😉

Das erste was mir einfällt: prefix, name und suffix. Da gibt es Grenzen, wo alles im Namen drin ist, welche wo das doppelt ist oder auch suffixe im Namen, die nach suffix könnten.

ich habe derzeit 18236 Administrative Grenzen von Deutschland drin; sollte wohl zu stemmen sein

country␣|␣count
---------+-------
A␣␣␣␣␣␣␣|␣␣2630
CH␣␣␣␣␣␣|␣␣2706
DE␣␣␣␣␣␣|␣18236
LU␣␣␣␣␣␣|␣␣␣191
PL␣␣␣␣␣␣|␣␣6699

Gruss
walter

Ich zähle übrigens 11354 Gemeinden in DE. Alle mit type=boundary, Gemeindeschlüssel, Regionalschlüssel und Name. Ob die Angaben allerdings alle stimmen...
Dazu kommen 402 Kreise; alle mit type=boundary, Name und Regionalschlüssel.
An der Küste gibt es teils noch eine Variante mit type=land_area.

Gehrke wrote:

Ich zähle übrigens 11354 Gemeinden in DE. Alle mit type=boundary, Gemeindeschlüssel, Regionalschlüssel und Name. Ob die Angaben allerdings alle stimmen...
Dazu kommen 402 Kreise; alle mit type=boundary, Name und Regionalschlüssel.
An der Küste gibt es teils noch eine Variante mit type=land_area.

tja, landarea ist auch ne riesige Baustelle.

"meine" Werte sind übrigens alle AL von 2 bis 12 obwohl bei 11 in den Daten Schluss ist.

Gruss
walter

Mal so zur Info: Von AL 2 bis AL 8 haben wir konsistent type=boundary. Für AL 9 gibt es 506 Mal type=multipolygon, für AL 10 sind das 861 Relationen.

wambacher wrote:

Das erste was mir einfällt: prefix, name und suffix. Da gibt es Grenzen, wo alles im Namen drin ist, welche wo das doppelt ist oder auch suffixe im Namen, die nach suffix könnten.

Dann gleich mal nachgefragt: Was ist ein gewünschter Präfix? "Stadt"?, ok. "Flecken"?, auch noch okay. "Einheitsgemeinde" oder "Gemeinde", nicht okay?
Die Referenz könnte das Gemeindeverzeichnis von DESTATIS sein. Dort steht der Präfix mit Komma abgetrennt hinter dem Gemeindenamen.
Allerdings gibt es da auch solche IMHO, sorry, teils albernen Dinger wie "Wisssenschaftsstadt", "Lutherstadt", "Universitätsstadt" usw. "Hansestadt" finde ich noch ok, aber da bin ich parteiisch 😉 Na ja, ist halt alles amtlich.

EDIT: Typo

Gehrke wrote:

Mal so zur Info: Von AL 2 bis AL 8 haben wir konsistent type=boundary. Für AL 9 gibt es 506 Mal type=multipolygon, für AL 10 sind das 861 Relationen.

Wenn mir das irgenwo unter die Finger kommt, ändere ich es.
In OSMI wird type=boundary angezeigt/moniert. Kann durch einen Klick ausgeblendet werden, wird aber u.U. als Fehler aufgefasst, daher vielleicht die type=multipolygon.

Gehrke wrote:

wambacher wrote:

Das erste was mir einfällt: prefix, name und suffix. Da gibt es Grenzen, wo alles im Namen drin ist, welche wo das doppelt ist oder auch suffixe im Namen, die nach suffix könnten.

Dann gleich mal nachgefragt: Was ist ein gewünschter Präfix? "Stadt"?, ok. "Flecken"?, auch noch okay. "Einheitsgemeinde" oder "Gemeinde", nicht okay?
Die Referenz könnte das Gemeinderverzeichnis von DESTATIS sein. Dort steht der Präfix mit Komma abgetrennt hinter dem Gemeindenamen.
Allerdings gibt es da auch solche IMHO, sorry, teils albernen Dinger wie "Wisssenschaftsstadt", "Lutherstadt", "Universitätsstadt" usw. "Hansestadt" finde ich noch ok, aber da bin ich parteiisch 🤔 Na ja, ist halt alles amtlich.

Ich bin dafür, nur den "nackten" Namen nach name zu übernehmen (übrigens auch bei place etc), alle Präfixe (auch Hansestadt) in den subtag prefix und alle Suffixe (Frankfurt am Main / an der Oder) nach suffix.
Nur wenn das immer zusammen verwendet wird, soll es nach name.
Mit fällt da Sankt Gallen ein, das ich noch nie als "Gallen" gesehen habe.

seichter wrote:

Ich bin dafür, nur den "nackten" Namen nach name zu übernehmen (übrigens auch bei place etc), alle Präfixe (auch Hansestadt) in den subtag prefix und alle Suffixe (Frankfurt am Main / an der Oder) nach suffix.
Nur wenn das immer zusammen verwendet wird, soll es nach name.
Mit fällt da Sankt Gallen ein, das ich noch nie als "Gallen" gesehen habe.

Falls Du mich missverstanden haben solltest: Hansestadt usw. gehört natürlich nicht zu "name". Aber was wollen wir alles alles Präfix taggen oder doch weglassen ("Einheitsgemeinde").

Gehrke wrote:

Aber was wollen wir alles alles Präfix taggen oder doch weglassen ("Einheitsgemeinde").

Was "offiziell" ist: Das Gemeindeverzeichnis scheint mir ein vernünftiges Kriterium.

Hier mal eine Übersicht aller Gemeinde-Präfixe in DE mit Häufigkeit:

"Ortsgemeinde";900
"Gemeinde";814
"Stadt";530
"Gemeindefreies␣Gebiet";160
"Kreisfreie␣Stadt";76
"Hansestadt";14
"Verbandsfreie␣Gemeinde";12
"Verbandsfreie␣Stadt";12
"Markt";11
"Einheitsgemeinde";10
"Flecken";8
"Kreisstadt";8
"Landeshauptstadt";7
"Marktgemeinde";4
"Lutherstadt";2
"Universitätsstadt";2

Und hier die teils recht kuriosen Einzelfälle:

"082155006066"
"Amtsfreie␣Gemeinde"
"Bundesland"
"Bundesstadt"
"Burggemeinde"
"documenta-Stadt"
"Einheitsgemeinde␣und␣Stadt"
"Freie␣und␣Hansestadt"
"Goethestadt"
"Insel"
"Klingenstadt"
"Kolpingstadt"
"Kreisangehörige␣Stadt"
"Kreisfreie␣Hansestadt"
"Kurort"
"Landgemeinde"
"Landstadt"
"Mehrortgemeinde"
"NRW-Klimakommune"
"Schloss-Stadt"
"Selbständige␣Gemeinde"
"Sennegemeinde"
"Stadt␣der␣Fern-Universität"
"Stadtkreis"
"Stadtstaat"
"Widukindstadt"
"Wissenschaftsstadt"

Gehrke wrote:

Hier mal eine Übersicht aller Gemeinde-Präfixe in DE mit Häufigkeit:

...

Hi, ich würde mit bei der Aktion nicht auf die Gemeinden oder Orte beschränken, die eine Kennzahl haben. Gerade in den höheren Leveln sieht es sehr konfus aus.
Diese Beschränkung ist zwar verständlich, bringt aber wohl nicht das - von mir - gewünschte Resultat: Sauber gerenderte Namen ALLER Administrativen Grenzen in Deutschland oder besser noch DACH.

Offene Fragen:
- was macht Nominatim?
- was macht Mapnik?

Hier mal meine "komplette" Liste (die kleinen Abweichungen klären wir später)

␣␣␣␣␣␣␣␣␣␣␣prefix␣␣␣␣␣␣␣␣␣␣␣␣|␣count
------------------------------+-------
Ortsgemeinde␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣900
Gemeinde␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣815
Ortsteil␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣710␣␣<---
Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣540␣<---
Stadtteil␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣335␣<---
Amt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣211
Verwaltungsgemeinschaft␣␣␣␣␣␣|␣␣␣197
Verbandsgemeinde␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣179
Gemeindefreies␣Gebiet␣␣␣␣␣␣␣␣|␣␣␣159
Samtgemeinde␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣102
Kreisfreie␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣74
Landkreis␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣74
Stadtbezirk␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣46␣<----
erfüllende␣Gemeinde␣␣␣␣␣␣␣␣␣␣|␣␣␣␣37
Ortschaft␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣35
Bundesland␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣15␣<-----
Hansestadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣15
Bezirk␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣12␣<----
Verbandsfreie␣Gemeinde␣␣␣␣␣␣␣|␣␣␣␣12
Verbandsfreie␣Stadt␣␣␣␣␣␣␣␣␣␣|␣␣␣␣12
Einheitsgemeinde␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣11
Markt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣11
Ortsamtsbereich␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣10␣<---???
Flecken␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣8
Kreisstadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣8
Landeshauptstadt␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣7
Verwaltungsverband␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣6
Marktgemeinde␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣4
Ortsbezirk␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣3␣<----
Stadtgebiet␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣3␣<----
Kreis␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣2
Lutherstadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣2
Ortsbereich␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣2␣<----
Statistischer␣Bezirk␣␣␣␣␣␣␣␣␣|␣␣␣␣␣2␣<----
Universitätsstadt␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣2
082155006066␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Amt␣Kirchspielslandgemeinden␣|␣␣␣␣␣1
Amtsfreie␣Gemeinde␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Bezirksteil␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1␣<----
Bundesstadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Burggemeinde␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
documenta-Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Einheitsgemeinde␣und␣Stadt␣␣␣|␣␣␣␣␣1
Erfüllende␣Gemeinde␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Goethestadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Große␣Kreisstadt␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Insel␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1␣<---
Klingenstadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Kolpingstadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Kreisangehörige␣Stadt␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Kreisfreie␣Hansestadt␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Kurort␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Landgemeinde␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Landstadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Mehrortgemeinde␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
NRW-Klimakommune␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Ortsteils␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1␣<----
OT␣(Ortsteil)␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1␣<---
OT(Ortsteil)␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1␣<----
Schloss-Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Selbständige␣Gemeinde␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Sennegemeinde␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Stadt␣der␣Fern-Universität␣␣␣|␣␣␣␣␣1
Stadtkreis␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Stadtstaat␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
VVG␣der␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Widukindstadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
Wissenschaftsstadt␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣1
(68␣rows)

Sehr oft wird name:prefix für einen Namensbestandteil (ok) aber auch für eine Einstufung/Kategorisierung (nicht ok?) verwendet.

Gruss
walter

wambacher wrote:

ich würde mit bei der Aktion nicht auf die Gemeinden oder Orte beschränken, die eine Kennzahl haben. Gerade in den höheren Leveln sieht es sehr konfus aus.
Diese Beschränkung ist zwar verständlich, bringt aber wohl nicht das - von mir - gewünschte Resultat: Sauber gerenderte Namen ALLER Administrativen Grenzen in Deutschland oder besser noch DACH.

Stimmt, mein Fokus ist halt er DE, aber muss ja nicht so bleiben. Kennzahlen (Regionalschlüssel) gibt es für alle (sub-nationalen) DE-Level bis runter zur Gemeinde.

wambacher wrote:

Sehr oft wird name:prefix für einen Namensbestandteil (ok) aber auch für eine Einstufung/Kategorisierung (nicht ok?) verwendet.

Ja, genau so würde ich das sehen, auch wenn dann leider so etwas wie "Stadt der FernUniversität" oder gar "NRW-Klimakommune" dabei herauskommt.

EDIT: Typo

Ein paar gröbere Schnitzer bei den Präfixen habe ich eben korrigiert.
Zu offiziellen Präfixen in NRW gibt es übrigens einen Wikipedia-Artikel: http://de.wikipedia.org/wiki/Liste_der_ … -Westfalen

Highlight: Die Mähdrescherstadt Harsewinkel

Gehrke wrote:

Und hier die teils recht kuriosen Einzelfälle:

...
"Bundesstadt"
...

Es kann nur eine geben. 🙂
Gilt auch für "documenta-Stadt".

Edbert (EvanE)

Admin-Relationen haben oft einen tag "population", der (Achtung: wertender Kommentar!) die Einwohnerzahl, die vor Jahren mal galt, angibt.

Spricht etwas dagegen, diese tags zu löschen? Immer nachpflegen ergibt wohl noch weniger Sinn.

Das betrifft übrigens ca. 1400 Relationen.

Gehrke wrote:

Spricht etwas dagegen, diese tags zu löschen? Immer nachpflegen ergibt wohl noch weniger Sinn.

Einwohnerzahlen ändern auch ja so gesehen ständig und werden ja immer z.B. durch das Statistische Bundesamt aktualisiert. Meiner Ansicht nach sind das Daten, die unpassen für OSM sind. Wichtig sind Regional- und Gemeindeschlüssel, da darüber der Nutzer zu solchen Listen vernüpfen kann.

Ich wäre für ein löschen...

Sven

streckenkundler wrote:

Ich wäre für ein löschen...

Dito, Walter

wambacher wrote:

Ich wäre für ein löschen...

Ich stimme zu, dass die Einwohnerzahl auf die letzte Stelle genau als Geo-Information wenig sinnvoll ist.

Ich gebe aber zu bedenken, dass die Größenordnung einer Gemeinde schon eine nützliche Information ist. Die Einwohnerzahl stand mal verbreitet an den place-Knoten, ihr Fehlen wurde sogar vom OSMI angemahnt. Wenn wir jetzt die Aufgaben der place-nodes zu den admin-Relationen verlagern, müssen die halt auch zumindest grob deren Tag-Infos übernehmen. Eine Typisierung der Art 1-1000, 1000-10000 usw müsste aber eigentlich genügen.

Löschen geht immer schneller als Eintragen (wie war das mit den paar Bytes in der Datenbank?).

seichter wrote:

Löschen geht immer schneller als Eintragen (wie war das mit den paar Bytes in der Datenbank?).

Das Problem liegt wohl eher in der Vollständigkeit. Derzeit finde ich 1260 von 12977 Admin-Grenzen AL2-8 mit Population, also knapp 10%. Die anderen 90% müssten entweder aus den Place-Tags kopiert oder gar von anderen Quellen besorgt werden.

Sorry, da hab ich besseres zu tun.

Gruss
walter

In Österreich ist es mit den Prefixen ganz schlimm!
Irgendwer hat das mal durchgezogen und ALLE Gemeinden, Bezirke mit Geminde .... oder Bezirk... versehen.

Ich denke das ist unsinn und gehört wieder gelöscht! (oder in ein Prefix oder type oder was auch immer Tag!)

curmet wrote:

In Österreich ist es mit den Prefixen ganz schlimm!
Irgendwer hat das mal durchgezogen und ALLE Gemeinden, Bezirke mit Geminde .... oder Bezirk... versehen.

Ich denke das ist unsinn und gehört wieder gelöscht! (oder in ein Prefix oder type oder was auch immer Tag!)

Ich hab mal als Stichprobe bei Bregenz nachgesehen: Da taucht Bezirk bei Hörbranz nur im tag "is_in" auf und der ist ist sowieso eher Lyrik.
Im AL6 steht als name=Bezirk Bregenz, das würde in D üblicherweise als name:prefix:de=Bezirk getaggt (analog zu Landkreis Lindau).
Die Unterscheidung zur Stadt Bregenz geht neben dem prefix vor allem über den admin_level. Ich habe mir erlaubt, dort note=Stadt zu name:prefix zu machen.
Anm.: wikipedia:de=Bezirk Bregenz gibt es aber.

seichter wrote:

wambacher wrote:

Ich wäre für ein löschen...

Ich stimme zu, dass die Einwohnerzahl auf die letzte Stelle genau als Geo-Information wenig sinnvoll ist.

Ich gebe aber zu bedenken, dass die Größenordnung einer Gemeinde schon eine nützliche Information ist.

Inwiefern? Um z.B. "Essen" größer zu rendern als "Gladbeck"? Das kann sein. Wie wird denn so etwas derzeit gemacht?
Für Auswertungen sollte man sich diese Info (über den Schlüssel) aber von DESTATIS oder auch Wikipedia holen.

curmet wrote:

In Österreich ist es mit den Prefixen ganz schlimm!
Irgendwer hat das mal durchgezogen und ALLE Gemeinden, Bezirke mit Geminde .... oder Bezirk... versehen.

Ich denke das ist unsinn und gehört wieder gelöscht! (oder in ein Prefix oder type oder was auch immer Tag!)

Shitstorm ich hör dir trapsen. Ich sage nur "subareas" in Polen 😉 Wenn die österreichische Community die Prefixe im Namen stören, sollte schon von dort die Initiative ausgehen, diese umzuschichten. Mir persönlich ist aber auch schon aufgefallen, dass da überall die Prefixe im Namen stehen.

Gehrke wrote:

Inwiefern? Um z.B. "Essen" größer zu rendern als "Gladbeck"? Das kann sein. Wie wird denn so etwas derzeit gemacht?
Für Auswertungen sollte man sich diese Info (über den Schlüssel) aber von DESTATIS oder auch Wikipedia holen.

Momentan scheint da kein schlauer Algorithmus dahinter zu stecken, der die Ortsnamen nach irgendwelchen Kriterien bevorzugt rendert. Ich denke dass momentan beim Rendern der Zufall zuschlägt, ala FIFO. Meiner Meinung nach wäre "population" aber schon ein gutes Kriterium, nach dem man rendern könnte. Genaue Zahlen braucht man dafür ja nicht, nur ungefähre.

JohnDoe23 wrote:

Momentan scheint da kein schlauer Algorithmus dahinter zu stecken, der die Ortsnamen nach irgendwelchen Kriterien bevorzugt rendert. Ich denke dass momentan beim Rendern der Zufall zuschlägt, ala FIFO. Meiner Meinung nach wäre "population" aber schon ein gutes Kriterium, nach dem man rendern könnte. Genaue Zahlen braucht man dafür ja nicht, nur ungefähre.

Willst du die fehlenden 90% ( ~11700 ) Tags nachtragen?

Viel Spass
walter

seichter wrote:

Ich hab mal als Stichprobe bei Bregenz nachgesehen:

Knapp daneben. Nimm mal Steiermark/Bezirk Leipnitz - dann sieht es gleich anders aus.

von den 2627 Admin-Grenzen in A haben 92 "Bezirk" und 1895 "Gemeinde" am Anfang des Namens - prefix:name wird nicht genutzt.

␣␣id␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣name␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣admin_level
---------+---------------------------------------------------+-------------
128099␣|␣Bezirk␣Amstetten␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
105088␣|␣Bezirk␣Baden␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
74804␣|␣Bezirk␣Bludenz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
417294␣|␣Bezirk␣Braunau␣am␣Inn␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
74231␣|␣Bezirk␣Bregenz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
112050␣|␣Bezirk␣Bruck␣an␣der␣Leitha␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
2661074␣|␣Bezirk␣Bruck-Mürzzuschlag␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
35202␣|␣Bezirk␣Deutschlandsberg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
75111␣|␣Bezirk␣Dornbirn␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
86256␣|␣Bezirk␣Eferding␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
79747␣|␣Bezirk␣Eisenstadt␣(Stadt)␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
103816␣|␣Bezirk␣Eisenstadt-Umgebung␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
...
86358␣|␣Gemeinde␣Abtenau␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
111872␣|␣Gemeinde␣Achau␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
103894␣|␣Gemeinde␣Aderklaa␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
373771␣|␣Gemeinde␣Adlwang␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
34727␣|␣Gemeinde␣Admont␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
86363␣|␣Gemeinde␣Adnet␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
950342␣|␣Gemeinde␣Afiesl␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
35100␣|␣Gemeinde␣Aflenz␣Kurort␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
35178␣|␣Gemeinde␣Aflenz␣Land␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
106156␣|␣Gemeinde␣Afritz␣am␣See␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
453187␣|␣Gemeinde␣Aggsbach␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
951081␣|␣Gemeinde␣Ahorn␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
35204␣|␣Gemeinde␣Aibl␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
50595␣|␣Gemeinde␣Aich␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
64854␣|␣Gemeinde␣Aichkirchen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
...
106089␣|␣Gemeinde␣Zillingtal␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
105353␣|␣Gemeinde␣Zistersdorf␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
110534␣|␣Gemeinde␣Zöbern␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
34907␣|␣Gemeinde␣Zwaring-Pöls␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
108217␣|␣Gemeinde␣Zwentendorf␣an␣der␣Donau␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
89547␣|␣Gemeinde␣Zwettl␣an␣der␣Rodl␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
405607␣|␣Gemeinde␣Zwettl-Niederösterreich␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
111827␣|␣Gemeinde␣Zwölfaxing␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣8
(1987␣rows)

Aber ich möchte auch nicht den Shitstorm erleben, wenn wir "Piefkes" das einfach ändern.

Eventuell äußert sich die lokale Community mal dazu? Ein eigenes Unterforum haben die ja hier nicht im Gegensatz zur Schweiz.

Gruss
walter

JohnDoe23 wrote:

Momentan scheint da kein schlauer Algorithmus dahinter zu stecken, der die Ortsnamen nach irgendwelchen Kriterien bevorzugt rendert. Ich denke dass momentan beim Rendern der Zufall zuschlägt, ala FIFO. Meiner Meinung nach wäre "population" aber schon ein gutes Kriterium, nach dem man rendern könnte. Genaue Zahlen braucht man dafür ja nicht, nur ungefähre.

Wenn das wirklich Zufall ist (ich glaube, ganz so simpel ist es nicht), scheint das einigermaßen zu funktionieren. Mein Eindruck ist auch, dass sich Mapnik eher an den place-nodes orientiert. 🙁

wambacher wrote:

Willst du die fehlenden 90% ( ~11700 ) Tags nachtragen?

Ohne, dass ich jetzt schon eine Meinung dazu hätte:
Man bräuchte ja eigentlich nur, die markieren, die hervorgehoben werden sollen könnten - nicht jede Mini-Gemeinde mit <1000 Einwohnern.
Der default-Wert für AL8-Relationen wäre also Kategorie "Mini".

EDIT: etwas präzisiert; Typo

wambacher wrote:

von den 2627 Admin-Grenzen in A haben 92 "Bezirk" und 1895 "Gemeinde" am Anfang des Namens - prefix:name wird nicht genutzt.

Ich möchte zu bedenken geben, dass in DE ja auch meist Kreis/Landkreis vor denselbigen steht (nicht als Präfix). Ich dachte da auch ein (sinnvolles) Muster zu erkennen. Wenn der Kreis nach einer Stadt benannt ist, heißt er z.B. "Landkreis Göttingen", nicht "Göttingen". Niemand würde zu dem Landkreis nur "Göttingen" sagen.

Gehrke wrote:

Ich möchte zu bedenken geben, dass in DE ja auch meist Kreis/Landkreis vor denselbigen steht (nicht als Präfix). Ich dachte da auch ein (sinnvolles) Muster zu erkennen. Wenn der Kreis nach einer Stadt benannt ist, heißt er z.B. "Landkreis Göttingen", nicht "Göttingen". Niemand würde zu dem Landkreis nur "Göttingen" sagen.

Gibt es öfter z.B. "Landkreis Ahrweiler" mit der Stadt "Ahrweiler" und "Landkreis Neuwied" mit der Stadt "Neuwied".
Ein Gegenbeispiel ist Koblenz (kreisfreie Stadt) und der Kreis "Mayen-Koblenz".

Edbert (EvanE)

EvanE wrote:

Ein Gegenbeispiel ist Koblenz (kreisfreie Stadt) und der Kreis "Mayen-Koblenz".

Somit ist das ja kein Gegenbeispiel, sondern bestätigt meine vermutete Regel. Der Kreis heißt nicht genau wie die Stadt.

Gehrke wrote:

Ohne, dass ich jetzt schon eine Meinung dazu hätte:
Man bräuchte ja eigentlich nur, die markieren, die hervorgeboben werden sollen - nicht jede Mini-Gemeinde mit <1000 Einwohnern.

Sorry, "Taggen für den Renderer" 🙁

Ich bin mehr von der "Wenn schon- denn schon"-Fraktion: wenn Population in osm, dann bitte für alle.

Gruss
walter

Gehrke wrote:

wambacher wrote:

von den 2627 Admin-Grenzen in A haben 92 "Bezirk" und 1895 "Gemeinde" am Anfang des Namens - prefix:name wird nicht genutzt.

Ich möchte zu bedenken geben, dass in DE ja auch meist Kreis/Landkreis vor denselbigen steht (nicht als Präfix). Ich dachte da auch ein (sinnvolles) Muster zu erkennen. Wenn der Kreis nach einer Stadt benannt ist, heißt er z.B. "Landkreis Göttingen", nicht "Göttingen". Niemand würde zu dem Landkreis nur "Göttingen" sagen.

Klar, für die Landkeise/Bezirke ist das schon richtig: entweder alle beim Namen oder alle als Prefix. Zweiteres wäre mir am liebsten.
Aber 1895x "Gemeinde xyz" als Namen? Na ich weiss nicht recht.

Gruss
walter

EDIT: Bin mir jetzt auch nicht mehr sicher: "Landkreis xyz" bzw. "Bezirk xyz" für den Kreis/Bezirk und "xyz" für die gleichnamige Stadt ist auch nicht schlecht.

wambacher wrote:

Gehrke wrote:

Ohne, dass ich jetzt schon eine Meinung dazu hätte:
Man bräuchte ja eigentlich nur, die markieren, die hervorgeboben werden sollen - nicht jede Mini-Gemeinde mit <1000 Einwohnern.

Sorry, "Taggen für den Renderer" 🙁

Is scho recht. Aber letztlich geht es bei OSM um Kartendaten, die meist auch dargestellt werden sollen.
Insofern taggen wir alle letztlich für irgendeinen Renderer. Ich "rendere" oft nur Text auf die Konsole... 😉

Ich verstehe "Taggen für den Renderer" eher als "Taggen, so dass ich den Algorithmus bestimmter Renderer so austrickse, dass sie meine Sachen so darstellen, wie ich es gerne hätte." Meine Formulierung "hervorgehoben werden sollen" ist in dieser Hinsicht sicher ungünstig, weil einschlägig.

Dass man für eine 08/15-Standard-Übersichtskarte Deutschland zusätzlich zu OSM noch DESTATIS-Daten einlesen und mappen muss, finde ich aber auch nicht recht einleuchtend. Wenn es trotzdem anders geht - prima.

EDIT: Typo

HI,

gibt es noch Einwände, aus name:prefix=Landkreis und name=Posemuckl name=Landkreis Posemuckl zu machen?

Aktuelle - für mich untragbare - Situaton:

osm_id␣␣|␣country␣|␣name:prefix␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣name␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣name:postfix
---------+---------+-------------+------------------------------------+--------------
62623␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Ahrweiler␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62492␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Altenburger␣Land␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62357␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Altenkirchen␣(Westerwald)␣␣␣␣␣␣␣␣␣␣|
62680␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Alzey-Worms␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62747␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Anhalt-Bitterfeld␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62454␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Bad␣Dürkheim␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62741␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Bad␣Kreuznach␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62384␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Bautzen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62712␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Berchtesgadener␣Land␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62668␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Bernkastel-Wittlich␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2804156␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Biberach␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62679␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Birkenfeld␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62359␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Börde␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62569␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Cochem-Zell␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62704␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Darmstadt-Dieburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62500␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Eichsfeld␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62700␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Fulda␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62698␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Germersheim␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62692␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Gießen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62345␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Görlitz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62468␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Gotha␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62445␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Greiz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62429␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Harz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2812850␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Heidenheim␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62637␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Hersfeld-Rotenburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62365␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Hildburghausen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62477␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Jerichower␣Land␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62401␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Kassel␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62367␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Kusel␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62765␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Amberg-Sulzbach␣␣␣␣␣␣␣␣␣␣|
62689␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Ammerland␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62609␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Ansbach␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62497␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Aschaffenburg␣␣␣␣␣␣␣␣␣␣␣␣|
62622␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Augsburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62355␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Aurich␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62627␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Bamberg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62378␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Bayreuth␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62721␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Böblingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
1946367␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Breisgau-Hochschwarzwald␣|
62601␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Calw␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62608␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Celle␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62597␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Cloppenburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62561␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Coburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2083535␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Cuxhaven␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62426␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Diepholz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2168230␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Ebersberg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
1946117␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Emmendingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62540␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Emsland␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62356␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Erding␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2812851␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Esslingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62354␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Freudenstadt␣␣␣␣␣␣␣␣␣␣␣␣␣|
62773␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Friesland␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62778␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Fürth␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62647␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Gifhorn␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2812852␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Göppingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62669␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Goslar␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62386␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Göttingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62550␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Grafschaft␣Bentheim␣␣␣␣␣␣|
62766␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Hameln-Pyrmont␣␣␣␣␣␣␣␣␣␣␣|
2083497␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Harburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62674␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Heidekreis␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62750␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Heilbronn␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62416␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Helmstedt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62742␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Hildesheim␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2145179␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Hof␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62510␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Holzminden␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62451␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Kaiserslautern␣␣␣␣␣␣␣␣␣␣␣|
62393␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Karlsruhe␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62603␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Konstanz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62657␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Landshut␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62567␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Leer␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62434␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Leipzig␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62587␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Lörrach␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62662␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Lüchow-Dannenberg␣␣␣␣␣␣␣␣|
62536␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Ludwigsburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2084746␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Lüneburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62580␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣München␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62728␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Nienburg␣an␣der␣Weser␣␣␣␣|
62613␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Northeim␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62648␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Oldenburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62673␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Osnabrück␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62399␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Osterholz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62677␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Osterode␣am␣Harz␣␣␣␣␣␣␣␣␣|
62541␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Passau␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62494␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Peine␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62388␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Rastatt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62565␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Regensburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2796980␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Reutlingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2156362␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Rosenheim␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
1739377␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Rostock␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62617␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Rotenburg␣an␣der␣Wümme␣␣␣|
62344␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Rottweil␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62762␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Schaumburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62582␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Schwäbisch␣Hall␣␣␣␣␣␣␣␣␣␣|
62530␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Schweinfurt␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62482␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Stade␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62575␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Tirschenreuth␣␣␣␣␣␣␣␣␣␣␣␣|
2156363␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Traunstein␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2797036␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Tübingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62682␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Tuttlingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62743␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Uelzen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62666␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Vechta␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62740␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Verden␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62716␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Waldshut␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62731␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Wesermarsch␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62425␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Wittenberg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62397␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Wittmund␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62558␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Wolfenbüttel␣␣␣␣␣␣␣␣␣␣␣␣␣|
62465␣|␣DE␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Landkreis␣Würzburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62585␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Limburg-Weilburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
1739381␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Ludwigslust-Parchim␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62632␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Mainz-Bingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62681␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Mansfeld-Südharz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62643␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Marburg-Biedenkopf␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62572␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Mayen-Koblenz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
1739376␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Mecklenburgische␣Seenplatte␣␣␣␣␣␣␣␣|
62511␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Meißen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62387␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Merzig-Wadern␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62350␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Mittelsachsen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2168232␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Mühldorf␣a.Inn␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62474␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Neunkirchen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62348␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Neuwied␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62621␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Nordhausen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62547␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Nordsachsen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62715␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Offenbach␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62353␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Potsdam-Mittelmark␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
2808774␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Ravensburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62661␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Rhein-Erft-Kreis␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62447␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Saalfeld-Rudolstadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62466␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Saarlouis␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62485␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Sächsische␣Schweiz-Osterzgebirge␣␣␣|
62618␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Schmalkalden-Meiningen␣␣␣␣␣␣␣␣␣␣␣␣␣|
2806390␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Sigmaringen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62588␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Sömmerda␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62552␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Sonneberg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62683␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Spree-Neiße␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62725␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Stendal␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62346␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣St.␣Wendel␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62653␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Südliche␣Weinstraße␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62360␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Südwestpfalz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62361␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Trier-Saarburg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
1431517␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Vorpommern-Greifswald␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
1739379␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Vorpommern-Rügen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62615␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Vulkaneifel␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62563␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Waldeck-Frankenberg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62462␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Weimarer␣Land␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
62785␣|␣DE␣␣␣␣␣␣|␣Landkreis␣␣␣|␣Zwickau␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|
(147␣rows)

also knapp 50/50

Gruss
walter

Gehrke wrote:

Inwiefern? Um z.B. "Essen" größer zu rendern als "Gladbeck"? Das kann sein. Wie wird denn so etwas derzeit gemacht?
Für Auswertungen sollte man sich diese Info (über den Schlüssel) aber von DESTATIS oder auch Wikipedia holen.

Momentan scheint da kein schlauer Algorithmus dahinter zu stecken, der die Ortsnamen nach irgendwelchen Kriterien bevorzugt rendert. Ich denke dass momentan beim Rendern der Zufall zuschlägt, ala FIFO. Meiner Meinung nach wäre "population" aber schon ein gutes Kriterium, nach dem man rendern könnte. Genaue Zahlen braucht man dafür ja nicht, nur ungefähre.

Also der OSM-Bright Renderstyle sortiert die Orte auch nach population: https://github.com/mapbox/osm-bright/bl … 2pgsql.mml
Und auch der Lyrk renderstyle orientiert sich an der Einwohnerzahl bei der Reihenfolge der Labels. Das ist nicht immer ganz einfach, weil manchmal absurde Zahlen oder Abkürzungen in der Population stehen, aber prinzipiell funktioniert das. Für sowas reicht auch die ungefähre Einwohnerzahl, und ich aktualisiere sowas auch manchmal, wenn ich über eine Zahl stolper, die lange nicht mehr aktualisiert wurde.

von mir hast du ein OK !

Gehrke wrote:

seichter wrote:

wambacher wrote:

Ich wäre für ein löschen...

Ich stimme zu, dass die Einwohnerzahl auf die letzte Stelle genau als Geo-Information wenig sinnvoll ist.

Ich gebe aber zu bedenken, dass die Größenordnung einer Gemeinde schon eine nützliche Information ist.

Inwiefern? Um z.B. "Essen" größer zu rendern als "Gladbeck"? Das kann sein. Wie wird denn so etwas derzeit gemacht?
Für Auswertungen sollte man sich diese Info (über den Schlüssel) aber von DESTATIS oder auch Wikipedia holen.

Warum taggt man nicht die Gemeindegrenze mit dem Namen. Dann könnte der Renderer anhand der Fläche die Größe des Namens rendern.

hfst wrote:

Warum taggt man nicht die Gemeindegrenze mit dem Namen. Dann könnte der Renderer anhand der Fläche die Größe des Namens rendern.

hä? der Name steht doch längst in der Grenz-Relation drin. Und was hat das mit der Fläche (welcher überhaupt?) zu tun?

Gruss
walter

Mal eine andere Frage bezüglich Grenzen...

Gegeben sind die Admin-Grenzen. Gefunden werden place-nodes mit entsprechenden Angaben. Sofern sich die Grenzen mit den Angaben im place-node decken (die selbe admin-level-Ebene beschreiben) können dich die Attribute an die Grenze übertragen werden und der munkt entsorgt werden, oder?

fragt Sven

streckenkundler wrote:

Gegeben sind die Admin-Grenzen. Gefunden werden place-nodes mit entsprechenden Angaben. Sofern sich die Grenzen mit den Angaben im place-node decken (die selbe admin-level-Ebene beschreiben) können dich die Attribute an die Grenze übertragen werden und der munkt entsorgt werden, oder?

Ich gehe da folgendermaßen vor:

alle "wichtigen" Tags vom place-Node kommen an die Grenzrelation. Da gibt es aber nichts mehr als ab und zu ein population=* und da zweifel ich immer mehr, daß der noch wichtig ist. Der Rest (is_in, GEO-Server-Daten, place=*) wird nicht übernommen. Dann fliegt der place-Node raus.

Gruß
walter

Das finde ich nicht in Ordnung! Die Place-Nodes haben eine wichtige Funktion und sind viel robuster als irgendwelche Relationen, die schnell durcheinander kommen. Sie können auch leichter ausgewertet werden.

wambacher wrote:

streckenkundler wrote:

Gegeben sind die Admin-Grenzen. Gefunden werden place-nodes mit entsprechenden Angaben. Sofern sich die Grenzen mit den Angaben im place-node decken (die selbe admin-level-Ebene beschreiben) können dich die Attribute an die Grenze übertragen werden und der munkt entsorgt werden, oder?

Ich gehe da folgendermaßen vor:

alle "wichtigen" Tags vom place-Node kommen an die Grenzrelation. Da gibt es aber nichts mehr als ab und zu ein population=* und da zweifel ich immer mehr, daß der noch wichtig ist. Der Rest (is_in, GEO-Server-Daten, place=*) wird nicht übernommen. Dann fliegt der place-Node raus.
walter

Ich würde so wenig wie möglich in die Grenzrelation stecken, und die place-node beibehalten. Denn mit der kann man kontrollieren, wo auf der Karte der Name z. B. einer Gemeinde erscheint. Wenn die place-node nicht da ist, sondern der in der Grenzrelation eingetragene Name angezeigt wird, dann geschieht das sehr oft an einer unpassenden Stelle. Wichtig ist auch, dass die Grenzrelation und auch ein landuse=residential keinen name-tag enthalten, damit der Name nicht doppelt oder dreifach angezeigt wird.

Karl

mink wrote:

Ich würde so wenig wie möglich in die Grenzrelation stecken, und die place-node beibehalten. Denn mit der kann man kontrollieren, wo auf der Karte der Name z. B. einer Gemeinde erscheint.

Diese "Nebenaufgabe" des place-Nodes kann durch einen Label-Node übernommen werden. Allerdings wird der noch nicht von Mapnik gerendert.

Wichtig ist auch, dass die Grenzrelation und auch ein landuse=residential keinen name-tag enthalten, damit der Name nicht doppelt oder dreifach angezeigt wird.

bei Landuse stimme ich dir zu aber bei den Administrativen Grenzen war und ist der Name-Tag etabliert.

Die Hauptfunktion des Place-Nodes für Städte war es, Nominatim mit Suchinformationen zu versorgen; das machen die Grenzrelationen genauer und sicherer.

ansonsten gibt es seitenlange Diskussionen darüber im Forum - es ist mir nur zu spät, diese jetzt rauszusuchen.

Gruss
walter

wambacher wrote:

ansonsten gibt es seitenlange Diskussionen darüber im Forum - es ist mir nur zu spät, diese jetzt rauszusuchen.

z.B. Hier: http://forum.openstreetmap.org/viewtopic.php?id=23908

mink wrote:

Ich würde so wenig wie möglich in die Grenzrelation stecken, und die place-node beibehalten. Denn mit der kann man kontrollieren, wo auf der Karte der Name z. B. einer Gemeinde erscheint. Wenn die place-node nicht da ist, sondern der in der Grenzrelation eingetragene Name angezeigt wird, dann geschieht das sehr oft an einer unpassenden Stelle. Wichtig ist auch, dass die Grenzrelation und auch ein landuse=residential keinen name-tag enthalten, damit der Name nicht doppelt oder dreifach angezeigt wird.

Karl

Die Grenzrelation einer Gemeinde, Landkreis, ... sollte schon einen Namen haben. Woher soll man sonst wissen was die Grenzrelation beschreibt? Wo der name gerendert wird kann man über die Rolle "label" in der Grenzrelation festlegen: http://wiki.openstreetmap.org/wiki/Rela … on_members

Ich sehe die Place-Nodes aber als notwendiges übel an, zum einen weil die Relationen leider immer noch nicht vernünftig gerendert werden auf osm.org usw., zum anderen weil man oft den Grenzverlauf von Gemeindeteilen usw. nicht kennt. 3. sollte man ja sowieso einen label-Node setzen, da kann man dann ja einfach noch die place-Angaben mit dranpacken. Naja, ich denke die Diskussion gabs schon zu genüge.

Edit: Uhrzeit

Häufig haben die einzenen Ways, die die Grenze ausmachen, noch überflüssige Namen, die meines Erachtens auch raus können, da das von OSM auch so schon anhand der Relationen gerendert wird.

wambacher wrote:

alle "wichtigen" Tags vom place-Node kommen an die Grenzrelation. Da gibt es aber nichts mehr als ab und zu ein population=* und da zweifel ich immer mehr, daß der noch wichtig ist. Der Rest (is_in, GEO-Server-Daten, place=*) wird nicht übernommen. Dann fliegt der place-Node raus.

Danke bis hier her. Gerade der Umgang mit diesen is_in-Angaben, Geo-Server-Daten ect. war mir noch nicht ganz klar, aber alles kommt mit der Zeit an die Reihe.ich glaube, in meinem engeren Umfeld hab ich eh nur recht wenige place-nodes die eine nähere Betrachtung wert wären, z.T. fehlen mit da aber auch noch die Ortsteilgrenzen... Vor allem solange die fehlen behalte ich natürlich den Staus Quo bei.

Jetzt hab ich erst mal eine grobe Richtung und schaue mir das bei Gelegenheit an. Vorschnell löschen werd ich aber nicht.

Sven

streckenkundler wrote:

ich glaube, in meinem engeren Umfeld hab ich eh nur recht wenige place-nodes die eine nähere Betrachtung wert wären, z.T. fehlen mit da aber auch noch die Ortsteilgrenzen... Vor allem solange die fehlen behalte ich natürlich den Staus Quo bei.

Klar, da wo die Admin-Grenzen fehlen, macht der Place-Node durchaus Sinn; damit hat Nominatim zumindest einen Anhaltspunkt, wie die Gegend heisst.
Ansonsten möchte ich den Place-Node wirklich nur noch für kleine, überschaubare Ecken wie Locality, Hamlet, Island und sowas verwendet sehen.

Frage: Ich stoße immer wieder auf Administrative Grenzen mit z.B. place=city als Tag. Muss das so sein?
Sagt das Admin-Level das nicht aus?
Bei AL6 bin ich mir nicht sicher: Kreis? Kreisfreie Stadt? sonst was?

naja, mitschleppen kann man das wohl.

Gruß
walter

JohnDoe23 wrote:

Ich sehe die Place-Nodes aber als notwendiges übel an, zum einen weil die Relationen leider immer noch nicht vernünftig gerendert werden auf osm.org usw., zum anderen weil man oft den Grenzverlauf von Gemeindeteilen usw. nicht kennt. 3. sollte man ja sowieso einen label-Node setzen, da kann man dann ja einfach noch die place-Angaben mit dranpacken.

Sehe ich (leider) auch so. Wir taggen eben doch für Renderer. Der Aufschrei wäre groß, wenn in Deutschland plötzlich keine Städtenamen mehr zu sehen wären. Kenne da aber Mapnik nicht.
Trotzdem wäre ich dafür, dass sich das ändert! Die ganzen Tags am place-Node brauchen wir bei bestehender Relation wirklich nicht. Teils sind sie auch veraltet oder unnütz.

Für alles unter place=city|town bzw. admin_level>8 sind die Relationen meist noch kein Ersatz.

Noch mal ein Gedanke zum population-Tag: Ich weiß nicht ob Nominatim den verwendet, aber wenn ich ein Geocoder bauen würde, dann würde ich das Tag zum Ranking verwenden, bzw. ins ranking mit einfließen lassen.

wambacher wrote:

Frage: Ich stoße immer wieder auf Administrative Grenzen mit z.B. place=city als Tag. Muss das so sein?
Sagt das Admin-Level das nicht aus?
Bei AL6 bin ich mir nicht sicher: Kreis? Kreisfreie Stadt? sonst was?

naja, mitschleppen kann man das wohl.

Ich bin zwar auch kein Verfechter der place=city-Tags: Wenn ich mir aber ansehe, welche Einträge dort stellenweise vorhanden sind, von denen ich nicht weiß, ob sie überhaupt irgendeine Bedeutung haben (GEO-Server-Importe) oder vielleicht doch (TMC), ist es mir fast lieber, sie bleiben dort, als dass ich mit Gedanken machen muss, ob sie in die Grenzrelation verschoben werden sollten.
Da wir dem Renderer auch freundlicherweise Hinweise geben wollen, wo er die Beschriftung hinsetzen soll, ist es (fast) egal, ob der Knoten als label oder als place firmiert.

Der place-node kann auch hilfreich sein, wenn man z.B. nur das Stadtzentrum geladen hat und die Grenzen weit draußen liegen. Dann ist wenigstens der place-node bei den geladenen Daten dabei.

seichter wrote:

Wenn ich mir aber ansehe, welche Einträge dort stellenweise vorhanden sind, von denen ich nicht weiß, ob sie überhaupt irgendeine Bedeutung haben (GEO-Server-Importe) oder vielleicht doch (TMC), ist es mir fast lieber, sie bleiben dort, als dass ich mit Gedanken machen muss, ob sie in die Grenzrelation verschoben werden sollten.

Bei den GEO-Server-Tags waren wir uns einig, daß die raus können. Also im Place-Node löschen, wenn der mal wieder angefaßt wird, aber auf keinem Fall in die Relation übernehmen.
TMC macht wohl noch - für einige Jahre? - Sinn.

ym2c
Walter

wambacher wrote:

seichter wrote:

Wenn ich mir aber ansehe, welche Einträge dort stellenweise vorhanden sind, von denen ich nicht weiß, ob sie überhaupt irgendeine Bedeutung haben (GEO-Server-Importe) oder vielleicht doch (TMC), ist es mir fast lieber, sie bleiben dort, als dass ich mit Gedanken machen muss, ob sie in die Grenzrelation verschoben werden sollten.

Bei den GEO-Server-Tags waren wir uns einig, daß die raus können. Also im Place-Node löschen, wenn der mal wieder angefaßt wird, aber auf keinem Fall in die Relation übernehmen.

Was ist mit der "openGeoDB:loc_id"? Sollte die auch raus? Ich erinnere mich dunkel, dass es mal hieß, die Verknüpfung beider Quellen kann auch über AGS bzw. RS geschehen.
Das gölte aber nur für alles <=AL8.

wambacher wrote:

Ich stoße immer wieder auf Administrative Grenzen mit z.B. place=city als Tag. Muss das so sein? Sagt das Admin-Level das nicht aus?

Ich meine, dass das admin_level je nachdem eine andere Bedeutung haben kann, unter anderem weil es kreisfreie Städte gibt, die zwar eine place=city wären, aber vom admin_level her ein Landkreis. Zumindest habe ich das Wiki so verstanden. Von daher fände ich, dass ein place=city-Tag schon seine Daseinsberechtigung hat. Korrigiert mich, wenn ich das falsch verstanden habe.

Was TMC angeht: Inwiefern ist es sinnvoller, die Daten an eine Node zu kleben als an die Relation? Kann jemand etwas dazu sagen?

Nadjita wrote:

Was TMC angeht: Inwiefern ist es sinnvoller, die Daten an eine Node zu kleben als an die Relation? Kann jemand etwas dazu sagen?

Gar nicht, wenn es um eine TMC-Area geht. Viele AL8-Relationen haben auch eine TMC-Location-ID - für alle ist das eh nicht vergeben.

Gehrke wrote:

Was ist mit der "openGeoDB:loc_id"? Sollte die auch raus? Ich erinnere mich dunkel, dass es mal hieß, die Verknüpfung beider Quellen kann auch über AGS bzw. RS geschehen.
Das gölte aber nur für alles <=AL8.

Ich meine wirklich alle openGeoDB-Tags. Ich finde, daß AGS und RS durchaus reichen um an externe Daten ranzukommen.

Gruss
walter

Hurra! Gestern war seit langer Zeit mal wieder ein Tag, an dem keine Grenzpolygone zerschossen wurden. 😐 Mit Untrasried/Wildpoldsried hat das übrigens nichts zu tun.

Mein Hurra von gestern war (natürlich) voreilig. Gestern ging wieder einiges kaputt. Außerdem war auch vorgestern noch etwas im Argen:
Es gab bei Ludwigslust, Grabow (Meck-Pomm) eine selbstüberschneidende Grenzlinie, an der sich mein PostGIS verschluckt hat.

so, ich hab mal die Unstimmigkeiten zwischen OSM und DESTATIS 31.12.2013 herausgekitzelt. Die werde ich ab morgen wohl Zeile für Zeile durchgehen müssen.

So nebenbei: die AGS fast aller Gemeindefreier Gebiete (nicht in dieser Liste enthalten) scheinen sich auch geändert zu haben; zumindest gibt es extrem wenige Treffer wo beide AGS gleich sind. Die enden übrigens alle mit 444 - scheint neu zu sein? Aber das ist eine andere Task.

osm_id␣␣|␣␣␣␣␣␣␣␣name:prefix␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣osm.name␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣destatis.name␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣osm.ags␣␣|␣destatis.ags
---------+---------------------------+-------------------------------------------+----------------------------------------------------+----------+--------------

1161863␣|␣Gemeinde␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Hagen␣im␣Bremischen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣03352060␣|
2900086␣|␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Kaltennordheim␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣16063044␣|
3412601␣|␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Pockau-Lengefeld␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣14521495␣|
3411187␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Eschede␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣03351025␣|
3422046␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Gehlsbach␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣13076165␣|
1421453␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Goslar␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣03153017␣|
3422079␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Neetzow-Liepen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣13075155␣|
2602488␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Neuwirtshauser␣Forst␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣09672462␣|
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Bad␣Suderode␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣15085035
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Neetzow␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣13075096
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Hagen␣im␣Bremischen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03352019
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Küstengewässer␣einschl.␣Anteil␣am␣Festlandsockel␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣13000999
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Kaltennordheim,␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣16063102
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Driftsethe␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03352014
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Scharnhorst␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03351019
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Bartelshagen␣II␣b.␣Barth␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣13073008
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Höfer␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03351014
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Ketzerbachtal␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14627090
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Gernrode,␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣15085120
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Pockau␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14521490
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Liepen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣13075077
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Habighorst␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03351011
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Madlitz-Wilmersdorf␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣12067310
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Herzberg␣am␣Harz,␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03156009
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Sohland␣a.␣Rotstein␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14626540
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Lengefeld,␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14521360
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Gemeinsames␣deutsch-luxemburgisches␣Hoheitsgebiet␣␣|␣␣␣␣␣␣␣␣␣␣|␣07000999
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Karbow-Vietlübbe␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣13076066
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Mühlanger␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣15091230
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Vienenburg,␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03153013
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Schmiedeberg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14628350
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Wahlstorf␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣13076144
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Bramstedt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03352007
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Leuben-Schleinitz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14627120
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Wulsbüttel␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03352058
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Uthlede␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03352054
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Eschede␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03351009
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Goslar,␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03153005
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Sandstedt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03352049
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Süplingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣15083495
|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Erlbach␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14523110

Gruss
walter

wambacher wrote:

So nebenbei: die AGS fast aller Gemeindefreier Gebiete (nicht in dieser Liste enthalten) scheinen sich auch geändert zu haben; zumindest gibt es extrem wenige Treffer wo beide AGS gleich sind. Die enden übrigens alle mit 444 - scheint neu zu sein? Aber das ist eine andere Task.

Das ist kompliziert (Wer kann helfen/erklären?): Die Endung 444 für gem.fr. Gebiete ist nur eine statistische Endung (in Bayern?), die (glaube ich) alle gem.fr. Gebiete eines Kreises zusammenfasst. Der "echte" Schlüssel ist anders. Wo zu finden? Keine Ahnung.

wambacher wrote:

so, ich hab mal die Unstimmigkeiten zwischen OSM und DESTATIS 31.12.2013 herausgekitzelt. Die werde ich ab morgen wohl Zeile für Zeile durchgehen müssen

Ich kann nicht warten und fang schonmal an: Goslar, Hagen im Bremischen, Pockau-Lengefeld, Gehlsbach, Neetzow-Liepen, Eschede wurden am 1.1.2014 entweder neu gegründet oder es wurden unter bestehendem Namen Gemeinden fusioniert. Die Schlüssel in OSM sollten stimmen. Viele Einträge, die Du nur bei DESTATIS 2013 findest, sollten sich auch dadurch erklären.

Kaltennordheim bekam am 31.12.2013 einen neuen AGS. Der war trotz eines Edits von mir irgendwie falsch und ist jetzt gefixt.

Neuwirtshauser Forst (Wikipedia) ist ein gem.fr. Gebiet in Bayern. Ist bei DESTATIS wohl nicht separat aufgeführt.

Eigentlich sollte es in OSM noch "Einsiedler und Walderbacher Forst" geben, obwohl das 2013 auf die Nachbargemeinden aufgeteilt wurde. Wir haben aber keine Idee, wie die neuen Grenzen verlaufen.

Gehrke wrote:

Ich kann nicht warten und fang schonmal an: Goslar, Hagen im Bremischen, Pockau-Lengefeld, Gehlsbach, Neetzow-Liepen, Eschede wurden am 1.1.2014 entweder neu gegründet oder es wurden unter bestehendem Namen Gemeinden fusioniert. Die Schlüssel in OSM sollten stimmen. Viele Einträge, die Du nur bei DESTATIS 2013 findest, sollten sich auch dadurch erklären.

thx

Neuwirtshauser Forst (Wikipedia) ist ein gem.fr. Gebiet in Bayern. Ist bei DESTATIS wohl nicht separat aufgeführt.

war in osm noch nicht als name:prefix=Gemeindefreies Gebiet erfaßt, hab ich vorhin wohl übersehen als ich alle Gem.fr.Gebiete so getaggt habe, bei denen der Prefix fehlte.

Eigentlich sollte es in OSM noch "Einsiedler und Walderbacher Forst" geben, obwohl das 2013 auf die Nachbargemeinden aufgeteilt wurde. Wir haben aber keine Idee, wie die neuen Grenzen verlaufen.

gibt es immer noch: http://www.openstreetmap.org/btrowse/relation/2630453

Gruss
walter

Hi, hier mal meine erste Grafik zum Thema.

Meine Annahme: Die Flächen der Stadtstaaten, der kreisfreien Städte (AL6 ohne Kreise) und Städte/Gemeinden (AL8) müssen Deutschland komplett und ohne Überlappungen bedecken. Wenn da was "durchscheint", ist dort was faul.

Genau wie auf diesem Bild, wo jemand im Harz meint, daß Herzfeld Admin-Level 7 haben soll. Könnte ein kleiner Edit-War werden 😉

Gruß
walter

Moin,

wambacher wrote:

Genau wie auf diesem Bild, wo jemand im Harz meint, daß Herzfeld Admin-Level 7 haben soll. Könnte ein kleiner Edit-War werden 😉

kann ich mir gut vorstellen:

Herzberg ist eine "Einheitsgemeinde", also eine kreisangehörige Gemeinde, die nicht Mitglied in einer Verwaltungsgemeinschaft (für Bayern, Sachsen und Sachsen-Anhalt) oder Samtgemeinde (für Niedersachsen) ist. Sie erledigt alle kommunalen Aufgaben in eigener Zuständigkeit.

Das heißt, sie steht auf gleicher Ebene wie die Verwaltungsgemeinschaften bzw. Samtgemeinden.
Und die haben (entsprechend unseren Ämtern in SH und den amtsfreien Gemeinden) nunmal admin_level=7 ...

Gruß
Georg

GeorgFausB wrote:

Das heißt, sie steht auf gleicher Ebene wie die Verwaltungsgemeinschaften bzw. Samtgemeinden.
Und die haben (entsprechend unseren Ämtern in SH und den amtsfreien Gemeinden) nunmal admin_level=7 ...

AL7 ist eher eine optionale "Zwischenebene". Gemeinden haben immer AL8 (oder AL6, Hamburg und Berlin AL4).
Amtsfreie Gemeinden haben doch auch AL8. Wo ist das anders?

Moin,

Gehrke wrote:

GeorgFausB wrote:

Das heißt, sie steht auf gleicher Ebene wie die Verwaltungsgemeinschaften bzw. Samtgemeinden.
Und die haben (entsprechend unseren Ämtern in SH und den amtsfreien Gemeinden) nunmal admin_level=7 ...

AL7 ist eher eine optionale "Zwischenebene". Gemeinden haben immer AL8 (oder AL6, Hamburg und Berlin AL4).
Amtsfreie Gemeinden haben doch auch AL8. Wo ist das anders?

z.B. im Wiki beschrieben.

Und so habe ich die amtsfreien Gemeinden im Juli 2011 auch eingestuft - bis sie dann im Juli 2012 wieder von ludwich herabgestuft wurden ... wie ich jetzt erst bemerke.

Gruß
Georg

GeorgFausB wrote:

Gehrke wrote:

AL7 ist eher eine optionale "Zwischenebene". Gemeinden haben immer AL8 (oder AL6, Hamburg und Berlin AL4).
Amtsfreie Gemeinden haben doch auch AL8. Wo ist das anders?

z.B. im Wiki beschrieben.

Das finde ich ja überhaupt nicht gut. Das war nicht immer so und entspricht auch gar nicht dem Status in OSM.
Es ergibt auch keinen Sinn. In Nds. ist eine Samtgemeinde z.B. überhaupt nicht mit einer selbstständigen Gemeinde zu vergleichen.

AL8 normale Gemeinde, AL6 kreisfreie Gemeinde, AL6 Stadtstaat. Ganz einfach.
Gemeinden teils in AL7 zu schieben, macht die schöne Ordnung völlig kaputt.

EDIT: Habe mir nochmal die Wiki-History angeschaut. Das scheint schon recht lange so (unschön) zu sein. Bezeichnend, dass es nicht so angewendet wird.
Es gibt in DE keine einzige Gemeinde mit AL7!

Gehrke wrote:

Es gibt in DE keine einzige Gemeinde mit AL7!

Aber AL7-Boundaries schon: Das sind doch die Verwaltungsgemeinschaften, oder? Bestehen die aber immer aus mehreren AL8-Gemeinden? Dann würde mein Weltbild (keine Reklame!) wieder stimmen.

Gruss
walter

wambacher wrote:

Gehrke wrote:

Es gibt in DE keine einzige Gemeinde mit AL7!

Aber AL7-Boundaries schon: Das sind doch die Verwaltungsgemeinschaften, oder? Bestehen die aber immer aus mehreren AL8-Gemeinden? Dann würde mein Weltbild (keine Reklame!) wieder stimmen.

Ja und das ist auch mein Weltbild, das durch eine vollständige Betrachtung ganz OSM-Deutschlands gefestigt ist. 🙂

Aber wer hat das anders ins Wiki geschrieben und legt darauf wert? Kann man das Wiki nicht der OSM-Realität anpassen?

Moin,

Gehrke wrote:

Das finde ich ja überhaupt nicht gut. Das war nicht immer so und entspricht auch gar nicht dem Status in OSM.
Es ergibt auch keinen Sinn. In Nds. ist eine Samtgemeinde z.B. überhaupt nicht mit einer selbstständigen Gemeinde zu vergleichen.

AL8 normale Gemeinde, AL6 kreisfreie Gemeinde, AL6 Stadtstaat. Ganz einfach.
Gemeinden teils in AL7 zu schieben, macht die schöne Ordnung völlig kaputt.

EDIT: Habe mir nochmal die Wiki-History angeschaut. Das scheint schon recht lange so (unschön) zu sein.

Das war damals (Nov 2008) schlicht Stand der Dinge - das heißt ja nicht, das man/OSM sich nicht weiterentwickeln kann.

Gehrke wrote:

Bezeichnend, dass es nicht so angewendet wird.

nicht mehr

Gehrke wrote:

Es gibt in DE keine einzige Gemeinde mit AL7!

... mehr! 😉

Ich bin ja (heute) durchaus Deiner/Eurer Meinung, dass es sinnvoll ist, level 7 auf Verwaltungsgemeinschaften zu beschränken.
Wollte halt nur darauf hinweisen, dass das Wiki es seit über 5 Jahren anders beschreibt - und man sich dann nicht wundern muss.

Gruß
Georg

So, hab mal meine Hausaufgaben gemacht und den Vergleich DESTATIS 4/2013 mit OSM (Live) überprüft.

Eine einzige Differenz, die ich mir nicht erklären kann: Kaltennordheim

IN␣OSM␣aber␣nicht␣mit␣diesem␣AGS␣bei␣DESTATIS␣4/2013

1161863␣|␣␣␣␣␣␣␣␣|␣Hagen␣im␣Bremischen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣03352060␣|␣neue␣Nummer
2900086␣|␣␣␣␣␣␣␣␣|␣Kaltennordheim␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣16063044␣|
3412601␣|␣␣␣␣␣␣␣␣|␣Pockau-Lengefeld␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣14521495␣|␣NEU
3411187␣|␣␣␣␣␣␣␣␣|␣Eschede␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣03351025␣|␣neue␣Nummer
3422046␣|␣␣␣␣␣␣␣␣|␣Gehlsbach␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣13076165␣|␣NEU
1421453␣|␣␣␣␣␣␣␣␣|␣Goslar␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣03153017␣|␣neue␣Nummer
3422079␣|␣␣␣␣␣␣␣␣|␣Neetzow-Liepen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣13075155␣|␣NEU

In␣DESTATIS␣4/2013␣aber␣nicht␣mit␣diesem␣AGS␣in␣OSM

|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Kaltennordheim,␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣16063102
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Driftsethe␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03352014␣-->␣H␣i␣B
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Scharnhorst␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03351019␣-->␣Eschede
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Bartelshagen␣II␣b.␣Barth␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣13073008␣-->␣Sahl
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Höfer␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03351014␣-->␣Eschede
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Ketzerbachtal␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14627090␣-->␣Nossen
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Gernrode,␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣15085120␣-->␣Quedlinburg
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Pockau␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14521490␣-->␣Pockau-Lengenfeld
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Liepen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣13075077␣-->␣Neetzow-Liepen
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Habighorst␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03351011␣-->␣Eschede
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Madlitz-Wilmersdorf␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣12067310␣-->␣Briesen
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Sohland␣a.␣Rotstein␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14626540␣-->␣Reichenbach
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Lengefeld,␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14521360␣-->␣Pockau-Lengenfeld
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Karbow-Vietlübbe␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣13076066␣-->␣Gehlsbach
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Mühlanger␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣15091230␣-->␣Zahner-Elster
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Vienenburg,␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03153013␣-->␣Goslar
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Schmiedeberg␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14628350␣-->␣Dippoldswalde
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Bramstedt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03352007␣-->␣H␣i␣B
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Leuben-Schleinitz␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14627120␣-->␣Nossen
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Wulsbüttel␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03352058␣-->␣H␣i␣B
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Uthlede␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03352054␣-->␣H␣i␣B
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Eschede␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03351009␣neue␣Nummer
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Goslar,␣Stadt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03153005␣neue␣Nummer
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Sandstedt␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03352049␣-->␣H␣i␣B
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Süplingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣15083495␣-->␣Haldersleben
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Erlbach␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣14523110␣-->␣Markneukirchen
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Bad␣Suderode␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣15085035␣-->␣Quedlinburg
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Neetzow␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣13075096␣-->␣Neetzow-Liepen
|␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣Hagen␣im␣Bremischen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣␣␣␣␣␣␣␣␣␣|␣03352019␣neue␣Nummer

wer weiss näheres?

Gruss
walter

wambacher wrote:

So, hab mal meine Hausaufgaben gemacht und den Vergleich DESTATIS 4/2013 mit OSM (Live) überprüft.

Eine einzige Differenz, die ich mir nicht erklären kann: Kaltennordheim

Habe ich doch gestern gleich gefixt! Ist jetzt auf AGS 16063102. Oder was meinst Du?

Gehrke wrote:

Aber wer hat das anders ins Wiki geschrieben und legt darauf wert? Kann man das Wiki nicht der OSM-Realität anpassen?

Ich nehme an, es geht um die Spalte unter admin_level=7. wo bei einigen Bundesländern neben den Verbandsgemeinden o.ä. noch selbständige/verbandsfreie/freie Gemeinde steht.
Das gehört mMn nicht dahin.
In anderen Bundesländern gibt es das auch, ohne dass das einen speziellen Namen hat: Größere Gemeinden (etwa ab 20 - 30000 Einwohner) können einige Aufgaben der höheren Verwaltungsebene übernehmen. Das sind aber weiterhin Gemeinden mit AL8.

Im Sinne einer einheitlichen Handhabung in D sollte das überall so bleiben und das Wiki angepasst werden.

Anm.: Etwas anderes ist es bei den kreisfreien Städten/Stadtkreisen: Die übernehmen die Aufgaben eines Landkreises und sind AL6.

seichter wrote:

Im Sinne einer einheitlichen Handhabung in D sollte das überall so bleiben und das Wiki angepasst werden.

Hab das Wiki dieser Diskussion und dem Stand in OSM angepasst.

Gehrke wrote:

wambacher wrote:

So, hab mal meine Hausaufgaben gemacht und den Vergleich DESTATIS 4/2013 mit OSM (Live) überprüft.

Eine einzige Differenz, die ich mir nicht erklären kann: Kaltennordheim

Habe ich doch gestern gleich gefixt! Ist jetzt auf AGS 16063102. Oder was meinst Du?

alles klar, die Liste war eine Adelige: Liste von Gestern 😉

Gruss
walter

@Gehrke: schau dir die drei mal an, die passen zu meiner letzten mail. werden bestimmt noch mehr, da ich hier limit=3 angegeben habe.

osm_id␣␣|␣␣␣name␣␣␣␣|␣admin_level␣|␣␣␣landuse
---------+-----------+-------------+-------------
1345859␣|␣Geisa␣␣␣␣␣|␣11␣␣␣␣␣␣␣␣␣␣|␣residential
172478␣|␣Berwinkel␣|␣9␣␣␣␣␣␣␣␣␣␣␣|␣residential
172502␣|␣␣␣␣␣␣␣␣␣␣␣|␣9␣␣␣␣␣␣␣␣␣␣␣|␣residential

Gruss
walter

wambacher wrote:

@Gehrke: schau dir die drei mal an, die passen zu meiner letzten mail. werden bestimmt noch mehr, da ich hier limit=3 angegeben habe.

osm_id␣␣|␣␣␣name␣␣␣␣|␣admin_level␣|␣␣␣landuse
---------+-----------+-------------+-------------
1345859␣|␣Geisa␣␣␣␣␣|␣11␣␣␣␣␣␣␣␣␣␣|␣residential
172478␣|␣Berwinkel␣|␣9␣␣␣␣␣␣␣␣␣␣␣|␣residential
172502␣|␣␣␣␣␣␣␣␣␣␣␣|␣9␣␣␣␣␣␣␣␣␣␣␣|␣residential

Ja, übel. Dabei hätte man in Geisa sogar recht einfach eine Ortsteilgrenze machen können. Die Grenzsegmente sind ja schon da.

wambacher wrote:

Aber AL7-Boundaries schon: Das sind doch die Verwaltungsgemeinschaften, oder? Bestehen die aber immer aus mehreren AL8-Gemeinden?

Also bei uns im brandenburgischen ist Lübben z.B. eine Amtsfreie Gemeinde (AL 7) unterhalb dessen gibt es Ortsteile, (AL 9/10) wärenddessen gibt es angrenzend das Amt Lieberose/Oberspreewald (AL7) z.B. mit der Gemeinde Schwielochsee (AL8) und dem Gemeindeteil Byhleguhre-Byhlen (AL9) und dem Ortsteil Byhleguhre (AL10).

Meines Wissens nach ist die hierarchische Kette aktuell. Gemeindeteil Byhleguhre-Byhlen ist AL 9, hat einen Ortsvorsteher/ Bürgermeister...

Je nach Größe (Einwohnerzahl) gibt es ein Amt (eben eine Verwaltungsgemeinschaft), die untergeordneten Einheiten haben aber weiterhin eigene Gemeinderäte. Oder die Gemeinde ist so groß, daß ein Amt (Verwaltungsgemeinschaft) nicht nötig ist --> Amtsfrei.
Nächsthöhere Aggregation sind (noch) in Brandenburg eben die Kreisfreien Städte-

Sven

streckenkundler wrote:

wambacher wrote:

Aber AL7-Boundaries schon: Das sind doch die Verwaltungsgemeinschaften, oder? Bestehen die aber immer aus mehreren AL8-Gemeinden?

Also bei uns im brandenburgischen ist Lübben z.B. eine Amtsfreie Gemeinde (AL 7) unterhalb dessen gibt es Ortsteile, (AL 9/10) wärenddessen gibt es angrenzend das Amt Lieberose/Oberspreewald (AL7) z.B. mit der Gemeinde Schwielochsee (AL8) und dem Gemeindeteil Byhleguhre-Byhlen (AL9) und dem Ortsteil Byhleguhre (AL10).

Meines Wissens nach ist die hierarchische Kette aktuell. Gemeindeteil Byhleguhre-Byhlen ist AL 9, hat einen Ortsvorsteher/ Bürgermeister...

Je nach Größe (Einwohnerzahl) gibt es ein Amt (eben eine Verwaltungsgemeinschaft), die untergeordneten Einheiten haben aber weiterhin eigene Gemeinderäte. Oder die Gemeinde ist so groß, daß ein Amt (Verwaltungsgemeinschaft) nicht nötig ist --> Amtsfrei.
Nächsthöhere Aggregation sind (noch) in Brandenburg eben die Kreisfreien Städte-

Weshalb soll Lübben AL 7 sein?
Amtsfrei heißt doch nur, dass sie nicht einen Teil der Kommunalaufgaben mit anderen Gemeinden zusammen macht. Sie hat (Ober-)Bürgermeister, Gemeinderat und Finanzhoheit im Kommunalbereich wie andere AL8-Gemeinden auch.
In AL 9 wird das Geld von der Gemeinde (AL 8) bewilligt, in AL 7 arbeiten selbständige Gemeinden (AL 8) zusammen. In manchen Bundesländern ist diese Zusammenarbeit erzwungen (Amt), in anderen freiwillig (da spricht kein Mensch von verbundsfrei).
Ich plädiere dringend dafür, AL7 für Verbünde zu reservieren und nicht als AL8 de luxe zu verwenden.

seichter wrote:

Ich plädiere dringend dafür, AL7 für Verbünde zu reservieren und nicht als AL8 de luxe zu verwenden.

+1

Gruss
walter

Was wir hier so zum Besten geben, wird von der breiten Mapperschaft ja kaum zur Kenntnis genommen. Ich möchte daher darum bitten, auch zur Aktualisierung und Verbesserung der (vielen) einschlägigen Artikel des Wiki beizutragen. Das Thema admin_level hatten wir ja bereits.

Ich habe mich auch mal an einer Erweiterung des DE-Artikels zum Zeichnen von Grenzen versucht, den Ihr gerne weiter verbessern könnt:

https://wiki.openstreetmap.org/wiki/DE:Grenze_zeichnen

Das Ganze hat noch immer Baustellencharakter...

seichter wrote:

Weshalb soll Lübben AL 7 sein?

so hatte ich jedenfalls die Admin-Level-Pyramide interpretiert... Lübben hat jedenfalls eine Gemeindeschlüsselnummer (12061316) und eine Amtschlüsselnummer (12061000).

Meiner Ansicht nach müsste in dem Fall Lübben in einer Auswertung der AL-Ebene 7 erscheinen, als auch in der Ebene AL 8. Ich schaue morgen auf Arbeit noch mal nach... da hab ich detailliertere Dateien.
oder wie jetzt?

Sven

streckenkundler wrote:

Meiner Ansicht nach müsste in dem Fall Lübben in einer Auswertung der AL-Ebene 7 erscheinen, als auch in der Ebene AL 8. Ich schaue morgen auf Arbeit noch mal nach... da hab ich detailliertere Dateien.

Alle ungeraden AL sind optionale Zwischenbenen.

Mal ein Gedankenexperiment zu Verdeutlichung: Wenn Du Recht hättest, müssten doch auch alle Kreise ohne Regierungsbezirk auf AL5 gezogen werden, damit die in einer Auswertung der Ebene AL5 auch auftauchen.

Ich sage hingegen, eine Auswertung allein auf ungeraden Ebenen ist normalerweise gar nicht sinnvoll. Sollte das z.B. in Schleswig-Holstein oder Brandenburg wider Erwarten doch sinnvoll sein, muss man sich dort etwas anderes überlegen, das die Bundessystematik nicht über den Haufen wirft. Man könnte die AL8-Gemeinden eines Amtes z.B. spatial oder über den Regionalschlüssel ("5" an sechster Stelle) herausfiltern.

Was ist eigentlich ein Amtsschlüssel? Ist das der Regionalschlüssel eines Gem.verbandes (9 Stellen statt 12)? Der wäre für Lübben (das ja kein Verband ist) garantiert nicht 12061000 (hätten dann ja alle im Kreis Dahme-Spreewald), sondern wäre eher 120610316 der Regionalschlüssel der Gemeinde hingegen 120610316316.

Gehrke wrote:

Ja, übel. Dabei hätte man in Geisa sogar recht einfach eine Ortsteilgrenze machen können. Die Grenzsegmente sind ja schon da.

Sind doch nur 9, die teilweise auch noch durch den OSMF Redaction Bot "verstümmelt" wurden.

osm_id␣␣|␣␣␣name␣␣␣␣|␣admin_level␣|␣␣␣landuse
---------+-----------+-------------+-------------
1345859␣|␣Geisa␣␣␣␣␣|␣11␣␣␣␣␣␣␣␣␣␣|␣residential
172478␣|␣Berwinkel␣|␣9␣␣␣␣␣␣␣␣␣␣␣|␣residential
172502␣|␣␣␣␣␣␣␣␣␣␣␣|␣9␣␣␣␣␣␣␣␣␣␣␣|␣residential
172482␣|␣␣␣␣␣␣␣␣␣␣␣|␣9␣␣␣␣␣␣␣␣␣␣␣|␣residential
161731␣|␣␣␣␣␣␣␣␣␣␣␣|␣11␣␣␣␣␣␣␣␣␣␣|␣meadow
172483␣|␣␣␣␣␣␣␣␣␣␣␣|␣9␣␣␣␣␣␣␣␣␣␣␣|␣residential
172510␣|␣␣␣␣␣␣␣␣␣␣␣|␣9␣␣␣␣␣␣␣␣␣␣␣|␣residential
1338720␣|␣Geismar␣␣␣|␣11␣␣␣␣␣␣␣␣␣␣|␣residential
172503␣|␣␣␣␣␣␣␣␣␣␣␣|␣9␣␣␣␣␣␣␣␣␣␣␣|␣residential
(9␣rows)

Inzwischen ist ein Mapper an mich herangetreten, dazu einen eigenen Thread aufzumachen, da es sMn einiges zu klären gibt. Derzeit kitzel ich noch die "Admin-Grenzen" raus, die nicht als Relation sondern als normales Residential erfaßt sind. Danach gehts woanders weiter.

Gruss
walter

Hm... Da sind doch erst mal Unterschiede: entweder hat ein Bundesland eine dritte administrative Ebene (Regierungsbezirke) wie Sachsen, oder nicht. In Sachsen müsste es AL4 (Land), AL5, Regierungsbezirk), AL6 (Landkreis) geben. Brandenburg hat keine Regierungsbezirke, also fällt hier AL5 flach.

Hingegen: hat Brandenburg AL4 (Land), AL6 (Kreis). Zur Ebene AL6 gehören auch die Kreisfreien Städte. In Brandenburg ist es aber unterhalb von AL6 nicht einheitlich: entweder gibt es Ämter: AL7 mit Gemeinden: AL8 und Ortsteile: AL9. Oder es gibt Amtsfreie Gemeinden. AL7 mit Ortsteilen: AL9.

Die Ebenen AL5 und AL7 sind schon Zwischenebenen.

Gehrke wrote:

Wenn Du Recht hättest, müssten doch auch alle Kreise ohne Regierungsbezirk auf AL5 gezogen werden, damit die in einer Auswertung der Ebene AL5 auch auftauchen.

Nein, die AL 5 Grenzen tauchen nur da auf, wo es AL5 gibt. Bei Abfrage von AL 4: alle Bundesländer und Stadtstaaten. Bei Abfrage von AL6 alle Kreise und kreisfreien Städte. Bei Abfrage von AL7: alles Ämter(Verwaltungsgemeinschaften) und amtsfreien Gemeinden
Bei AL 8: nur noch die amtangehörigen Gemeinden.

Gehrke wrote:

Ich sage hingegen, eine Auswertung allein auf ungeraden Ebenen ist normalerweise gar nicht sinnvoll.

AL 5 jann ich dahingehend nicht beurteilen. AL7 jedoch ist durchaus wichtig. Ich habe z.B. dienstlich viel Flurstücken und Kostenbescheiden (z.B. Grundsteuer) zu tun. Diese kommen von den Amtern (wenn es Ämter gibt). Ein Wissen, zu welcher Gemeine und zu welchem Amt ein Flurstück gehört ist da unerläßlich.

Sven.

PS: verdammte Kleinstaaterei... 🙂

streckenkundler wrote:

Hm... Da sind doch erst mal Unterschiede: entweder hat ein Bundesland eine dritte administrative Ebene (Regierungsbezirke) wie Sachsen, oder nicht.

Betrachtet man nur jeweils ein Bundesland, hast Du recht. Ich hatte da eher die "Bundesbrille" auf.

streckenkundler wrote:

Gehrke wrote:

Ich sage hingegen, eine Auswertung allein auf ungeraden Ebenen ist normalerweise gar nicht sinnvoll.

AL 5 kann ich dahingehend nicht beurteilen. AL7 jedoch ist durchaus wichtig. Ich habe z.B. dienstlich viel Flurstücken und Kostenbescheiden (z.B. Grundsteuer) zu tun. Diese kommen von den Amtern (wenn es Ämter gibt). Ein Wissen, zu welcher Gemeinde und zu welchem Amt ein Flurstück gehört ist da unerläßlich.

Ok. Aber die Information ist doch in OSM, auch wenn amtsfreie Gemeinden nicht in AL7 sind. Der Regionalschlüssel gibt das ja her.

Gehrke wrote:

Was ist eigentlich ein Amtsschlüssel? Ist das der Regionalschlüssel eines Gem.verbandes (9 Stellen statt 12)? Der wäre für Lübben (das ja kein Verband ist) garantiert nicht 12061000 (hätten dann ja alle im Kreis Dahme-Spreewald), sondern wäre eher 120610316 der Regionalschlüssel der Gemeinde hingegen 120610316316.

verdammt, in der Spalte geirrt...

Nochmal:

Gemeinde:␣␣12␣0␣61␣0316␣316
Amt:␣␣␣␣␣␣␣12␣0␣61␣0316␣000
Kreis:␣␣␣␣␣12␣0␣61␣000

Ich bin etwas durcheinander gekommen, weol im meinem Shape anscheinend verkürzte Zahlen stehen.

Sven

Ich hätte jetzt nach DESTATIS eher gesagt:

Gemeinde:␣␣12␣0␣61␣0316␣316
(Amt:␣␣␣␣␣␣␣12␣0␣61␣0316)
Kreis:␣␣␣␣␣12␣0␣61

Gehrke wrote:

Ich hätte jetzt nach DESTATIS eher gesagt:

Gemeinde:␣␣12␣0␣61␣0316␣316
(Amt:␣␣␣␣␣␣␣12␣0␣61␣0316)
Kreis:␣␣␣␣␣12␣0␣61

Ja,stimmt. DESTATIS zeigt meiner Ansicht deutlich, daß die Auswerteebene "Gemeindeverband" (=Amt; =AL7) stets belegt ist, es sei denn es ist eine kreisfreie Stadt.

Es gibt Gemeindeverbände mit nur einer Gemeine: in Brandenburg sind das die Amtsfreien Gemeinden und es gibt Gemeindeverbände mit mehreren Gemeinden.

Währenddessen ist AL5 = 0 keine Regierungsbezirke in Bundesland, oder AL5>0 --> Regierungsbezirke vorhanden.

Sven

streckenkundler wrote:

DESTATIS zeigt meiner Ansicht deutlich, daß die Auswerteebene "Gemeindeverband" (=Amt; =AL7) stets belegt ist, es sei denn es ist eine kreisfreie Stadt.

Es gibt Gemeindeverbände mit nur einer Gemeinde: in Brandenburg sind das die Amtsfreien Gemeinden und es gibt Gemeindeverbände mit mehreren Gemeinden.

Na ja, das würde ich nicht überinterpretieren. In Hessen z.B. gibt es überhaupt keine Ämter und Verw.gemeinschaften. Trotzdem sind da jeweils 2 Zeilen.
Entscheidend ist, ob an Stelle 6 eine "5" steht.

Bei kreisfreien Städten ist es übrigens genau so. Da sind es dann 3 Zeilen. Hamburg und Berlin haben 4 Zeilen.

Gehrke wrote:

Entscheidend ist, ob an Stelle 6 eine "5" steht.

Ah... Ok... Danke für die Erklärung.

seltsame Tabelle...

Ich sag ja, verdammte Kleinstaaterei...

Sven

Mit Friedberg in Hessen bekomme ich so meine Probleme.

Der AL8 heißt nur Friedberg, hat aber zusätzlich ein so mir unbekanntes name:suffix namens "(Hessen)".
Der Al9 heißt einfach Friedberg (Hessen).

Nominatim macht daraus jetzt folgendes:

"Dorheimer Straße, Fauerbach, Friedberg (Hessen), Friedberg, [...]"

1. ist Fauerbach völlig falsch (liegt auf der komplett anderen Seite) und ich weiß nicht wie der Nominatim darauf kommt den da reinzuschreiben.
2. haben wir jetzt zweimal Friedberg, nämlich zuerst als Friedberg (Hessen) und dann nochmal als nur Friedberg. Also scheint Nominatim das name:suffix nicht zu verstehen.
3. stehen auf der Karte drei Bezeichnungen: Friedberg (Hessen) (aus dem place-node), nur Friedberg und dann nochmal Friedberg (Hessen).

So, was machen wir daraus? Ist das name:suffix so üblich und passt es, oder sollte es raus?

Prince Kassad wrote:

Mit Friedberg in Hessen bekomme ich so meine Probleme.

Der AL8 heißt nur Friedberg, hat aber zusätzlich ein so mir unbekanntes name:suffix namens "(Hessen)".
Der Al9 heißt einfach Friedberg (Hessen).

Nominatim macht daraus jetzt folgendes: "Dorheimer Straße, Fauerbach, Friedberg (Hessen), Friedberg, [...]"

Mir scheint das OT, weil es Dir eigentlich um Nominatim geht.
Fauerbach liegt im Polygon für "Friedberg (Hessen)" (AL9). Ob das stimmt, kann ich nicht sagen.
Wäre das Ergebnis denn anders, wenn AL9 nur "Friedberg" hieße? Vermute, dass nicht.

Prince Kassad wrote:

Der AL8 heißt nur Friedberg, hat aber zusätzlich ein so mir unbekanntes name:suffix namens "(Hessen)". Der Al9 heißt einfach Friedberg (Hessen).

2. haben wir jetzt zweimal Friedberg, nämlich zuerst als Friedberg (Hessen) und dann nochmal als nur Friedberg.

Ich lese da die prinzipielle Frage "Was tun mit dem Hauptort bei AL>8?" heraus. Gibt es da etwas allgemein übliches?
Zum Nominatim-Ergebnis: Etwas deutlicher denkbar wäre z.B. "Ort, Verwaltungsverbund Ort, Landkreis Ort" wo das Mehrfachvorkommen korrekt wäre.
Wie ist es bei Stadtteilen (also in offiziellen Daten): Gibt es da einen Stadtteil "Ort", der in der Stadt "Ort" liegt? Oder ist das ein "Stadtteil", in dem es einfach keinen Stadtteil gibt (wie die fehlende Stadt in Berlin)? Oder hat der Stadtteil üblicherweise einen Namen wie "Innenstadt"? Nach Gefühl würde ich bei vielen Orten die zweite Option wählen, bei Grossstädten die dritte.

Prince Kassad wrote:

"Dorheimer Straße, Fauerbach, Friedberg (Hessen), Friedberg, [...]"
1. ist Fauerbach völlig falsch (liegt auf der komplett anderen Seite) und ich weiß nicht wie der Nominatim darauf kommt den da reinzuschreiben.

Da ich keine Grenze dazu sehe wohl vom Place-Node. Und da die "Dorheimer Straße" direkt neben dem Place-Node liegt: Wirklich "komplett auf der anderen Seite"?

Prince Kassad wrote:

3. stehen auf der Karte drei Bezeichnungen: Friedberg (Hessen) (aus dem place-node), nur Friedberg und dann nochmal Friedberg (Hessen).

Das ist einmal die Place-Node-Diskussion, die wir ja schon ein paar Mal hatten, und die Frage in Punkt 2.

Prince Kassad wrote:

Ist das name:suffix so üblich und passt es, oder sollte es raus?

Ich würde hoffen, dass man es als üblich bezeichnen kann, da es mir relativ sinnvoll erscheint und ein logisches Gegenstück zu "name:prefix"=* ist.

rayquaza wrote:

Ich lese da die prinzipielle Frage "Was tun mit dem Hauptort bei AL>8?" heraus. Gibt es da etwas allgemein übliches?
Zum Nominatim-Ergebnis: Etwas deutlicher denkbar wäre z.B. "Ort, Verwaltungsverbund Ort, Landkreis Ort" wo das Mehrfachvorkommen korrekt wäre.
Wie ist es bei Stadtteilen (also in offiziellen Daten): Gibt es da einen Stadtteil "Ort", der in der Stadt "Ort" liegt? Oder ist das ein "Stadtteil", in dem es einfach keinen Stadtteil gibt (wie die fehlende Stadt in Berlin)? Oder hat der Stadtteil üblicherweise einen Namen wie "Innenstadt"? Nach Gefühl würde ich bei vielen Orten die zweite Option wählen, bei Grossstädten die dritte.

Es zwingt einen ja auch keiner den Kernort als Relation separat zu erfassen. Wenn die umliegenden OT eine Relation bekommen, verbleibt der Kernort als nicht weiter unterhalb zugewiesene Fläche der Gemeinde-Relation.

Schau dir hier mal die Situation an. Da kannst du ganz genau die Administrativen Grenzen UND die Place-Nodes sehen.

Und wenn du oben rechts mal "Friedberg" eingibst, kannst du sehen, was Nominatim ausgibt, wenn er "vernünftig" gefragt wird.

Gruss
walter

ps: Und ich muß jetzt klären, wieso in meiner Boundaries-Karte
bei Deutschland (2)/Hessen (4)/Regierungsbezirk Darmstadt (5)/Wetteraukeis (6)/Friedberg (8) nur Ockstadt(9) steht und die anderen Stadtteile fehlen. 🙁

Oder hat die gerade jemand frisch eingegeben?

Jo, dann werde ich wohl mal den Tree updaten lassen.

EDIT: Done, jetzt ist die Ecke sauber. 68 neue Boundaries dazu gekommen - da war wohl jemand fleissig. Der Tree wird ab jetzt jede Nacht neu aufgebaut, damit das nicht nochmals passiert.

Um mögliche Korrekturbedarfe der Grenzen zu erkennen, habe ich mal die Fläche der Gemeinden (im Moment nur für Schleswig-Holstein) laut OSM/PostGIS mit der laut DESTATIS verglichen.
Leider gibt es wegen ein paar Gebietsänderungen seit 2014 noch Abgleichsprobleme. Ich muss die im April mit dem neuen Gem.Verz.dann mal richtig machen.

Trotzdem lässt sich schon erkennen, dass es teils größere Abweichungen gibt. Meist scheinen diese durch Wasserflächen (drin oder nicht drin) verursacht zu werden.

Extrembeispiele für zu große OSM-Flächen (prozentual gesehen) sind Neufelderkoog mit 9,76 qkm (DESTATIS) bzw. 19,52 qkm (OSM/PostGIS); Tümlauer Koog mit 6,20 qkm (DESTATIS) und 8,80 qkm (OSM/PostGIS);
sowie Wittdün auf Amrum mit 2,60 qkm (DESTATIS) bzw. 8,69 qkm (OSM/PostGIS).

Helgoland hingegen ist erstaunlicherweise (die Grenze ist ja recht gut zu erkennen) laut DESTATIS in OSM viel zu klein: 4,20 (DESTATIS) vs. 1,78 qkm. Da ist bei DESTATIS dann wohl auch Wasserfläche dabei.

Moin,

Gehrke wrote:

Um mögliche Korrekturbedarfe der Grenzen zu erkennen, habe ich mal die Fläche der Gemeinden (im Moment nur für Schleswig-Holstein) [...]

Trotzdem lässt sich schon erkennen, dass es teils größere Abweichungen gibt. Meist scheinen diese durch Wasserflächen (drin oder nicht drin) verursacht zu werden.

Dieser Korrekturbedarf wird wohl so lange bestehen bleiben, bis eindeutige Erkenntnisse über die Zugehörigkeit von Wasserflächen vorliegen (ggf. durch amtlich freigegebene Grenzverläufe).
Die Grenzen habe ich (damals zwecks Navi-Suche) erstmal sehr grob eingetragen - insbesondere auf der Seeseite, auch um die coastline nicht dauernd anfassen zu müssen.
Aber um Wittdün auf ein Viertel einzudampfen müsste ja der ganze Strand entfallen ... der ja auch erst im Laufe der letzten 150 Jahre dazugekommen ist.

Bisher habe ich nur 2 Verweise zur Zugehörigkeit gefunden:
a) Ein Urteil in der Zeitschrift "Die Gemeinde 11/2007", wonach eine (leider nicht benannte) Marina zum (ebenfalls leider nicht benannten) Gemeindegebiet gehört. (1)
b) Aushang im Amt: Das Eigentum an einer benannten Marina wird gemäß Bundeswasserstraßengesetz auf den Bund übertragen.

Gruß
Georg

GeorgFausB wrote:

Dieser Korrekturbedarf wird wohl so lange bestehen bleiben, bis eindeutige Erkenntnisse über die Zugehörigkeit von Wasserflächen vorliegen (ggf. durch amtlich freigegebene Grenzverläufe).

Stimmt wohl. Ich habe einfach im Norden angefangen. Aber SH ist wohl ein schwieriger Fall. Werde die Auswertung nochmal in einem Bundesland starten, das nicht an der Küste liegt und in dem 2014 auch keine Gebietsänderungen waren.

EDIT: Baden-Württemberg müsste ja recht genau stimmen, oder?

So hier mal die schlimmsten Fälle für BaWü (Fläche in km²):

Gemeinde␣␣␣␣␣␣DEST.␣␣␣␣␣OSM␣␣␣␣␣Abw.

Heimsheim␣␣␣␣␣14,30	15,70	9,77%
Bühlertal␣␣␣␣␣17,68	16,37	7,42%
Neulußheim␣␣␣␣␣3,39	3,18	6,27%
Rutesheim␣␣␣␣␣16,22	15,21	6,22%
Neidenstein␣␣␣␣6,48	6,16	4,94%
Rainau␣␣␣␣␣␣␣␣25,44	26,61	4,58%
Ottersweier␣␣␣29,22	30,48	4,31%
Kürnbach␣␣␣␣␣␣12,67	13,06	3,08%
Lobbach	␣␣␣␣␣␣14,91	15,37	3,05%
Westhausen␣␣␣␣38,46	37,29	3,05%

Wie erwartet wesentlich besser als in SH. Dennoch ein paar Fragezeichen, insb. Heimsheim. Dort scheinen im Norden ein paar Grenzsegmente nicht von der LGL zu sein. Die Flächen der nördl. Nachbargemeinden passen aber fast exakt. Auffällig: Rutesheim im Osten von Heimsheim hat auch eine große Abweichung. Heimsheim ist in OSM zu groß (1,4 km²), Rutesheim zu klein (1,01 km²).

EDIT: Habs herausgefunden. Rutesheim besitz eine Exklave, die in OSM durch Heimsheim eingenommen wird.

Habe das mal grob gefixt. Ein Spezi da unten sollte sich das nochmal anschauen. Insbesondere frage ich mich, warum da kein LGL-Grenzen vorhanden sind.

Gehrke wrote:

EDIT: Habs herausgefunden. Rutesheim besitz eine Exklave, die in OSM durch Heimsheim eingenommen wird.
Habe das mal grob gefixt. Ein Spezi da unten sollte sich das nochmal anschauen. Insbesondere frage ich mich, warum da kein LGL-Grenzen vorhanden sind.

Ich habe mich vorwiegend um die Gemeindegrenzen in Württemberg gekümmert (vor allem die nicht oder nur grob vorhandenen). In Richtung Baden habe ich nur bei Gelegenheit korrigiert, wenn mir größere Abweichungen von LGL aufgefallen sind (ich habe die LGL-Karte z.B. jetzt bei den PLZ-Irrläufern immer als Hintergrund).
Es kann sich aber fast nur um Exklaven handeln, da keine eklatanten Abweichungen der Grenzverläufe mehr vorhanden sind.
Aber so eine Liste ist sehr hilfreich, Westhausen (Nähe Aalen) dürfte eigentlich nicht vorkommen. Ich sehe in nächster Zeit mal nach (ich habe die LGL-Grenzen auch als OSM-Datei).

Ich hätte eher erwartet, dass es am Bodensee Abweichungen gibt. Da gehen die Gemeindegebiete bis zum Ufer, der (deutsche) Seeteil gehört allein zum Land. In Bayern sind die Gemeindegrenzen bis Seemitte gezogen, was ich fraglich finde. Der Grenzverlauf zwischen den Staaten D,A,CH im Obersee ist abgesehen davon sogar bis heute völkerrechtlich unklar.

Gehrke wrote:

So hier mal die schlimmsten Fälle für BaWü (Fläche in km²):

Ist der Datenstand neuer als 2014-02-21? Neulussheim passt nämlich trotz der "alten" source-Tags recht gut zur LGL-Karte.

rayquaza wrote:

Gehrke wrote:

So hier mal die schlimmsten Fälle für BaWü (Fläche in km²):

Ist der Datenstand neuer als 2014-02-21? Neulussheim passt nämlich trotz der "alten" source-Tags recht gut zur LGL-Karte.

Datenstand 2014-02-25T21:55:01Z. Neulussheim ist aber natürlich auch sehr klein, die absolute Abweichung beträgt ja nur 0,21 km².

EDIT: Ich weiß auch nicht, ob die Berechnungsmethode der Behörden (?) bzw. von PostGIS (Kugel-Modell) zu Abweichungen führt.

seichter wrote:

Ich hätte eher erwartet, dass es am Bodensee Abweichungen gibt. Da gehen die Gemeindegebiete bis zum Ufer, der (deutsche) Seeteil gehört allein zum Land.

Ja, bei OSM und wohl auch bei DESTATIS.

Friedrichshafen: 69,93 km² bei DESTATIS und 69,87 km² bei OSM (Abweichung 0,08%)

Das würde doch Sinn machen so eine Liste bspw. im OSM-Wiki zu erstellen. Dann könnte man das systematisch abarbeiten. Und wenn das regelmäßig aktualisiert wird könnte man so ggf. auch auf die Zerstörung solcher Grenzen aufmerksam werden.

Westhausen und Rainau in BW sind geklärt:
Da war vermutlich die Grenz-Relation defekt. Bei der Reparatur im Okt. 2013 wurde dann aber die alte (obsolete) Grenze verwendet.
Habe die jetzt durch die LGL-Grenze ersetzt. Die Flächen müssten jetzt auf 0,00 km² genau stimmen.

Gehrke wrote:

Neidenstein 6,48 6,16 4,94%

Bei Neidenstein betrifft es sogar Gebäude. Hier gibt es eine Übersicht über andere ungenaue Grenzverläufe in dem Gebiet, die LGLifiziert werden könnten.

Hier nochmal die Top10-BaWü-Abweichler nach Fläche:

Gemeinde	DEST	OSM	Abw.	%

Heimsheim	14,30	15,70	1,40	9,77%
Bühlertal	17,68	16,37	1,31	7,42%
Ottersweier	29,22	30,48	1,26	4,31%
Westhausen	38,46	37,29	1,17	3,05%
Rainau		25,44	26,61	1,17	4,58%
Willstätt	55,28	54,14	1,14	2,07%
Rutesheim	16,22	15,21	1,01	6,22%
Kehl		75,07	75,84	0,77	1,02%
Sinsheim	127,01	126,40	0,61	0,48%
Sulzfeld	18,76	18,20	0,56	2,97%

Diese Woche kann ich eventuell noch ein paar mehr und aktuellere Werte ins Wiki stellen.

Nochmal ein Update der BaWü-Daten, sortiert nach Abweichung der Fläche in km² (Top 10):

Gemeinde	offiz.	OSM	Abw.	%
----------------------------------------------
Oberkirch	␣69,13	␣68,69	0,439	0,63%
Altlußheim	␣15,96	␣16,39	0,429	2,69%
Ubstadt-Weiher	␣36,50	␣36,89	0,390	1,07%
Renchen		␣32,08	␣32,47	0,388	1,21%
Achern		␣65,24	␣64,86	0,381	0,58%
Kraichtal	␣80,56	␣80,93	0,371	0,46%
Sasbach		␣16,74	␣17,09	0,350	2,09%
Bruchsal	␣93,01	␣92,67	0,345	0,37%
Schwäb.␣Hall	104,23	104,54	0,306	0,29%
Hambrücken	␣10,97	␣11,26	0,288	2,62%

Im Wesentlichen sieht das ganz gut aus.
Ich schaue mal, ob ich am Wochende etwas im Wiki dazu aufbauen.

EDIT: Oberkirch/Renchen sind korrigiert. Da war eine Exklave (37,248 ha) falsch zugewiesen. Außerdem habe ich die Grenzverläufe von Oberkirch im Detail verbessert.

EDIT: Ich sehe, Kollege seichter war (u.a.?) in Ubstadt-Weiher und Altlußheim aktiv und hat Grenzen "LGL-ifiziert".

EDIT: Habe einen Exklaven-Fehler zwischen Achern und Sasbach gefixt und Kraichtal "LGL-ifiziert".

Kann dieser kranke Grenzverlauf zwischen Landshut und Ergolding wirklich so stimmen? Mir scheint das sehr unwahrscheinlich. Die (Way-)History verrät es mir leider nicht.

Ist mir aufgefallen, weil nach einer Änderung der PLZ-Grenze gestern, da jetzt die Geometrie durch Überschneidung kaputt ist.

EDIT: Ist behoben.

Gehrke wrote:

Die History verrät es mir leider nicht.

https://www.openstreetmap.org/node/2054114551/history
Kann passieren, da bei OSM alles mit allem verklebt ist. 😉

Danke für's aufräumen.

Baßtölpel

Die 10. größten Abweichungen nach Gemeindefläche (DESTATIS vs. OSM) für Rheinland-Pfalz:

Gemeinde	␣offiz.	␣OSM	␣␣Abw.	␣rel.

Baumholder	␣␣69,47	132,163	␣62,693	␣90,25%
Idar-Oberstein	␣␣91,54	␣66,650	␣24,889	␣27,19%
Homberg		␣␣10,89	␣␣4,105	␣␣6,784	␣62,30%
Niederalben	␣␣␣8,81	␣␣2,794	␣␣6,015	␣68,28%
Sinzig		␣␣41,02	␣46,651	␣␣5,631	␣13,73%
Wörth␣am␣Rhein	␣131,64	126,050	␣␣5,590	␣␣4,25%
Hagenbach	␣␣15,86	␣21,003	␣␣5,144	␣32,43%
Bingen␣am␣Rhein	␣␣37,73	␣42,622	␣␣4,893	␣12,97%
Saarburg	␣␣20,53	␣25,300	␣␣4,771	␣23,24%
Oberreidenbach	␣␣10,93	␣␣6,574	␣␣4,356	␣39,85%

Uiuiui... Kann sich jemand die Abweichung bei Baumholder erklären. So falsch sieht es gar nicht aus.

Übrigens DESTATIS weist ein "Gemeinsames deutsch-luxemburgisches Hoheitsgebiet" mit 6,20 km² aus. Das ist das Wasser zwischen Luxemburg und Deutschland. OSM kennt das nicht.

EDIT: Habe doch ein paar Unstimmigkeiten zwischen Idar-Oberstein und Baumholder gefunden und korrigiert. Baumholder ist schonmal bestimmt 20% kleiner. Aber der Osten ist noch zu beschneiden.

EDIT: Die Daten bei Wikipedia scheinen grob falsch zu sein, selbst die Kreisgrenze. Ich vermute das hat etwas mit den US-Militätgeländen dort zu tun.

Hei,

Ich habe hierdiverse AL10 eingepflegt, nachdem ich eine amtliche Veröffentlichung des LDS-Kreises zur Statistik mit einer Grenzkarte (wenn auch grob) gefunden hatte. Hoffentlich sind alle von mir erfassten Grenzen sauber, denn ich habe festgestellt, daß JOSM (Version 6891) nicht immer sauber Linienelemente nach dem Trennen den Relationen zugeordnet hat.

Ich hoffe mal, die Grenzen sind valid... teilweise werde ich eventuell die erfassten AL10-Grenten wieder auf AL 9 setzen, da teilweise Ortsbürgermeister und Beirat/ Beiräte vorhanden sind.., wenn, dann kommt das später.

Sven

streckenkundler wrote:

Hoffentlich sind alle von mir erfassten Grenzen sauber, denn ich habe festgestellt, daß JOSM (Version 6891) nicht immer sauber Linienelemente nach dem Trennen den Relationen zugeordnet hat.

In JOSM kann das Auftrennen von Grenzsegmenten ja nur funktionieren, wenn alle Relationen des betreffenden Segments auch geladen sind. Das war bei Dir wahrscheinlich für die PLZ-Relationen nicht der Fall. Ich lade immer die Daten des Segments, indem ich einen kleinen Bereich lade, der einen Knoten des Segments enthält, am besten einer Gabelung.

Ich hatte aber das Gefühl, dass JOSM nicht in 100% der Auftrenn-Fälle die Sequenzreihenfolge beibehält, sondern die zwei Teile vertauscht.

Gehrke wrote:

Ich hatte aber das Gefühl, dass JOSM nicht in 100% der Auftrenn-Fälle die Sequenzreihenfolge beibehält, sondern die zwei Teile vertauscht.

Ich sortiere die Segment eh, bevor ich sie hochlade. Dann sehe ich gleich, ob noch was faul ist.

Gruss
walter

Gehrke wrote:

EDIT: Die Daten bei Wikipedia scheinen grob falsch zu sein, selbst die Kreisgrenze. Ich vermute das hat etwas mit den US-Militätgeländen dort zu tun.

Stammt die Kreisgrenze, die wir haben, nicht aus dem Kreisgrenzen-Import? Müsste die dann nicht stimmen?

Prince Kassad wrote:

Gehrke wrote:

EDIT: Die Daten bei Wikipedia scheinen grob falsch zu sein, selbst die Kreisgrenze. Ich vermute das hat etwas mit den US-Militätgeländen dort zu tun.

Stammt die Kreisgrenze, die wir haben, nicht aus dem Kreisgrenzen-Import? Müsste die dann nicht stimmen?

Tja, was ist, wenn die Quelle fehlerhaft oder veraltet (2005) ist... Der Grenze der Lks Kusel und Birkenfeld traue ich zumindest nicht.

Gehrke wrote:

Prince Kassad wrote:

Stammt die Kreisgrenze, die wir haben, nicht aus dem Kreisgrenzen-Import? Müsste die dann nicht stimmen?

Tja, was ist, wenn die Quelle fehlerhaft oder veraltet (2005) ist... Der Grenze der Lks Kusel und Birkenfeld traue ich zumindest nicht.

Die Grenzen zwischen Gemeinden (admin_level=8) sind zumindestens oft nur geschätzt. Die Grenze zwischen Königswinter und Bad Honnef lag zum Teil mehrere hundert Meter daneben. Die konnte ich mit dem Grenzlayer des NRW-Atlas korrigieren.

Wie es mit der Genauigkeit der Kreisgrenzen aus dem Import aussieht vermag ich nicht einzuschätzen. So große Abweichungen halte ich allerdings für unwahrscheinlich. Ausnahmen ergeben sich eigentlich nur durch Gebietsreformen, soweit sie nicht bei OSM eingetragen wurden. Inwieweit das auf die beiden benannten Kreise zutreffen mag, kann ich aus der Ferne nicht beurteilen.

Edbert (EvanE)

EvanE wrote:

Wie es mit der Genauigkeit der Kreisgrenzen aus dem Import aussieht vermag ich nicht einzuschätzen. So große Abweichungen halte ich allerdings für unwahrscheinlich. Ausnahmen ergeben sich eigentlich nur durch Gebietsreformen, soweit sie nicht bei OSM eingetragen wurden. Inwieweit das auf die beiden benannten Kreise zutreffen mag, kann ich aus der Ferne nicht beurteilen.

Ich traue den offiziellen Daten von DESTATIS und die passen dort schlicht nicht zum Kreis-Import.

Gehrke wrote:

Das war bei Dir wahrscheinlich für die PLZ-Relationen nicht der Fall.

Danke euch beiden. Ich vermute auch ganz stark, wo mein Fehler war.

Ich hatte mir die Grenzen im betreffenden Bereich mittels overpass-turbo geladen, und die Postleitzahlen vergessen. Obwohl... selbst repariert hatte ich schon admin-Grenzen, und da war ich eigentlich sicher, alle Relationen und Elemente geladen zu haben.

Mit

<osm-script␣output="xml"><!--␣fixed␣by␣auto␣repair␣-->
<query␣type="relation">
<has-kv␣k="boundary"␣regv="administrative|postal_code"/>
<bbox-query␣{{bbox}}/>
</query>
<print␣mode="meta"/>
<recurse␣type="down"/>
<print␣mode="meta"/>
</osm-script>

müsste ich jetzt eigentlich alle Elemente (Admin-und PLZ-Grenzen) in der BBox geladen haben.

Sven

@streckenkundler: Man weiß ja nie, was noch für eine Relation an dem Grenzsegment hängt. Habe da z.B. schon Naturschutzgebiete gesehen. Deshalb denke ich, das Herunterladen eines Ausschnitts ist die einzig sichere Methode.

Gehrke wrote:

Deshalb denke ich, das Herunterladen eines Ausschnitts ist die einzig sichere Methode.

Ich habe gerade verschiedene Dinge probiert. Ja, du hast recht... Die Wahlkreisgrenze war auch defekt...

Sven

Prince Kassad wrote:

Gehrke wrote:

EDIT: Die Daten bei Wikipedia scheinen grob falsch zu sein, selbst die Kreisgrenze. Ich vermute das hat etwas mit den US-Militätgeländen dort zu tun.

Stammt die Kreisgrenze, die wir haben, nicht aus dem Kreisgrenzen-Import? Müsste die dann nicht stimmen?

Wikipedia-Artikel zur Gemeinde Unterjeckenbach:

Durch das rheinland-pfälzische „Landesgesetz über die Auflösung des Gutsbezirks Baumholder und seine kommunale Neugliederung“ vom 2. Nov. 1993 (GVBl. S. 518) wurde die bis dahin zum Landkreis Birkenfeld gehörende Gemarkung der ehemaligen Nachbargemeinde Oberjeckenbach am 1. Januar 1994 in die Ortsgemeinde Unterjeckenbach umgegliedert.[2]

Oberjeckenbach ist bei OSM und Wikipedia auf dem Gemeindegebiet von Baumholder. Also sind die Gemeinde- und auch die Kreisgrenzen in OSM und Wikipedia immer falsch gewesen! Der Import von 2005 hatte offenbar auch Daten benutzt, die schon damals über 10 Jahre nicht mehr aktuell waren!

Habe in der Ecke Baumholder jetzt mal ein paar Aufräumversuche unternommen. Mal schauen, wie die DESTATIS-Flächendifferenzen dort jetzt sind...

Gehrke wrote:

Ich hatte aber das Gefühl, dass JOSM nicht in 100% der Auftrenn-Fälle die Sequenzreihenfolge beibehält, sondern die zwei Teile vertauscht.

Tipp: Way und seine beiden Endnodes(!) selektieren, [Strg]+[Alt]+[D] drücken (=Elternelemente laden), beruhigt* aufteilen 😉
Besonders wichtig ist das bei Relationen, bei denen die Reihenfolge wirklich wichtig ist, und davon gibt es ja inzwischen einige.

• Eine␣Ausnahme:␣Wenn␣der␣Way␣mit␣keinem␣seiner␣Vorgänger␣oder␣Nachfolger␣in␣der␣Relation␣verbunden␣ist.␣Dann␣ist␣eine␣solche␣Relation␣aber␣normalerweise␣eh␣schon␣durcheinander.␣Ausserdem␣natürlich␣wenn␣JOSM␣versagt.
  

Ich habe im OSM-Wiki jetzt mal begonnen, Flächenabweichungen aufzulisten: https://wiki.openstreetmap.org/wiki/DE: … u_DESTATIS

Angefangen mit den aktuellen Top 5 für Rheinland-Pfalz und Baden-Württemberg. Dazu noch Bremen komplett.

Jetzt gibt es die Top-5-Flächenabweichungen auch für Niedersachsen:

https://wiki.openstreetmap.org/wiki/DE: … dersachsen

Gehrke wrote:

Ich habe im OSM-Wiki jetzt mal begonnen, Flächenabweichungen aufzulisten: https://wiki.openstreetmap.org/wiki/DE: … u_DESTATIS
Angefangen mit den aktuellen Top 5 für Rheinland-Pfalz und Baden-Württemberg. Dazu noch Bremen komplett.

Die Listen sind ganz nett, aber leider ziemlich kurz. Bei BW sind die ersten vier Kandidaten zwei Paare, die aneinandergrenzen und bei denen die Differenz ziemlich gleich ist. Ich habe aber an der Grenzlinie nichts Auffälliges feststellen können und Exklaven gibt es nach LGL-BW auch nicht.
Beim fünften Eintrag konnte ich eine Exklave nachtragen und das wars dann.
Machbar wären mehr Einträge aber wohl nur per Aufklappen oder Link (siehe wambacher) und wenn sie wenigstens halbautomatisch erstellt werden können.

seichter wrote:

Gehrke wrote:

Ich habe im OSM-Wiki jetzt mal begonnen, Flächenabweichungen aufzulisten: https://wiki.openstreetmap.org/wiki/DE: … u_DESTATIS
Angefangen mit den aktuellen Top 5 für Rheinland-Pfalz und Baden-Württemberg. Dazu noch Bremen komplett.

Die Listen sind ganz nett, aber leider ziemlich kurz. Bei BW sind die ersten vier Kandidaten zwei Paare, die aneinandergrenzen und bei denen die Differenz ziemlich gleich ist. Ich habe aber an der Grenzlinie nichts Auffälliges feststellen können und Exklaven gibt es nach LGL-BW auch nicht.
Beim fünften Eintrag konnte ich eine Exklave nachtragen und das wars dann.
Machbar wären mehr Einträge aber wohl nur per Aufklappen oder Link (siehe wambacher) und wenn sie wenigstens halbautomatisch erstellt werden können.

Richtig. Da bin ich dran, aber nur so nebenbei. Ich denke, ich werde eine generierte Textdatei auf meiner eigenen Website verlinken, die dann alle Daten enthält.

Die Fälle in BW habe ich mir auch ohne Erfolg angesehen. Aber generell sind die Abweichungen in BW ja auch recht gering.

Gestern sind in Duisburg recht viele Grenzen (Ortsteile und PLZ) beschädigt worden. Ich habe es eben korrigiert.

Bin gerade auf Bielefeld gestoßen. Das ist sehr aufwendig mit ca. 100 admin-Relationen erfasst. Leider auch mit subareas. Sollten die in DE nicht weg? Walter?

Gehrke wrote:

Bin gerade auf Bielefeld gestoßen. Das ist sehr aufwendig mit ca. 100 admin-Relationen erfasst. Leider auch mit subareas. Sollten die in DE nicht weg? Walter?

Bielefeld? Gibts doch garnicht 😉

Jo, Subareas sollen weg. Ich muß noch mal an meiner Query feilen, die die eigentlich entdecken soll.

Da hat sich jemand aber sehr viel Arbeit gemacht. Allerdings auch einen kleinen Fehler:
Quelle(10) #1014628 enthält nur 1x AL11 (Kupferheide #2370432). Das sollten mindestens 2 Teile sein.

EDIT: Fixed

Gruss
walter

Bittschön: Alle Subareas im RB Detmold.

␣␣id␣␣␣␣|␣␣␣␣␣␣␣␣␣␣name␣␣␣␣␣␣␣␣␣␣␣|␣admin_level
---------+-------------------------+-------------
62646␣|␣Bielefeld␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣6
1014629␣|␣Brackwede␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10
1001322␣|␣Brake␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10
2226718␣|␣Eckardtsheim␣␣␣␣␣␣␣␣␣␣␣␣|␣10
1014604␣|␣Gadderbaum␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10
1014620␣|␣Großdornberg␣␣␣␣␣␣␣␣␣␣␣␣|␣10
1001320␣|␣Heepen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10
953535␣|␣Jöllenbeck␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10
1001325␣|␣Oldentrup␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10
1014628␣|␣Quelle␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10
976442␣|␣Stadtbezirk␣Brackwede␣␣␣|␣9
976440␣|␣Stadtbezirk␣Dornberg␣␣␣␣|␣9
976439␣|␣Stadtbezirk␣Gadderbaum␣␣|␣9
975261␣|␣Stadtbezirk␣Heepen␣␣␣␣␣␣|␣9
974940␣|␣Stadtbezirk␣Jöllenbeck␣␣|␣9
976404␣|␣Stadtbezirk␣Mitte␣␣␣␣␣␣␣|␣9
976422␣|␣Stadtbezirk␣Schildesche␣|␣9
976441␣|␣Stadtbezirk␣Senne␣␣␣␣␣␣␣|␣9
976380␣|␣Stadtbezirk␣Sennestadt␣␣|␣9
976364␣|␣Stadtbezirk␣Stieghorst␣␣|␣9
1014611␣|␣Stieghorst␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10
1014612␣|␣Ubbedissen␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10
1014627␣|␣Ummeln␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10
953520␣|␣Vilsendorf␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10
(24␣rows)

array_agg
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{62646,1014611,1014627,976440,2226718,953535,974940,1014629,1014604,1001322,1014612,976404,976380,1014628,1001325,975261,976442,976439,976364,1001320,953520,976422,976441,1014620}
(1␣row)

Nachher schmeiss ich mal Germany an. Die Kiste hat momentan viel zu tun, nachdem der Lag endlich abgebaut ist.

Gruss
walter

ps: diese subareas werfe ich natürlich gleich raus.

edit: Done

Wenn sich jemand eine (Extrakt-)Datenbank mit (geometrisch gesehen) sauberen admin- und PLZ-Grenzen für Deutschland aufsetzen möchte, so ist der gestrige Tag ein guter:
Alle Grenzen (bis auf ein paar unfertige AL9/10-Grenzen) sind in Ordnung. Welch seltener Anblick!

Gehrke wrote:

(bis auf ein paar unfertige AL9/10-Grenzen)

ja, hier sind z.B. zwei, die mich schon lange stören. Mal sehen ob ich Wochenende da was machen kann.

Sven

streckenkundler wrote:

hier sind z.B. zwei, die mich schon lange stören.

Genau die meine ich. Da müsste man aber wohl erstmal Grenzsegmente "erfinden".

Gehrke wrote:

Da müsste man aber wohl erstmal Grenzsegmente "erfinden".

Ich hab jetzt nicht die Ruhe... Wochenende schaue ich mal, ob ich was finde.

Sven

streckenkundler wrote:

Ich hab jetzt nicht die Ruhe... Wochenende schaue ich mal, ob ich was finde.

Muß du halt hinfahren und nach den violetten Streifen am Boden suchen 😉

duck&weg
walter

wambacher wrote:

Muß du halt hinfahren und nach den violetten Streifen am Boden suchen

Ich laufe die Grenzlinie nach der Karte ab. 😄

Sven

streckenkundler wrote:

wambacher wrote:

Muß du halt hinfahren und nach den violetten Streifen am Boden suchen

Ich laufe die Grenzlinie nach der Karte ab. 😄

Sven

Verdammt tun mir die Beine weh...

Ich geh ins Bett...

Sven

Gehrke wrote:

Wenn sich jemand eine (Extrakt-)Datenbank mit (geometrisch gesehen) sauberen admin- und PLZ-Grenzen für Deutschland aufsetzen möchte, so ist der gestrige Tag ein guter:
Alle Grenzen (bis auf ein paar unfertige AL9/10-Grenzen) sind in Ordnung. Welch seltener Anblick!

Und, wenn wunderts, schon ist der schöne Moment vorbeigezogen wie ein warmes Lüftchen im Frühling.
Östlich von Jena sind 3 mind. 12 Grenzen zerschossen worden... Dafür gibts dort jetzt Schienenkreuze.

EDIT: Habs repariert. Wie war das noch? Man soll sich Sisyphos als glücklichen Menschen vorstellen?

Mich würde es interessieren wie groß die Flächenabweichungen in Hessen sind. Wäre es möglich das zu generieren?

mich würde es auch freuen wenn diese sache: https://wiki.openstreetmap.org/wiki/DE: … u_DESTATIS von Gehrke so richtig ins rollen gebracht wird

Ok. Habe aber im Moment zu viel anderes zu tun. Vielleicht in 2-3 Wochen.

EDIT: Eigentlich lohnt es sich auch erst richtig, wenn das nrue GV Q1/2014 von DESTATIS da ist.

Prince Kassad wrote:

Mich würde es interessieren wie groß die Flächenabweichungen in Hessen sind. Wäre es möglich das zu generieren?

Insgesamt summieren sich alle Abweichungen in Hessen auf 250,679 km². Das ist recht viel und entspricht ungefähr der Fläche von Frankfurt am Main.

Erste Übersicht hier: https://wiki.openstreetmap.org/wiki/DE: … TIS#Hessen
Mehr geht aber wirklich erst später.

Am schlimmsten ist Hofbieber. Das liegt wohl auch daran das OT Kleinsassen in OSM fälschlich in Poppenhausen liegt.

Oje, da sieht es wirklich schlimm aus.

Ich kümmere mich mal um den Gutsbezirk Spessart. Da ist die Grenze noch äußerst ungenau und es fehlen etliche Exklaven.

Hallo,

ich vermisse gerade die ehemalige Gemeindegrenze von Hohenölsen, am 31.12.2013 in Weida eingemeindet.

Der Knoten #2168598181 gehört zu einigen ehemaligen Grenzabschnitten (vermutlich auch zu Hohenölsen), die auch nicht mehr zu einer Relation gehören.

Wäre es nicht sinnvoll, die ex. Gemeindegrenzen und jetzt sicherlich noch aktiven Ortsteilgrenzen als admin_level=10 zu behalten?

Ich könnte dann die Ortsteillisten in der Straßenlistenauswertung weiter führen. Die landesweite Straßenliste von Thüringen ist leider noch auf dem Stand 10/2013.

edit: auch fehlend: Steinsdorf Ortsteil-Grenze

viele Grüße

Dietmar

[edut] Steinsdorf-Ergänzung

okilimu wrote:

ich vermisse gerade die ehemalige Gemeindegrenze von Hohenölsen, am 31.12.2013 in Weida eingemeindet.

Wäre es nicht sinnvoll, die ex. Gemeindegrenzen und jetzt sicherlich noch aktiven Ortsteilgrenzen als admin_level=10 zu behalten?

Die Grenzsegmente scheinen doch noch da zu sein und das ist auch gut so.
Kannst ja die gelöschten Rels (2792739 und 2793038) wiederherstellen und umtaggen oder neu erzeugen.

die Goslar-Relation #1421453 hatte bis eben den Gemeindeschlüssel 03153017 und Regionalschlüssel 031530017017, ich habe die Zahlen korrigiert nach Destatis File vom 31.12.2013.

Müsste ein nicht mehr aktiver Gemeindeschlüssel in einer QS-Karte auffallen?

viele Grüße

Dietmar

okilimu wrote:

die Goslar-Relation #1421453 hatte bis eben den Gemeindeschlüssel 03153017 und Regionalschlüssel 031530017017, ich habe die Zahlen korrigiert nach Destatis File vom 31.12.2013.

Müsste ein nicht mehr aktiver Gemeindeschlüssel in einer QS-Karte auffallen?

Soweit ich weiß, handelt es sich hier um den neuen Gemeindeschlüssel von Goslar, der ab dem 1.1.2014 gültig ist.

Gruss
walter

edit: Tüpo

wambacher wrote:

okilimu wrote:

die Goslar-Relation #1421453 hatte bis eben den Gemeindeschlüssel 03153017 und Regionalschlüssel 031530017017, ich habe die Zahlen korrigiert nach Destatis File vom 31.12.2013.

Müsste ein nicht mehr aktiver Gemeindeschlüssel in einer QS-Karte auffallen?

Soweit ich weiß, handelt es hier um den neuen Gemeindeschlüssel von Goslar, der ab dem 1.1.2014 gültig ist.

Genau. Das wurde hier doch schon alles durchgekaut. Bitte erst genau prüfen und ggf. nachfragen, bevor man das ändert.

Hier nochmal der Auszug aus der aktuellen Gebietsänderungsliste von DESTATIS:

031530017017 03153017 Goslar, Stadt Wirksamkeit ab 01.01.2014

EDIT: Habs zurückgeändert.

Hat sich jemand schon mal mit redundant erfassten Admin-Grenzen beschäftigt?

Zumindest bei http://www.openstreetmap.org/#map=15/52.2714/9.8173 haben wir den Fall, dass die Admin-Level-8-Grenzen ordentlich als Way/Relations erfasst sind, aber zusätzlich gibt es noch redundante Admin-Level-8-Grenzen, die nicht zu Boundary-Relations gehören - diese sind leider teilweise anscheinend sogar genauer, so dass man sie nicht einfach löschen sollte...

Moin,

hofoen wrote:

Hat sich jemand schon mal mit redundant erfassten Admin-Grenzen beschäftigt?

[...] - diese sind leider teilweise anscheinend sogar genauer, so dass man sie nicht einfach löschen sollte...

bei einem von den beiden Verläufen muss man aber nunmal die "Grenz-tags" löschen, denn solch ein doppelter Verlauf ist doof.

Ob die geschätzte Grenze nun dem geraden gezackten Verlauf folgt oder sich eher an geologischen Hindernissen orientiert, muss jeder selbst entscheiden.
misterboo hat sich damals (02.2012) anscheinend nicht getraut, die bereits vorhandenen Grenzlinien zu verwenden.
Du Dich jetzt anscheinend auch nicht - damit bin ich derzeit schon mal überstimmt ... 😉

Gruß
Georg

Gehrke wrote:

Wenn sich jemand eine (Extrakt-)Datenbank mit (geometrisch gesehen) sauberen admin- und PLZ-Grenzen für Deutschland aufsetzen möchte, so ist der gestrige Tag ein guter:
Alle Grenzen (bis auf ein paar unfertige AL9/10-Grenzen) sind in Ordnung. Welch seltener Anblick!

Seit dem 4. März war es gestern mal wieder soweit: Alle Grenzen (<=AL8) sind in Ordnung. Eine Ortsteilgrenze war defekt und ist inzwischen repariert.
Auch die PLZ-Grenzen waren alle in Ordnung.

Habe gerade den Landkreis Halberstadt korrigiert. Der hieß in OSM "Landkreis Halberstadt", obwohl jener schon zum 1. Juli 2007 aufgelöst wurde.

EDIT: Sehe gerade, der Fehler hatte sich erst kürzlich eingeschlichen.

Karlshuld hieß bis eben "Karslhuld" - und das seit Bestehen der Relation am 30.05.2010!

Gehrke wrote:

Habe gerade den Landkreis Halberstadt korrigiert. Der hieß in OSM "Landkreis Halberstadt", obwohl jener schon zum 1. Juli 2007 aufgelöst wurde.

EDIT: Sehe gerade, der Fehler hatte sich erst kürzlich eingeschlichen.

Eventuell würde es Sinn machen den alten Namen "Landkreis Halberstadt" durch old_name oder description zu erhalten. Dann werden solche Umbennungen (aus Unkenntnis der Gebietsreform) in Zukunft hoffentlich unterbleiben.

Edbert (EvanE)

EvanE wrote:

Eventuell würde es Sinn machen den alten Namen "Landkreis Halberstadt" durch old_name oder description zu erhalten. Dann werden solche Umbennungen (aus Unkenntnis der Gebietsreform) in Zukunft hoffentlich unterbleiben.

Ich glaube hier eher an einen Unfall. Aber unabhängig davon: Der Landkreis Harz ist ja nicht einfach durch Umbenennung des Landkreis Halberstadt entstanden, sondern durch eine Zusammenlegung mehrerer Kreise.

Gehrke wrote:

EvanE wrote:

Eventuell würde es Sinn machen den alten Namen "Landkreis Halberstadt" durch old_name oder description zu erhalten. Dann werden solche Umbennungen (aus Unkenntnis der Gebietsreform) in Zukunft hoffentlich unterbleiben.

Ich glaube hier eher an einen Unfall. Aber unabhängig davon: Der Landkreis Harz ist ja nicht einfach durch Umbenennung des Landkreis Halberstadt entstanden, sondern durch eine Zusammenlegung mehrerer Kreise.

Dann bleibt nur description=Der Landkreis Harz ist im Jahr nnnn durch Zusammenlegung von XYZ, ABC, ... entstanden.

Edbert (EvanE)

EvanE wrote:

Dann bleibt nur description=Der Landkreis Harz ist im Jahr nnnn durch Zusammenlegung von XYZ, ABC, ... entstanden.

Ich halte nichts davon, die jahrelang zurückliegende Historie von Gebietskörperschaften in Tags abzubilden. Kontinuierlich prüfen muss man eh.
Wenn die Änderung noch frisch ist (bis zu ca. 12 Monate), ist so ein Tagging eher eine Option.

Das neue Gemeindeverzeichnis von DESTATIS ist da:

https://www.destatis.de/DE/ZahlenFakten … sicht.html

Statistisch gab es nur folgende Änderung als Teilausgliederung/Gebietsabtretung (die juristisch aber schon seit dem 1.1. gelten):

In Brandenburg gehen Gebiete (3469 qm) der Stadt Altlandsberg an Gemeinde Fredersdorf-Vogelsdorf über und umgekehrt 10184 qm und 7 Einwohner an Altlandsberg.
Wo genau weiß ich nicht.

Der Februar-Eintrag zur Neuaufnahme "Nds-Küstengewässer(Gemarkung Nordsee)" ist wieder verschwunden.

Gehrke wrote:

Das neue Gemeindeverzeichnis von DESTATIS ist da:

Gute Nachricht!

Ist der user:misterboo eigentlich hier noch im Forum aktiv? Denn auf http://ags.misterboo.de könnte dann die aktuelle Datenbasis dann eingepflegt und ausgewertet werden ...

Es gibt in DE laut DESTATIS jetzt offiziell 11214 Gemeinden. Leider sind in Bayern hierbei aber alle gemeindefreien Gebiete in einem pro Kreis zusammengefasst.
Werde das nochmal nach Bundesland auswerten und mit OSM vergleichen.

Kreise (inkl. kreisfreier Städte gibt es 402). Das stimmt mit OSM überein.

Ein der 270 GVV in BaWü ist aus OSM verschwunden. Es handelt sich um die "VVG der Gemeinde Dornstadt" (RS 084255004).
Konnte keine Spuren von der entdecken. Gab es die jemals in OSM?

Hab jetzt eine neue Relation angelegt: http://www.openstreetmap.org/relation/3639849

Gehrke wrote:

Ein der 270 GVV in BaWü ist aus OSM verschwunden. Es handelt sich um die "VVG der Gemeinde Dornstadt" (RS 084255004).
Konnte keine Spuren von der entdecken. Gab es die jemals in OSM?

ja, die gab es. die sah so komisch aus (z.B. keinen Namen und uralt), daß ich die wohl für eine unentdeckte Leiche gehalten habe.

Asche auf mein Haupt
walter

Aus aktuellem Anlass noch einmal der Hinweis: Weder "Gemeinde" noch "Einheitsgemeinde" u.s.f. sind gewünschte "name:prefix"-Werte für Gemeinde-Relationen.
Anders sieht es mit Stadt, Flecken, Markt, Mähdrescherstadt usw. aus. Referenz ist DESTATIS. Für einige Bundesländern wird dort aber leider z.B. Stadt als "St" abgekürzt.

Chenshi wrote:

mich würde es auch freuen wenn diese sache: https://wiki.openstreetmap.org/wiki/DE: … u_DESTATIS von Gehrke so richtig ins rollen gebracht wird

Gehrke wrote:

Ok. Habe aber im Moment zu viel anderes zu tun. Vielleicht in 2-3 Wochen.

EDIT: Eigentlich lohnt es sich auch erst richtig, wenn das nrue GV Q1/2014 von DESTATIS da ist.

hey, würdest du bitte hier nochmals gucken ob du nun zeit dafür hast? danke

Hallo zusammen,

OSMI meint, Brandenburg, die Havelregion uns Sachsenanhalz ist errötet... oder schon wieder repariert?

fragt Sven

streckenkundler wrote:

OSMI meint, Brandenburg, die Havelregion uns Sachsenanhalz ist errötet... oder schon wieder repariert?

OSMI ist ja immer ein bisschen hinterher. Generell geht bei OSM fast jeden Tag etwas kaputt. Das repariere ich meist am Folgetag. Ich gucke mir morgen wieder alle Verwaltungsgrenzen an.

Gehrke wrote:

Ich gucke mir morgen wieder alle Verwaltungsgrenzen an.

Ok, Danke, das war mir heute Früh Vormittag nach ein aar Tagen Abstinenz aufgefallen, sieht aber warscheinlich schlimmer aus, als es ist.

Sven

Die DE-Verwaltungsgrenzen (AL4-8) sollten in Ordnung sein.

Habe heute mal angefangen, die neue DESTATIS-Liste abzugleichen. Habe da bei den Namen doch einige Abweichungen entdeckt (insb. in Rheinland-Pfalz).
Schlimmer noch: In Thüringen sind die Gemeindeschlüssel teilweise falsch (wegen Änderungen der Verbandsstrukturen). Muss da noch weiter korrigieren.

Wenn das durch ist, geht es weiter mit den Flächenabweichungen.

Mir ist aufgefallen, dass bei den Verwaltungsgemeinschaften in Bayern und bei den Vereinbarten Verwaltungsgemeinschaften bzw. Gemeindeverwaltungsverbänden in Baden Württemberg einige unterschiedliche Schreibweisen existieren. Teilweise wird name:prefix genutzt, usw.

Schreibweisen von Namen in BW:

name:prefix=Verwaltungsgemeinschaft + name=XYZ
name=Verwaltungsgemeinschaft XYZ
name=Vereinbarte Verwaltungsgemeinschaft XYZ
name=VVG XYZ;

name=Verwaltungsverband XYZ
name=Gemeindeverwaltungsverband XYZ
name=GVV XYZ

in Bayern:

name:prefix=Verwaltungsgemeinschaft + name=XYZ
name=Verwaltungsgemeinschaft XYZ
name= XYZ (VGem)

Könnte man das nicht vereinheitlichen? - Viel Aufwand wäre das ja nicht. Welche Schreibweise wäre am besten?

Ich bin noch immer dabei, die Namen gemäß DESTATIS zu prüfen. name:prefix bei Gemeinden setze ich auch nur nach DESTATIS. "name:prefix=Ortsgemeinde" u.ä. kommt weg. Das ist eine landesspezifische Gemeindekategorie aber kein Namenspräfix.

In Rheinland-Pfalz ist man Jahre mit diesem Kram beschäftigt. 😬

Was soll eigentlich "Stadtstaat Berlin"? Als Stadt heiß es "Stadt Berlin" als Bundesland "Berlin", oder?

Auch gut: "Stadt Wehlen, Stadt". offiz. Name nach DESTATIS

Gebe für heute erschöpft auf

Gehrke wrote:

Auch gut: "Stadt Wehlen, Stadt". offiz. Name nach DESTATIS

Ist aber richtig. Es gibt die Stadt "Stadt Wehlen" mit dem Ortsteilen "Dorf Wehlen" (Dorf), Pötzscha und Zeichen. Übrigens mit die kleinste Stadt Sachsens (Deutschlands?)

So, bis auf Bayern (mit blöden DESTATIS-Daten) habe ich jetzt alle Regionalschlüssel der Gemeinden geprüft und korrigiert. Es fehlt nur eine "Gemeinde": Die Küstengewässer in Mecklenburg-Vorpommern ("Küstengewässer einschl. Anteil am Festlandsockel", RS 130009999999).

Bei den Namen gibt es leider noch hunderte Detail-Abweichungen. Meist liegt das am Präfix der Gemeinde (fehlendes "Stadt", überflüssiges "Ortsgemeinde"), Suffixen oder an Abkürzungen im offiziellen Namen (z.B. "gem.fr. Gebiet", "b." statt "bei" u.s.ä.).

In den letzten Wochen habe ich mir mal die bestehenden admin_level=9/10 in Thüringen vorgenommen und mit den Hauptsatzungen (wo auffindbar) abgeglichen. Es waren einige Korrekturen (admin_level, name, Zuordnung der Orte) notwendig. Jetzt sollten alle in OSM bestehenden Ortsteile in Thüringen diesbezüglich korrekt sein.
Seit gestern Abend spendiere ich nun den Verwaltungsgrenzen in Thüringen ihren wikidata tag.

Bin eben nochmals die DESTATIS-Daten durchgegangen (nur Gemeinden). Die fehlenden Küstengewässer von MeckPomm habe ich erstmal als leere Relation eingefügt (macht das irgendwo Probleme?).

Zu den Namen: Vor meiner Bearbeitung waren in DE ohne Bayern (blöde DESTATIS-Daten) 17,4 % der Namen nicht exakt übereinstimmend mit DESTATIS. Hierzu gehören ein falscher Präfix (z.B. fehlendes "Stadt"), ein abweichender Suffix oder auch Abweichungen durch Abkürzungen oder Leerzeichen. Richtig falsch war nur der Name "Storbeck-Frankdorf" (seit mind. 2010).
Jetzt dürfte die Fehlerquote schon deutlich niedriger sein. Werde die nächsten Tage wieder vergleichen.

Ich wurde per PN angesprochen, warum ich denn die amtlichen DESTATIS-Daten verwende, ohne Angabe der Erlaubnis.

Klarstellung dazu: Ich schaue in das DESTATIS-Gemeindeverzeichnis und gleiche dort einzeln Namen und Regionalschlüssel mit OSM-Werten ab. Bei Abweichungen nehme ich ggf. eine manuelle Änderung der OSM-Werte vor.
Ich sehe darin kein Problem. Wenn da jemand rechtliche Probleme sieht, möge er oder sie diese bitte diskutieren.

Ich fürchte allerdings, dass das dazu führen könnte, dass ich fast gar keine Änderungen mehr in OSM machen dürfte. Es könnte ja sein, dass mein Wissen ganz ursprünglich (wenn auch über 5 Ecken) aus einer Quelle stammt, die nicht vollkommen gemeinfrei ist.

geri-oc wrote:

Es gibt die Stadt "Stadt Wehlen" mit dem Ortsteilen "Dorf Wehlen" (Dorf), Pötzscha und Zeichen. Übrigens mit die kleinste Stadt Sachsens (Deutschlands?)

Kleinste Stadt Deutschlands: https://www.openstreetmap.org/relation/1145353

Nach langer Verzögerung bin ich endlich dazu gekommen, wieder das Thema Gebietsabweichungen (OSM vs. DESTATIS) anzugehen.
Als Vorgeschmack hier die ersten Links zu allen Abweichungen in Niedersachsen, NRW, Hessen, Rheinland-Pfalz und Baden-Württemberg als Tabulator-separierte Listen mit absteigender Abweichung:

Niedersachsen: http://maps.aimpulse.com/osm/2014-04-24 … gen_03.txt
Nordrhein-Westfalen: http://maps.aimpulse.com/osm/2014-04-24 … gen_05.txt
Hessen: http://maps.aimpulse.com/osm/2014-04-24 … gen_06.txt
Rheinland-Pfalz: http://maps.aimpulse.com/osm/2014-04-24 … gen_07.txt
Baden-Württemberg: http://maps.aimpulse.com/osm/2014-04-24 … gen_08.txt

Spalten: Regionalschlüssel, Gemeindename, offiz. Fläche, OSM-Fläche, absolute Abweichung, relative Abweichung, OSM ID

EDIT: Niedersachsen, Hessen, NRW und Rheinland-Pfalz hinzu

Sachsen hatte am Freitag noch 522 Verwaltungseinheiten (Al4-8), jetzt sind es 521. Weiß jemand, was fehlt? Tippe auf einen Gemeindeverband.

Gehrke wrote:

Sachsen hatte am Freitag noch 522 Verwaltungseinheiten (Al4-8), jetzt sind es 521. Weiß jemand, was fehlt? Tippe auf einen Gemeindeverband.

schau dich mal im Vogtlandkreis um (der hellbraune nicht grün/blaue Fleck süd-östlich).

Gruss
walter

wo wir schon in Sachsen unterwegs sind - in Dresden scheinen 2-3 Bezirke zu fehlen.

zum "Ausgleich" überlappen sich dort Cotta und Plauen (dunkle Fläche im Süd-Westen):

Gruss
walter

Gehrke wrote:

Sachsen hatte am Freitag noch 522 Verwaltungseinheiten (Al4-8), jetzt sind es 521. Weiß jemand, was fehlt? Tippe auf einen Gemeindeverband.

Alles in Ordnung. Eine obsolete Verwaltungsgemeinschaft wurde entfernt (Markneukirchen-Erlbach). Relations-ID: 2986251.

Gehrke wrote:

Alles in Ordnung. Eine obsolete Verwaltungsgemeinschaft wurde entfernt (Markneukirchen-Erlbach). Relations-ID: 2986251.

Jo, genau. Wenn der Admin-Baum für Deutschland neu aufgebaut ist, sollte auch die Karte wieder ok sein. Hab den automatischen Update für einige Länder wieder aktiviert.

Gruss
walter

Edit: Der Vogtlandkreis ist wieder sauber.

34% Abweichung für Walluf? Halleluja. Ich hab das mal abgeglichen und die Grenze ist wirklich grob falsch eingezeichnet.

Buxdehude ist ja jetzt Hansestadt geworden. Nur hat dieser Flecken 1x AL7 und 1x AL8 als deckungsgleiche Grenze.

Ratlosigkeit auf Chinesisch: Wat nu? 😉

Gruss
walter

wambacher wrote:

Buxdehude ist ja jetzt Hansestadt geworden. Nur hat dieser Flecken 1x AL7 und 1x AL8 als deckungsgleiche Grenze.

Okay. Ist noch nicht bei DESTATIS bekannt. Interessant, dass die Hanse so viele Jahre nach ihrem Bestehen noch Mitglieder aufnimmt 😉

Das Problem mit deckungsgleichen AL7 und AL8 gibt es auch in Lübeck. Dort mit dem Vermerk der Regionalschlüssel-Satzart.
Nach diesem Prinzip müsste es für Berlin 4 Relationen geben. DESTATIS-Auszug (ganz links die Satzart, gefolgt von Textkennzeichen, Regionalschlüssel und Name):

10		11		Berlin
40	41	11000		Berlin,␣Stadt
50	50	110000000	Berlin,␣Stadt
60	61	110000000000	Berlin,␣Stadt

Gehrke wrote:

Das Problem mit deckungsgleichen AL7 und AL8 gibt es auch in Lübeck. Dort mit dem Vermerk der Regionalschlüssel-Satzart.
Nach diesem Prinzip müsste es für Berlin 4 Relationen geben. DESTATIS-Auszug (ganz links die Satzart, gefolgt von Textkennzeichen, Regionalschlüssel und Name):

10		11		Berlin
40	41	11000		Berlin,␣Stadt
50	50	110000000	Berlin,␣Stadt
60	61	110000000000	Berlin,␣Stadt

Ich würde dringenst davon absehen, DESTATIS als Master für alle möglichen Anpassungen von Schreibweisen oder wie hier Mehrfachklassifikationen zu benutzen. Es sollte mMn eine Referenz zur Vollständigkeitsprüfung und Quelle der Schlüssel sein, mehr nicht.
Redundante Grenzverläufe, nur weil es verwaltungstechnisch unterschiedliche Zuständige gibt, halte ich für Overkill.

Das etablierte Verfahren ist (und sollte es bleiben): Es gilt das höchstwertige AL.

Gruss
walter

wambacher wrote:

Redundante Grenzverläufe, nur weil es verwaltungstechnisch unterschiedliche Zuständige gibt, halte ich für Overkill.

Das etablierte Verfahren ist (und sollte es bleiben): Es gilt das höchstwertige AL.

Ja, natürlich. Das war als Abschreckung gemeint.

wambacher wrote:

Ich würde dringenst davon absehen, DESTATIS als Master für alle möglichen Anpassungen von Schreibweisen (...) zu benutzen.

Das würde ich gerne noch weiter diskutieren. Was soll denn die Referenz bzw. Regel sein? Was sich irgendjemand mal aus dem Finger gesaugt hat ja wohl nicht.
Wenn einer schreibt, eine Gemeinde sei eine Stadt und dafür gibt es bei DESTATIS oder anderswo keinen Beleg, muss das doch geändert werden.
Wenn jemand einen Ortsnamen künstlich erweitert (z.B. "(im Landkreis XYZ)", ohne dass es dafür einen Grund gibt (außer den Wikipedia-Artikelnamen), doch wohl auch.

Bei Abkürzungen u.ä. gibt es natürlich Abweichungen. DESTATIS schreibt nur, was die Länder melden. Da gibt es dann leider auch so etwas wie "St.Bernhard" (ohne Leerzeichen).

EDIT: Typo

Gehrke wrote:

Ja, natürlich. Das war als Abschreckung gemeint.

Jetzt bin ich wach 😉

Wirst du denn "Hansestadt Buxdehude" und HS Lübeck abbauen?

Gruss
walter

wambacher wrote:

Wirst du denn "Hansestadt Buxdehude" und HS Lübeck abbauen?

Tja, Löschen fremder Sachen ist ja immer so eine Sache. Werde heute oder morgen wohl mal die Ersteller anschreiben, wenn sie sich nicht zufällig hier melden.

Gehrke wrote:

wambacher wrote:

Wirst du denn "Hansestadt Buxdehude" und HS Lübeck abbauen?

Tja, Löschen fremder Sachen ist ja immer so eine Sache. Werde heute oder morgen wohl mal die Ersteller anschreiben, wenn sie sich nicht zufällig hier melden.

Buxdehude(7) war ein Test von 2012 - steht zumindest so dran. da hab ich keinerlei Hemmungen, das rauszuschmeissen.

Lübeck: ich sehe nur 1xAL6; AL7/8 kann ich auf die Schnelle nicht finden.

Gruss
walter

wambacher wrote:

Buxdehude(7) war ein Test von 2012 - steht zumindest so dran. da hab ich keinerlei Hemmungen, das rauszuschmeissen.

Ok.

wambacher wrote:

Lübeck: ich sehe nur 1xAL6; AL7/8 kann ich auf die Schnelle nicht finden.

Sehe ich auch nicht mehr. Ist wohl inzwischen weg. Habe mich vertan. Es war Lüneburg: ID 334652

Gehrke wrote:

Lüneburg: ID 334652

War stephan75 nicht dort unterwegs. Vielleicht kann hier er ja etwas zur Aufklärung beitragen?

Gehrke wrote:

Sehe ich auch nicht mehr. Ist wohl inzwischen weg. Habe mich vertan. Es war Lüneburg: ID 334652

ok, beide al7 sind weg.

Gruss
walter

Gehrke wrote:

Gehrke wrote:

Lüneburg: ID 334652

War stephan75 nicht dort unterwegs. Vielleicht kann hier er ja etwas zur Aufklärung beitragen?

Seufz ... wenn ihr so schnell seid mit dem Korrigieren, dann kann ich da auch nix mehr zu sagen ... ;-)

Da die ersten Korrekturen bereits vorgenommen wurden, habe ich einige Listen aktualisiert.
Tabelle und Verlinkung zur besseren Übersicht folgen im Wiki.

Niedersachsen: http://maps.aimpulse.com/osm/2014-04-29 … gen_03.txt
Hessen: http://maps.aimpulse.com/osm/2014-04-29 … gen_06.txt
Rheinland-Pfalz: http://maps.aimpulse.com/osm/2014-04-29 … gen_07.txt

Spalten: Regionalschlüssel, Gemeindename, offiz. Fläche, OSM-Fläche, absolute Abweichung, relative Abweichung, OSM ID

Nachdem ein Mapper Küstengrenzen in MeckPomm verändert hat, muss ich mal wieder Relationen mit über 2000 Membern reparieren. Ich könnte kotzen! Auch mit JOSM unwartbar. Wer hat sich das bloß ausgedacht? Es könnte alles so einfach sein...

Bei Olbernau (Sachsen) wurden massiv und brutal Grenzrelation zerstückelt und vermurkst. Versuche das seit 2 Stunden zu korrigieren 😠

EDIT: Betrifft auch Tschechien, was es nicht eben einfacher macht...

EDIT: Done (hoffe ich) 🤔 (nach ca. 3 Stunden)

Was ist das (way ID 278842819) denn für ein Murks?

Da hat jemand in mühevoller Kleinstarbeit die Grenze der Gemeinde Rheinfleden Baden (Rel. ID 2787853) als Way nachgebildet und dann als role "Gemeindegebiet" in die Relation aufgenommen. 🙄

Ach ja, der User hat 25K Edits

Gehrke wrote:

Da hat jemand in mühevoller Kleinstarbeit die Grenze der Gemeinde Rheinfleden Baden (Rel. ID 2787853) als ein Way nachgezeichnet und dann als role "Gemeindegebiet" in die Relation aufgenommen

"Gemeindegebiet" sehe ich nur als Kommentar im Changeset, die Rolle in der Relation ist leer.
Die Aktion verstehe ich aber genau so wenig: Eine area mit (fast) allen Knoten der admin-Grenze angelegt und zur Relation hinzugefügt. Da hat sie mMn nach nichts zu suchen.

Der Sinn einer getrennten area (übrigens mit Tag "tiger:county" für ein is_in Kreis Lörrach) bleibt mir verborgen, da die selbe Information (ohne Flüchtigkeitsfehler) ja auch aus den Grenzen der Relation gewonnen werden kann.

seichter wrote:

Gehrke wrote:

Da hat jemand in mühevoller Kleinstarbeit die Grenze der Gemeinde Rheinfleden Baden (Rel. ID 2787853) als ein Way nachgezeichnet und dann als role "Gemeindegebiet" in die Relation aufgenommen

"Gemeindegebiet" sehe ich nur als Kommentar im Changeset, die Rolle in der Relation ist leer.

Bei mir in JOSM und auf openstreetmap.org ist das aber so.

hab ihn mal angeschrieben mit der Frage, ob er sich hier dazu äußern möchte.

Gruss
walter

Gehrke wrote:

Bei mir in JOSM und auf openstreetmap.org ist das aber so.

Stimmt. Nach Neuladen ist auch bei mir das Feld mit "Gemeindegebiet" belegt.
Dieser Tag fällt für mich völlig aus dem Rahmen des Zulässigen und Üblichen.

Hi, also das nennt man dann wohl Murks gebaut und ich weiß auch nicht, wie das passieren konnte.
Die Grenze angefasst habe ich beim Splitten von Straßen, die über die Grenze laufen (da sich Straßennamen ja an Grenzen ändern).

Ich habe es nun gelöscht. Und ja, ich weiß, man kann mit seinem Leben auch Besseres anfangen, als 25k edits in OSM zu machen 🙂

Grüße
Winfried

q_un_go wrote:

Hi, also das nennt man dann wohl Murks gebaut und ich weiß auch nicht, wie das passieren konnte.
Die Grenze angefasst habe ich beim Splitten von Straßen, die über die Grenze laufen (da sich Straßennamen ja an Grenzen ändern).

So wie ich es sehe, hast du nur die area-Grenze angefasst (einen Knoten hinzugefügt), sie aber nicht erzeugt (darum ging es).
Der "Schuldige" ist in der History eins weiter oben.

Abgesehen davon finde ich es nicht gut, Straßen und admin-Grenzen zu verknüpfen, auch nicht an nur in einem Knoten.
Das führt gern zu Schwierigkeiten. Die Kreisstraße darf ihren Namen ruhig erst ein paar Meter nach der Grenze ändern.

seichter wrote:

q_un_go wrote:

Hi, also das nennt man dann wohl Murks gebaut und ich weiß auch nicht, wie das passieren konnte.
Die Grenze angefasst habe ich beim Splitten von Straßen, die über die Grenze laufen (da sich Straßennamen ja an Grenzen ändern).

So wie ich es sehe, hast du nur die area-Grenze angefasst (einen Knoten hinzugefügt), sie aber nicht erzeugt (darum ging es).
Der "Schuldige" ist in der History eins weiter oben.

Dann bin ich ja erleichtert. Der "Schuldige" ist doch ein Newbie. Ich hatte das wegen des elendlangen History-Eintrags des Ways nicht gesehen, sorry. Die Relation hätte es gleich verraten.

seichter wrote:

Die Kreisstraße darf ihren Namen ruhig erst ein paar Meter nach der Grenze ändern.

Wenn man sich die Sache katastermäßig anschaut, wird deutlich, daß Straßen- oder Wege(-mittellinien) i.d.R. nie Grenzen sind. entweder ist die Straße in der einen oder in der anderen Gemarkung... im Zweifelsfall Gemeinde oder Kreis. Anders ist es oft bei Gewässern. Da war/ ist sehr gerne mal die Gewässermitte die Grenze.
Trotzdem:

seichter wrote:

Abgesehen davon finde ich es nicht gut, Straßen und admin-Grenzen zu verknüpfen, auch nicht an nur in einem Knoten.

wäre das für mich eine wichtige Auswertung eines QA-Tools um das zu eliminieren.

Sven

Hi,

ich hatte gestern ja einige "komische" PLZ-Grenzen in Berlin dargestellt.
Es kommt aber noch schlimmer: zumindest in der gleichen Ecke (Lichtenfelde, ...) sind auch viele Administrative Grenzen einfach neben-, über- und durcheinander erfaßt. Teile davon in den etablierten Relationen, die anderen separat.
Was ist denn da los? ich würde die (Leichen?) rauswerfen.

https://www.openstreetmap.org/way/115947499
https://www.openstreetmap.org/way/115947791
https://www.openstreetmap.org/way/115947746

usw

gruss
walter

Apropos, in Münster ist auch einiges krude bis kaputt. Ich repariere da gerade viele Fehler, die gestern entstanden sind.

Hallo Gehrke,

seichter wrote:

Abgesehen davon finde ich es nicht gut, Straßen und admin-Grenzen zu verknüpfen, auch nicht an nur in einem Knoten.
Das führt gern zu Schwierigkeiten. Die Kreisstraße darf ihren Namen ruhig erst ein paar Meter nach der Grenze ändern.

Also ich als Newbie habe bei http://www.openstreetmap.org/node/505058472 im Bereich der Straße "K520 / Am Gläserberg / Engenau" genau das ebenfalls gemacht, also Grenze mit Nodes verbunden, weil ich sonst wieder Schwierigkeiten mit der Straßenlistenauswertung bekomme: Am Gläserberg gehört zu Nahetal-Waldau, Engenau aber zu Schleusegrund.
Und durch deine Bearbeitung und meine Verknüpfung hat halt jetzt die Straße einen Knick bekommen.

Und ja, wenn du wambacher's residentials anguckst, wirst du sehen, dass das (westliche) Ortsschild von Langenbach (Gemeinde Schleusegrund) im Gebiet von Nahetal-Waldau steht und ein paar Meter weiter, eben nur für diese Ausbuchtung mit den drei Häusern von Am Gläserberg sogar ein schönes grünes Schild (hamlet) Waldau aufgestellt wurde :-D

So und nu?

EDIT: Und hier halte ich es für sinnvoll, weil eben jeweils an der Grenze auch der Straßenname beginnt, im Gegensatz zum o.g. Zitat.

Viele Grüße
Harald Hartmann

Harald Hartmann wrote:

Also ich als Newbie habe bei http://www.openstreetmap.org/node/505058472 im Bereich der Straße "K520 / Am Gläserberg / Engenau" genau das ebenfalls gemacht, also Grenze mit Nodes verbunden, weil ich sonst wieder Schwierigkeiten mit der Straßenlistenauswertung bekomme: Am Gläserberg gehört zu Nahetal-Waldau, Engenau aber zu Schleusegrund.
Und durch deine Bearbeitung und meine Verknüpfung hat halt jetzt die Straße einen Knick bekommen.

Sorry, ich habe den Node jetzt erstmal von der Straße getrennt und den Knick korrigiert.
Wegen der Straßenlistenauswertung würde ich da keine Ausnahmen machen. Die Grenze sollte da laufen, wo sie ist und die Straße auch.

Gehrke wrote:

Die Grenze sollte da laufen, wo sie ist und die Straße auch.

Das ja,

Gehrke wrote:

Wegen der Straßenlistenauswertung würde ich da keine Ausnahmen machen

das nein, da bin ich definitiv nicht mit einverstanden.

Sorry, aber hier würde ich Dich, Walter (wambacher) und Dietmar (okilimu) bitte Euch vielleicht mal zusammen auszutauschen. Meiner Meinung nach kann es nicht sein, dass sich mehrere (Groß) Projekte - die sich um Qualität kümmern - dann konträr zueinander Verhalten! 😠

seichter wrote:

Abgesehen davon finde ich es nicht gut, Straßen und admin-Grenzen zu verknüpfen, auch nicht an nur in einem Knoten.
Das führt gern zu Schwierigkeiten. Die Kreisstraße darf ihren Namen ruhig erst ein paar Meter nach der Grenze ändern.

Das sehe ich anders. Je PLZ-Gebiet bzw. Gemeinde gibt es in der Regel nur eine Straße selben Namens. Und an der Gemeindegrenze beginnt dann ein neuer Name, wo denn auch sonst?

Die Hauptstraße meines Wohnortes etwa heißt Schönbergstraße. Wenn die nicht an der Gemeindegrenze beginnt, sondern, davor ragt die in die Nachbargemeinde. Dort gibt es auch eine Schönbergstraße,
aber einen Kilometer weiter. Das würde also zu Fehlern führen, wenn die Schönbergstraße dann zweimal auftaucht. Und solche Fälle gibt es auch anderswo, etwa am Hochrhein, zu Hauf.
Da sollte z.B. die Basler Straße auch korrekt vorkommen. Basler Straßen und Freiburger Straßen als Hauptverkehrsstraßen sind in meiner Gegend sehr häufig und dein Vorgehen würde m.E. zu Doppeldeutigkeiten führen.
Oder es gibt plötzlich in Orten Straßennamen, die es dort eben gar nicht gibt.

An Gemarkungsgrenzen ändern sich auch oft die Bezeichnungen von Bächen, sofern der Bach nicht selbst die Grenze darstellt. Die Gemarkungsgrenze (eine Stufe tiefer als die Gemeindegrenze) trennt nun einmal sehr häufig auch Namensräume.

Grüße
Winfried

Harald Hartmann wrote:

Sorry, aber hier würde ich Dich, Walter (wambacher) und Dietmar (okilimu) bitte Euch vielleicht mal zusammen auszutauschen. Meiner Meinung nach kann es nicht sein, dass sich mehrere (Groß) Projekte - die sich um Qualität kümmern - dann konträr zueinander Verhalten

Naja, meine Residentials "verhält" sich nicht, sondern sie stellt nur den Datenbestand in OSM dar. Es werden hier keinerlei Entscheidungen in der Art richtig/falsch getroffen.

Kleiner Trick zum Positionieren von kritischen Nodes, die zwar genau an der gleichen Koordinate liegen müssen aber dennoch getrennt bleiben sollen:
Die gemeinsamen Nodes (z.B. Grenze/Straße) verbinden (M in Josm) und gleich danach wieder trennen (G in Josm)

Gruss
walter

Nur mal als unfertiger Gedanke eingeworfen: Muss die Straße denn unbedingt exakt bis zur Grenze einen Namen haben? Man könnte ja auch ein unbenanntes Stück abtrennen, das z.B. bis zur Kreuzung geht und die Grenze überlappt. Dann würden sich Grenzwelt und Straßen(namen)welt nicht in die Quere kommen.

Gehrke wrote:

Nur mal als unfertiger Gedanke eingeworfen: Muss die Straße denn unbedingt exakt bis zur Grenze einen Namen haben? Man könnte ja auch ein unbenanntes Stück abtrennen, das z.B. bis zur Kreuzung geht und die Grenze überlappt. Dann würden sich Grenzwelt und Straßen(namen)welt nicht in die Quere kommen.

nun, dann kommt wieder jemand und meint: "Josm motz, weil das Residential keinen Namen hat". Ich bin mehr für grenzgenaues Splitten.

Gruss
walter

Hallo Gehrke,

Gehrke wrote:

Harald Hartmann wrote:

Also ich als Newbie habe bei http://www.openstreetmap.org/node/505058472 im Bereich der Straße "K520 / Am Gläserberg / Engenau" genau das ebenfalls gemacht, also Grenze mit Nodes verbunden, weil ich sonst wieder Schwierigkeiten mit der Straßenlistenauswertung bekomme: Am Gläserberg gehört zu Nahetal-Waldau, Engenau aber zu Schleusegrund.
Und durch deine Bearbeitung und meine Verknüpfung hat halt jetzt die Straße einen Knick bekommen.

Sorry, ich habe den Node jetzt erstmal von der Straße getrennt und den Knick korrigiert.
Wegen der Straßenlistenauswertung würde ich da keine Ausnahmen machen. Die Grenze sollte da laufen, wo sie ist und die Straße auch.

laut einer amtlichen Datei verlaufen die Subadmin-Grenzen an einigen Stellen auf der Straße, weil in der Datei steht, das die Häuser auf einer Seite zu einem anderen Bereich als die auf der anderen Seite gehören und das in Bezug zur Straße angegeben ist.

Es ist also in der Realität (nicht nur in Münster, auch bei uns in Augsburg) der Fall, das die Straße die Trennung darstellt und daher finde ich Deine Änderungen ohne lokale Kenntnisse (ich habe in Münster auch keine, kümmere mich gerade aber etwas wegen der empfangenden Straßenliste und Hausnumemrliste darum) nicht ok.

viele Grüße

Dietmar

okilimu wrote:

Es ist also in der Realität (nicht nur in Münster, auch bei uns in Augsburg) der Fall, das die Straße die Trennung darstellt und daher finde ich Deine Änderungen ohne lokale Kenntnisse (ich habe in Münster auch keine, kümmere mich gerade aber etwas wegen der empfangenden Straßenliste und Hausnumemrliste darum) nicht ok.

Wie gesagt, wir können das gerne diskutieren. Meine Änderung war explizit vorläufig. Ich habe nur schnell den "Knick" korrigieren wollen.
In der Sache: "Sollten Flüsse, Straßen etc. als Grenzlinien verwendet werden dürfen?" habe ich keine fertige Meinung.

In Münster hatte ich, sofern ich das sehe, nur offene Grenzpolygone geschlossen.

wambacher wrote:

Naja, meine Residentials "verhält" sich nicht, sondern sie stellt nur den Datenbestand in OSM dar. Es werden hier keinerlei Entscheidungen in der Art richtig/falsch getroffen.

richtig/falsch wollte ich auch nicht andeuten, ich habe ja von Projekten zur Qualitätsverbesserung gesprochen, und da könnte sich die kleine Grenzverschieberei nicht nur auf die Straßenliste sondern auch auf deine PLZ Irrläufer auswirken 😛

Gehrke wrote:

Man könnte ja auch ein unbenanntes Stück abtrennen, das z.B. bis zur Kreuzung geht und die Grenze überlappt.

Bei meinem o.g. Node wäre ja aber dein Grenznode immer westlich von der Straße, unabhängig davon ob man jetzt unbenannte Stücke hat oder nicht.

Harald Hartmann wrote:

Gehrke wrote:

Man könnte ja auch ein unbenanntes Stück abtrennen, das z.B. bis zur Kreuzung geht und die Grenze überlappt.

Bei meinem o.g. Node wäre ja aber dein Grenznode immer westlich von der Straße, unabhängig davon ob man jetzt unbenannte Stücke hat oder nicht.

Das stimmt. Wo läuft denn die Grenze auf der Straße bzw. ist die Straße die Grenze? Dann hätten wir wieder ein Zuodnungsproblem. Oder läuft die Grenze östlich?

EDIT: Habe eben bei http://www.geodatenzentrum.de gespickt und kann da nicht erkennen, wo die Grenze genau läuft. Irgendwie unter der dargestellten Straße und dem Bach.

Gehrke wrote:

Das stimmt. Wo läuft denn die Grenze auf der Straße bzw. ist die Straße die Grenze? Dann hätten wir wieder ein Zuodnungsproblem. Oder läuft die Grenze östlich?

Ja, um das herauszufinden, die Diskussion hatte ich gestern mit Dietmar, müsste ich, ich weiss ja nicht woher du deine Daten hast, eigentlich zum Katasteramt gehen und mir die Flurlinien zeigen lassen ;-)

Edit: PS: Ich verweise dich da gerne nochmal auf mein o.g. Beispiel. Du fährst auf eine Straße und siehst zunächst ein Ortschild Langenbach (Gemeinde Schleusegrund) und 30m weiter steht links am Straßenrand ein grünes Hamlet-Schild Waldau rum. 😄

Gehrke wrote:

Habe eben bei http://www.geodatenzentrum.de gespickt und kann da nicht erkennen, wo die Grenze läuft.

Die Daten vom Geodatenzentrum sind da auch nicht geeignete. Diese sind generalisiert.

Harald Hartmann wrote:

müsste ich, ..., eigentlich zum Katasteramt gehen und mir die Flurlinien zeigen lassen

Das brächte eine saubere Lösung. In der Regel ist die Straße ein eigenes Flurstück. Somit verläuft die Grenze entweder rechts oder links einer Straße. Da müsste dann auch die Grenze hin.
Das ist die katastermäßige Seite der Medaille. Die Namen einer Straße beziehen sich dann aber stets auf die Straßenachse. Das kurze Stück vom Knotenpunkt der Straßenachsen bis zur Katastermäßigen Grenze ist dabei irrelevant für die Gemeinde, in der das kurze Stück liegt.

Sven, der sich aber die Situation nicht genau angeschaut hat.

streckenkundler wrote:

Gehrke wrote:

Habe eben bei http://www.geodatenzentrum.de gespickt und kann da nicht erkennen, wo die Grenze läuft.

Die Daten vom Geodatenzentrum sind da auch nicht geeignete. Diese sind generalisiert.

Ja, aber oft trotzdem ein guter Anhaltspunkt. Die Generalisierung unterscheidet sich z.B. auch je nach Zoomstufe teils erheblich (vgl. z.B. Seegrenze Bremerhaven).

Letztlich basieren doch die "genauen" Grenzlinien in OSM für BaWü auf den gleichen Karten, oder?

Gehrke wrote:

Letztlich basieren doch die "genauen" Grenzlinien in OSM für BaWü auf den gleichen Karten, oder?

Die Basis ist die gleiche. Es ist aber unterm Strich doch ein Unterschied, ob ich DLM250 - Daten habe (Geodatenzentrum), oder DLM25-Genauigkeit (vergleiche http://forum.openstreetmap.org/viewtopi … 13#p304713 oder als Basis die Katastergrenzen.

Ausgehend von den Katastergrenzen sind DLM 25 schon das erste Mal generalisiert und DLM250 das zweite Mal. Jede Generalisierung ist mit Informtationsverlust (Weglassen von Stützpunkten) verbunden, der sich gerade bei solch speziellen Themen, wie Lage einer Straße an einer Grenze zeigt.

streckenkundler wrote:

Ausgehend von den Katastergrenzen sind DLM 25 schon das erste Mal generalisiert und DLM250 das zweite Mal. Jede Generalisierung ist mit Informtationsverlust (Weglassen von Stützpunkten) verbunden

Kannst Du erklären, wie es zu so drastischen Unterschieden wie bei der Seegrenze von Bremerhaven kommt? Generalisierung ist dort nicht der Grund.

Also ich habe jetzt mal den Geoclient von geoportal-th.de verwendet, und nachdem ist in meinem o.g. Fall die Gemarkungsgrenze links/westlich von der Straße - als der "Straßengraben". Wenn ich mir aber den ALKIS Katalog, ebenfalls von geoportal-th.de runterlade und in die Gemarkung Schleusegrund schaue, gibt es da aber keine Straße namens "Am Gläserberg". Und wenn ich aber vor Ort an dieser Kreuzung bin, ist definitiv die Straße in Richtung Norden als "Am Gläserberg" ausgeschildert 🙄

Edit: Was mich jetzt zu folgendem Gedanken bringt: Ist ein Straßenschild ein Indiz dafür, dass die Straße auch wirklich so heißt? Oder ist es in dem Fall nur eine Hilfe für den Postboten, dass er an dieser Straße entlang noch Häuser findet, die die postialische Adresse Am Gläserberg haben?
@Dietmar, weisst du hierzu etwas (also zu meiner Indiz-Frage)?

okilimu wrote:

laut einer amtlichen Datei verlaufen die Subadmin-Grenzen an einigen Stellen auf der Straße, weil in der Datei steht, das die Häuser auf einer Seite zu einem anderen Bereich als die auf der anderen Seite gehören und das in Bezug zur Straße angegeben ist.

Die Straße ist nicht die Grenze, sondern die Grenze verläuft auf der Straße.
Den kleinen Unterschied bemerkt man z.B. dann, wenn im Straßenverlauf ein Kreisverkehr angelegt wird. Da muss man dann spätestens die Grenze von der Straße trennen.

Selbst bei Gewässern ist es oft so, dass die Grenze nur ungefähr entlang des Baches verläuft, weil die Vermesser "keine Lust haben", nach jedem Hochwasser die Grenze dem geänderten Verlauf anzupassen.

Bei subadmin-Grenzen wird das nicht so genau genommen, die müssen nicht mal unbedingt vermessen sein. Da kann man beim "Kleben" großzügiger sein.
Trotzdem muss man auch da höllisch aufpassen, dass man z.B. bei einer Neuaufteilung der Stadtteile nicht den Bach oder die Straße bei der Korrektur "mitreißt". Der JOSM-Validator schimpft da inzwischen, bei anderen Tools bin ich mir da nicht so sicher.

Gehrke wrote:

Letztlich basieren doch die "genauen" Grenzlinien in OSM für BaWü auf den gleichen Karten, oder?

Basierend ja, aber generalisiert und das nicht mal konsistent.
Es gibt Gegenden, da stimmt die Grenze auf Bruchteile von Metern, woanders liegt sie (nach Kataster) bis zu 20 m daneben.
Ich habe fast den Eindruck, das hing vom Mitarbeiter (oder Wochentag) ab, als die Landesdaten aus den Katasterdaten generalisiert wurden.

Gehrke wrote:

Kannst Du erklären, wie es zu so drastischen Unterschieden wie bei der Seegrenze von Bremerhaven kommt? Generalisierung ist dort nicht der Grund.

Das schaue ich mit Abend mal genauer an. Da muß ich erst mal ein Gis-Projekt mit verschiednen Datenquellen bauen.

Sven

seichter wrote:

Selbst bei Gewässern ist es oft so, dass die Grenze nur ungefähr entlang des Baches verläuft, weil die Vermesser "keine Lust haben", nach jedem Hochwasser die Grenze dem geänderten Verlauf anzupassen.

Die Theorie:
http://www.bravors.brandenburg.de/sixcm … c.12316.de
https://recht.nrw.de/lmi/owa/br_bes_tex … n=N&menu=1

Die Praxis hast du ja genannt. Deswegen passen heutzutage oft die Grenzen (die alle auf Katasterdaten beruhen) z.B. nicht mehr zum realen Gewässerverlauf.

Sven

wambacher wrote:

Kleiner Trick zum Positionieren von kritischen Nodes, die zwar genau an der gleichen Koordinate liegen müssen aber dennoch getrennt bleiben sollen:
Die gemeinsamen Nodes (z.B. Grenze/Straße) verbinden (M in Josm) und gleich danach wieder trennen (G in Josm)

Dann beschweren sich andere QA tools wieder über doppelte nodes.

Baßtölpel

seichter wrote:

Trotzdem muss man auch da höllisch aufpassen, dass man z.B. bei einer Neuaufteilung der Stadtteile nicht den Bach oder die Straße bei der Korrektur "mitreißt". Der JOSM-Validator schimpft da inzwischen, bei anderen Tools bin ich mir da nicht so sicher.

Auch der kann das nur bemerken wenn die Ways geladen sind und die Abweichung z.B. zu überschneidenden Ways führt, was man auch selbst bemerken könnte. Und für ersteres bräuchte es mindestens ein note=*, damit man als Mapper eine Chance hat es zu bemerken.

Basstoelpel wrote:

Dann beschweren sich andere QA tools wieder über doppelte nodes.

Und wenn sich was ändert müsste man das andere eigentlich auch ändern…
Für die Strassenlistenauswertung: Spricht etwas dagegen, die Ways nur zu dem Ort, in dem der grössere Teil oder ihr Mittelpunkt ist, zu zählen?

Hallo rqyquaza,

rayquaza wrote:

...
Für die Strassenlistenauswertung: Spricht etwas dagegen, die Ways nur zu dem Ort, in dem der grössere Teil oder ihr Mittelpunkt ist, zu zählen?

eine große Straße verläuft u.U. durch einige/viele Stadtbezirke/-teile und ich möchte schon den OSM-Sachverhalt darstellen. Daher reicht ein kleiner Teil eines Weges in einem Subbereich aus, das dort erstmal alle Hausnummern als fehlend angezeigt werden, weil für die fehlenden Nrn. ja meist keine Koordinaten vorliegen, um zu entscheiden, welche konkret in dem Subbereich noch fehlen. Gut ist es, wenn die Hausnummernliste einer Stadt die Subbereichzuordnung je Hausnummer hat, dann geht eine exakte Anzeige, welche noch fehlen.

In der Praxis gibt es die einen Mapper, die in einem engen Umfeld erfassen und nur einige, die auch mal entlang einer langen Straße laufen und wirklich alle Hrn erfassen. Bei einer Zuordnung der großen Straße nur zu einem Subbereich muß der erstere ggfs. erstmal nachsehen, in welchem Subbeeich denn der Schwerpunkt der Straße liegt, das finde ich zu umständlich.

viele Grüße

Dietmar

okilimu wrote:

Gut ist es, wenn die Hausnummernliste einer Stadt die Subbereichzuordnung je Hausnummer hat, dann geht eine exakte Anzeige, welche noch fehlen.

Zum Verständnis: Ist ein Eintrag addr:suburb am Haus für die Straßenlistenauswertung also hilfreich?

Basstoelpel wrote:

Dann beschweren sich andere QA tools wieder über doppelte nodes.

jau 🙁

nun denn, ich kann mit Beidem leben.

Gruss
walter

Hallo seichter,

seichter wrote:

okilimu wrote:

Gut ist es, wenn die Hausnummernliste einer Stadt die Subbereichzuordnung je Hausnummer hat, dann geht eine exakte Anzeige, welche noch fehlen.

Zum Verständnis: Ist ein Eintrag addr:suburb am Haus für die Straßenlistenauswertung also hilfreich?

nein, das bringt aktuell nichts.

Die in OSM erfassten Hausnummern haben ja Koordinaten und die prüfe ich gegen möglichst vorhandene Subberreiche (also Stadtbezirke/-teile/-whatevername) einer Stadt/Gemeinde.

Wichtig ist, ob in der bereitgestellten Liste die Subbereichs-Zuordnung enthalten ist.

Wenn ja und Subbereiche vorhanden: dann kann ich exakt angeben, welche im Subbereich noch fehlen (bingo, deluxe Auswertung möglich).

Wenn ja, aber keine Subbereiche vorhanden: dann könnten theoretisch über die vorhandene Liste mit den schon erfassten Hausnummern allmählich die Subbereiche erzeugt werden. Jochen Topf hatte in Karlsruhe beim Februar Hack Weekend da mal einen kleinen Testlauf gemacht.

Wenn nein, aber Subbereiche vorhanden: dann werden alle noch fehlenden in den Auswertungen angezeigt, egal ob sie in dem Stadtbereich zu suchen sind oder nicht.

Wenn nein und es gibt keine Subbereiche: dann gibt es sowieso nur eine Gesamtauswertung, es können keine Subbereiche erzeugt werden. In diesem Fall könnte die addr:suburb Ergänzung die Grundlage sein, um die Subbereiche zu erzeugen, z.B. per Programm. Aber die Info wird es nicht für jede Hausnummer geben, das wäre aber nötig. Ich würde empfehlen, bei der Gemeinde nachzuhaken, ob es zumindest eine textuelle Beschreibung der Subbereiche gibt. Bei größeren Städten gibt es die evtl. auch bei Wikipedia (dort aber nochmal prüfen, woher dort die Infos sind und ob sie nutzbar sind). Bei uns in Augsburg sind im statistischen Jahrbuch die Stadtbezirke beschrieben über Straßen und Wege, das ist zwar nicht Hausnummerscharf, reicht aber aus.

viele Grüße

Dietmar

Hallo Harald,

Harald Hartmann wrote:

...

Edit: Was mich jetzt zu folgendem Gedanken bringt: Ist ein Straßenschild ein Indiz dafür, dass die Straße auch wirklich so heißt? Oder ist es in dem Fall nur eine Hilfe für den Postboten, dass er an dieser Straße entlang noch Häuser findet, die die postialische Adresse Am Gläserberg haben?
@Dietmar, weisst du hierzu etwas (also zu meiner Indiz-Frage)?

da habe ich das gleiche Wissen wie jeder andere hier, also kein subjektives.

Im allgemeinen sehen die Straßenschilder in einer Gemeinde ja mehr oder weniger gleich aus, von Einzelfällen sicher wieder abgesehen.

Wenn das ortsübliche Straßenschild pur dasteht, gehe ich davon aus, das die Straße benannt ist.

Manchmal sind für kleine Nebenstraßen oder außerhalb Ortschaften die Hausnummern darunter: in Orten übernehme ich den Straßennamen dann auch, außerhalb von Ortschaften aber eher nicht, dann sehe ich die Schilder nur als Hinweis auf die konkreten Adressen an.

Das ist aber meine persönliche Interpretation und bezieht sich vor allem auf frühere Aktionen im Ostallgäu und vereinzelt im größeren ländlichen Umfeld von Augsburg.

viele Grüße

Dietmar

Gehrke wrote:

Kannst Du erklären, wie es zu so drastischen Unterschieden wie bei der Seegrenze von Bremerhaven kommt? Generalisierung ist dort nicht der Grund.

Ich habe bisher keine bremer oder niedersächsische Grenze digital oder als WMS genauer als 1:100 000 gefunden. über Hilfe wäre ich dankbar.
Ich habe mir aber mal die Grenzen des WMS-Dienstes http://www.geobasisdaten.niedersachsen.de/bestand? im Vergleich zum WMS-Dienst http://sg.geodatenzentrum.de/wms_vg250? angeschaut. Im ersteren Dienst endet die Grenze an der westlichen Tiefenwasserlinie der Weser. Bei den Daten des Geodatenzentrums nicht, sondern irgendwo weiter westlich (älterer oder nicht aktueller Datenstand???). Ich denke mal, das meinst du... oder? Ich persönlich halte das für eine eher Pi mal Daumen-gezogene Grenze. Das ist jetzt aber nicht negativ gemeint, sondern der ständig wechselnden Situation der Nordsee und deren Zuläufen geschuldet.

Sven

streckenkundler wrote:

Gehrke wrote:

Kannst Du erklären, wie es zu so drastischen Unterschieden wie bei der Seegrenze von Bremerhaven kommt? Generalisierung ist dort nicht der Grund.

Ich habe bisher keine bremer oder niedersächsische Grenze digital oder als WMS genauer als 1:100 000 gefunden. über Hilfe wäre ich dankbar.
Ich habe mir aber mal die Grenzen des WMS-Dienstes http://www.geobasisdaten.niedersachsen.de/bestand? im Vergleich zum WMS-Dienst http://sg.geodatenzentrum.de/wms_vg250? angeschaut. Im ersteren Dienst endet die Grenze an der westlichen Tiefenwasserlinie der Weser. Bei den Daten des Geodatenzentrums nicht, sondern irgendwo weiter westlich (älterer oder nicht aktueller Datenstand???). Ich denke mal, das meinst du... oder? Ich persönlich halte das für eine eher Pi mal Daumen-gezogene Grenze. Das ist jetzt aber nicht negativ gemeint, sondern der ständig wechselnden Situation der Nordsee und deren Zuläufen geschuldet.

Danke für Deine Recherche. Ja ich meine den beschriebenen Unterschied. Für Niedersachsen gibt es die Gemeindegrenzen in hoher Auflösung (LAYERS=gemeinden_umringe) (bedarf aber einer Nutzungslizenz!)
Beim Geodatenzentrum sieht man in der Darstellung im Browser schon die großen Unterschiede je nach Zoomstufe. Der Widerspruch zeigt sich dort also schon in einem Dienst.

Es muss ja eine offizielle Grenze geben. Bei DESTATIS wird ja auch eine genaue Fläche für Bremerhaven angegeben. Da die in OSM deutlich kleiner ist, gehe ich davon aus, dass die DESTATIS gemeldeten Daten auf der weiter nach Westen ausgedehnten Seegrenze Bremerhavens beruhen. Das würde dann allerdings der Darstellung im Niedersachsen-WMS widersprechen.

Ich habe den Listen für DESTATIS-Flächenabweichungen einige Updates spendiert.

Guckst Du hier: https://wiki.openstreetmap.org/wiki/DE: … 9Cbersicht

Gehrke wrote:

Ich habe den Listen für DESTATIS-Flächenabweichungen einige Updates spendiert.

Bei der Spalte "Abweichung" wäre es schön zu sehen, ob OSM im Vergleich zu DESTATIS größer oder kleiner ist, also ein plus oder Minus vor der Zahl...

Sven

streckenkundler wrote:

Gehrke wrote:

Ich habe den Listen für DESTATIS-Flächenabweichungen einige Updates spendiert.

Bei der Spalte "Abweichung" wäre es schön zu sehen, ob OSM im Vergleich zu DESTATIS größer oder kleiner ist, also ein plus oder Minus vor der Zahl...

Wenn gewünscht, kann ich diese Spalte noch hinzufühen (ist ausgeblendet). Den absoluten Werte nutze ich für die Sortierung (könnte diese Spalte dann auch ausblenden).
Ich dachte, es reicht, die beiden Zahlen zur Gesamtfläche zu vergleichen, um zu sehen, ob etwas fehlt oder zu viel ist.

Gehrke wrote:

Danke für Deine Recherche. Ja ich meine den beschriebenen Unterschied. Für Niedersachsen gibt es die Gemeindegrenzen in hoher Auflösung (LAYERS=gemeinden_umringe) (bedarf aber einer Nutzungslizenz!)
Beim Geodatenzentrum sieht man in der Darstellung im Browser schon die großen Unterschiede je nach Zoomstufe. Der Widerspruch zeigt sich dort also schon in einem Dienst.

Es muss ja eine offizielle Grenze geben. Bei DESTATIS wird ja auch eine genaue Fläche für Bremerhaven angegeben. Da die in OSM deutlich kleiner ist, gehe ich davon aus, dass die DESTATIS gemeldeten Daten auf der weiter nach Westen ausgedehnten Seegrenze Bremerhavens beruhen. Das würde dann allerdings der Darstellung im Niedersachsen-WMS widersprechen.

Ich hab mir die Sache noch mal Niedersachsen-Viewer angeschaut, sowie verfügbare WMS-Dienste im ArcGis geladen.

Östliche der Bremerhaven vorgelagerten Insel "Langlütjen II" sind anscheinend zwei Grenzen auf der Karte angerissen. Die eine der beiden (östliche) scheint mit DESTATIS in etwa zu korrelieren. Wenn ich ein kartenaffiner Niedersachse oder Bremer wäre, wüsste ich, was da los ist... aus dem fernen Spreewald (genauer z.Z. aus dem Zug, auf der Heimfahrt) aber fehlt mir da da lokale Wissen.

Sven

Gehrke wrote:

Ich dachte, es reicht, die beiden Zahlen zur Gesamtfläche zu vergleichen, um zu sehen, ob etwas fehlt oder zu viel ist.

Wer kann das denn heute noch im Kopf?

Baßtölpel

Basstoelpel wrote:

Gehrke wrote:

Ich dachte, es reicht, die beiden Zahlen zur Gesamtfläche zu vergleichen, um zu sehen, ob etwas fehlt oder zu viel ist.

Wer kann das denn heute noch im Kopf?

Hast Du die Ironie-Annotierung vergessen? Jeder 10-jährige kann doch sehen, ob eine Zahl größer als eine andere ist.
Die Differenz hat ja eine eigene Spalte.

Sollte doch offensichtlich sein, daß der Beitrag ironisch gemeint war.

Baßtölpel

Basstoelpel wrote:

Sollte doch offensichtlich sein, daß der Beitrag ironisch gemeint war.

Dachte nur, es war vielleicht nicht klar, dass es natürlich auch eine Spalte für die Differenz gibt.

Harald Hartmann wrote:

Edit: Was mich jetzt zu folgendem Gedanken bringt: Ist ein Straßenschild ein Indiz dafür, dass die Straße auch wirklich so heißt? Oder ist es in dem Fall nur eine Hilfe für den Postboten, dass er an dieser Straße entlang noch Häuser findet, die die postialische Adresse Am Gläserberg haben?

Hehe, also ich war nun persönlich auf der Gemeinde und hab mir das erklären lassen. Und was soll ich sagen: mein eigentlicher Pseudoedit ist richtig 🤣
"Die Gemarkungsgrenze ist richtig eingetragen. Der Straßenkörper von der T-Kreuzung in Richtung Norden gehört der Gemeinde Schleusegrund. Der Straßenkörper heißt und ist auch in der Liegenschaft als Talstraße eintragen. Da es dort aber kein Haus auf Seiten der Gemeinde Schleusegrund gibt, hat man es der Nachbargemeinde Nahetal-Waldau überlassen, dort für den Postboten ein Straßenschild mit Am Gläserberg aufzustellen" 😬

@Dietmar: Auch "Löffelberg" und "Tannengrundstraße" hat sich auch geklärt:
- Löffelberg ist im zuständigen Katasteramt korrekt als Straße aufgeführt, die Gemeinde führt diese Straße aber nicht auf und zeichnet sie auch nicht aus, weil sie von den Eigentümern der FeWo-Bungalowsiedlung nicht zum Ausbau freigegeben wurde.
- Tannengrundstraße ist in der Tat eine Verbindungsstraße zwischen zwei Orten in der Nachbargemeinde und -landkreis. Die Gemeinde Schleusegrund hat aber dort noch ein Grundstück liegen, auf dem drei Häuser stehen. Die Bewohner wohnen zwar in Neustadt am Rennsteig sind aber bei der Gemeinde Schleusegrund gemeldet.

Ich habe auch die Auskunft bekommen, das man aktuell und wohl auch noch die nächsten Monate damit beschäftigt ist, sich die, teils aus 18hundertirgendwas, jetzt mal zu überprüfen, ob die Liegenschaften überhaupt noch richtig sind... und wann diese Daten dann mal in die entsprechenden Kataster, ALKIS, etc kommen, dazu wollte man mir keine Auskunft geben.

So, und wie das jetzt nochmal mit dem "wir können/sollen/müssen nur das mappen was wir sehen"? 🙄

Naturschutzgebiet mit admin_level=7

http://www.openstreetmap.org/relation/391918
http://www.openstreetmap.org/relation/3177600
http://www.openstreetmap.org/relation/382375

Stimmt das?

AndiG88 wrote:

Naturschutzgebiet mit admin_level=7

http://www.openstreetmap.org/relation/391918
http://www.openstreetmap.org/relation/3177600
http://www.openstreetmap.org/relation/382375

Stimmt das?

Nein, da keine Gebietskörperschaft. Im Übrigen haben die in DE und OSM entweder einen Regionalschlüssel oder sind historisch.

Gehrke wrote:

Nein, da keine Gebietskörperschaft. Im Übrigen haben die in DE und OSM entweder einen Regionalschlüssel oder sind historisch.

Was mich dann zu meiner nächsten Frage führen würde: http://www.openstreetmap.org/relation/3672639 🙄

__________________________

Ach ja und was ist das hier ohne name http://www.openstreetmap.org/relation/62433 ?

AndiG88 wrote:

Was mich dann zu meiner nächsten Frage führen würde: http://www.openstreetmap.org/relation/3672639 🙄

sehe ich kein Problem. Wer Ortsgrenzen haben will, muß sowieso immer auf boundary=administrative abfragen und somit stören solche Bezirke (mich) nicht.

Ach ja und was ist das hier ohne name http://www.openstreetmap.org/relation/62433 ?

- uralt #62433
- defekt (1 way fehlt)
- deckungsgleich mit dem Kreis Ostholstein

stammt wahrscheinlich aus der Zeit wo der Kreis eventuell noch etwas Ostsee mit drin hatte.

--> also weg

Gruss
walter

wambacher wrote:

AndiG88 wrote:

Ach ja und was ist das hier ohne name http://www.openstreetmap.org/relation/62433 ?

- uralt #62433
- defekt (1 way fehlt)
- deckungsgleich mit dem Kreis Ostholstein

stammt wahrscheinlich aus der Zeit wo der Kreis eventuell noch etwas Ostsee mit drin hatte.

--> also weg

Wartet mal damit. Will nochmal schauen, was damit los ist und ob es schon Ersatz gibt.

Ich habe die Relation 62433 repariert. Sie hat durchaus Berechtigung für die land_area. Eher ist die andere admin-Relation fehlerhaft, da die offizielle Grenze nicht immer mit der Küstenlinie identisch ist.

Mal eine Frage für lokale Kenner: Heißt die folgende Gemeinde in Schleswig-Holstein mit RS 010595987093 und OSM-ID 1149342 amtlich "Uelsby" oder "Ülsby"? DESTATIS sagt "Ülsby", Wikipedia und Homepage sagen nur "Uelsby". Vielleicht ein Übermittlungsfehler des stat. Landesamtes?

EDIT: Ein Blick in die Hauptsatzung verrät: "Uelsby (Kreis Schleswig-Flensburg)". Ob der Suffix offiziell, keine Ahnung... DESTATIS-Datum ist also falsch!

Blöd, dass man sich auf amtliche Daten nicht verlassen kann. 🙁

Habe ein paar Länder bzgl. offiz. Flächenabweichung der Gemeinden aktualisiert. Vielleicht möchte ja jemand ein paar Brocken abtragen (in NRW gibts ja z.B. gute Quellen).

Übersicht: https://wiki.openstreetmap.org/wiki/DE: … u_DESTATIS

also ich mach hauptsächlich die in niedersachsen. weißt du vielleicht ob die aktuellen destatis daten diese grenzbegradigung, zwischen niedersachsen und meckpomm, schon beachtet? http://www.niedersachsen.de/download/85 … _75-88.pdf Seite 81 ff

Chenshi wrote:

also ich mach hauptsächlich die in niedersachsen. weißt du vielleicht ob die aktuellen destatis daten diese grenzbegradigung, zwischen niedersachsen und meckpomm, schon beachtet?

Dornum habe ich übrigens schon angefasst. Die DESTATIS-Grunddaten sind, glaube ich, von 2012 und werden bei Gebietsänderungen (Abgang/Zugang) umgerechnet. Ich glaube nicht, dass diese Grenzbegradigung bereits drin ist. Man müsste mal die aktuelle Änderungsliste anschauen.

Nachtrag: Es handelt sich wohl um die Gemeinden Amt Neuhaus und Vielank. Dazu steht zu 2013/2014 nichts bei DESTATIS.

Scheint aber wirklich nur marginal zu sein. DESTATIS wird vermutlich im Juni nachziehen.

Hallo in die Runde,

könnte einer der erfahrenen Admin-Grenzen-Pfleger mal hier http://www.openstreetmap.org/#map=17/50.80835/10.62655 nachsehen ob ich diese "Insel" richtig gemappt habe ?

Es handelt sich um eine vom eigentlichen Gemeindegebiet von Tambach-Dietharz losgelöste Flur in der Nachbargemeinde.
Ich bin auf dieses Stück gestoßen weil mir immer die Straße "Hesserod" in Tambach-Dietharz in der Auswertung von regio-osm.de gefehlt hat und habe dann entsprechend gesucht.
Wäre alles nicht so schlimm wenn dort nicht ein Haus mit einer Adresse von Tambach-Dietharz in Georgenthal stehen würde.

Solche "Inseln" gibt es in Thüringen einige und die verlängern natürlich auch die Grenzen zwischen den Gemeinden.

MfG

Senni

sennewald63 wrote:

könnte einer der erfahrenen Admin-Grenzen-Pfleger mal hier http://www.openstreetmap.org/#map=17/50.80835/10.62655 nachsehen ob ich diese "Insel" richtig gemappt habe?

Alle Memberships sind als "outer" gekennzeichnet. Das kann bei einer Exklave nicht stimmen. Außerdem fehlt noch das Tagging des Grenzweges.
Habe es gleich angepasst. Vielen Dank für das Aufspüren und Eintragen!

Gehrke wrote:

Alle Memberships sind als "outer" gekennzeichnet. Das kann bei einer Exklave nicht stimmen.

Da diese beiden Sätze ja so nicht richtig zusammenpassen - eine Exklave wird schon korrekt mit "outer" angegeben - musste ich glatt mal nachschauen, ob Du nicht doch die Enklave korrekt zu inner korrigiert hast.

Gruß
Georg

GeorgFausB wrote:

Gehrke wrote:

Alle Memberships sind als "outer" gekennzeichnet. Das kann bei einer Exklave nicht stimmen.

Da diese beiden Sätze ja so nicht richtig zusammenpassen - eine Exklave wird schon korrekt mit "outer" angegeben - musste ich glatt mal nachschauen, ob Du nicht doch die Enklave korrekt zu inner korrigiert hast.

Sie sind zumindest etwas mißverständlich. Mit "Alle Memberships" meinte ich alle Relationen für das Grenzsegment. Wenn es eine Exklave (und damit auch eine Enklave) abgrenzt, kann es nicht nur Relationen mit "outer" (wie für die Exklave) geben, sondern auch Relationen mit "inner" (für Enklaven).

Die heutigen Gebietsänderungen in MeckPomm habe ich durchgeführt. Siehe Beitrag: http://forum.openstreetmap.org/viewtopi … 61#p423561

Es gab eine Änderung des Regionalschlüssels des Gem.verbandes Unterspreewald (ohne mir erkennbaren Grund) und daher auch aller zugehörigen Gemeinden. Habe das eben in OSM aktualisiert.

Gehrke wrote:

Es gab eine Änderung des Regionalschlüssels des Gem.verbandes Unterspreewald (ohne mir erkennbaren Grund) und daher auch aller zugehörigen Gemeinden. Habe das eben in OSM aktualisiert.

ich denke mal, wegen der Verschmelzung mit dem Amt Golßen, die vor nicht allzulanger Zeit stattfand. Sven

streckenkundler wrote:

Gehrke wrote:

Es gab eine Änderung des Regionalschlüssels des Gem.verbandes Unterspreewald (ohne mir erkennbaren Grund) und daher auch aller zugehörigen Gemeinden. Habe das eben in OSM aktualisiert.

ich denke mal, wegen der Verschmelzung mit dem Amt Golßen, die vor nicht allzulanger Zeit stattfand. Sven

Ah okay, üblicherweise wird dann aber doch gleich der Schlüssel geändert. Juristisch wirksam ist der Schlüssel auch schon seit 1.1.2014, bekannt und statistisch wirksam erst seit gestern. Vielleicht einfach vergessen zu melden?

In Offenburg, Willstädt, Schutterwald (BaWü) sind viele Grenze verschwunden und die Polygone entsprechend kaputt. Es gab da schon einen Revert, der aber wohl nur ein Problem zwischen Kehl und Willstädt beheben wollte.
Kann da mal jemand aus der Ecke für Ordnung sorgen, bitte? Es ist schwer für mich, einen Überblick über die Situation zu bekommen.

Gehrke wrote:

In Offenburg, Willstädt, Schutterwald (BaWü) sind viele Grenze verschwunden und die Polygone entsprechend kaputt.

Schutterwald habe ich inzwischen manuell durch eine neue LGL-Grenzlinie gefixt.

Habs doch selbst gemacht...

@Gehrke kannst du bitte nochmal die Flächenabweichungen zu DESTATIS aktualisieren bzw. nur niedersachsen.

Chenshi wrote:

@Gehrke kannst du bitte nochmal die Flächenabweichungen zu DESTATIS aktualisieren bzw. nur niedersachsen.

Für Niedersachsen habe ich neue Zahlen hochgeladen. Der erste Eintrag (Barsinghausen) ist ein Sonderfall, da das Polygon bis eben defekt war.

Oops, Kreis Recklinghausen ist weg. Werd ich wohl verbrochen haben 🙁

wird sofort gefixt.

Gruss
walter

Edit: User gehrke war schneller 🙁

Habe für alle "alten Bundesländer" ohne Bayern (weil Extrawurst bei Gemeindedaten) die Flächenabweichungen aktualisiert:

https://wiki.openstreetmap.org/wiki/DE: … u_DESTATIS

Auf github wird momentan über die Darstellung der Grenzen auf der osm.org Standardkarte diskutiert. Möglicherweise interessiert das ja den ein oder anderen der Grenzspezialisten hier 😉

Topic 1: Admin-Grenzen sollen nicht mehr angezeigt werden: https://github.com/gravitystorm/openstr … issues/619
Topic 2: Admin-Grenzen sollen prominenter und früher angezeigt werden: https://github.com/gravitystorm/openstr … issues/622
Topic 3: Maritime Grenzen sollen nicht mehr oder weniger prominent angezeigt werden: https://github.com/gravitystorm/openstr … issues/621

sinnvoller wäre es das man die grenzen weg und zu klicken kann

Chenshi wrote:

sinnvoller wäre es das man die grenzen weg und zu klicken kann

Eine layer-orientierte Karte/Anzeige hätte so manche Vorteile. Mehr und mehr entsteht sonst ein Wuselbild.

In Schleswig-Holstein zerstört ein Mapper Grenzrelationen, indem er einfach eine Linie um die Gemeinden zieht und die relation dann löscht oder deren Elemente entfernt.
Ich habe ihn/sie angeschrieben und werde mal schauen, was man retten kann.

Führt das dazu, wenn man sagt MPs seien böse und stets zu vermeiden?

Gehrke wrote:

In Schleswig-Holstein zerstört ein Mapper Grenzrelationen, indem er einfach eine Linie um die Gemeinden zieht und die relation dann löscht oder deren Elemente entfernt.
Ich habe ihn/sie angeschrieben und werde mal schauen, was man retten kann.

So. Habe das Gröbste wohl gefixt.

Ein wirkliches Gutes hatte diese Tortur: ich habe die fehlende PLZ 25946 Amrum (3 Gemeinden) entdeckt! keine Ahnung, wo die sich versteckt hattw.

Gehrke wrote:

Führt das dazu, wenn man sagt MPs seien böse und stets zu vermeiden?

Jo, glaube ich auch.

Wenn man es aber ganz genau betrachtet (und es alle Mapper auf der Welt so machen würden!) könnte man Grenzen auch so erfassen.
Als einfache Fläche, falls kein "Loch" und nur dann als MP, wenn "gelöchert". Das hätte uns viel Arbeit und Ärger erspart.

Ich erhoffe so eine Definition in dem 0.7-er Schema (Area), aber das kann noch lange dauern.

Gruss
walter

ps: Nein, das ist keine Socke von mir 😉

wambacher wrote:

Wenn man es aber ganz genau betrachtet (und es alle Mapper auf der Welt so machen würden!) könnte man Grenzen auch so erfassen.
Als einfache Fläche, falls kein "Loch" und nur dann als MP, wenn "gelöchert". Das hätte uns viel Arbeit und Ärger erspart.

Das halte ich bei Grenzen für grundfalsch, ob mit Area-Modell oder ohne.
Eine Grenze zwischen zwei Gebieten sollte auch eine Grenze sein (und nicht 2 oder 100, wenn man PLZ, Kreis etc. auch noch extra hat).
Man sollte das klar definieren und erkennen können (nein, ohne Vergleich aller Wegpunkte).

wambacher wrote:

Gehrke wrote:

Führt das dazu, wenn man sagt MPs seien böse und stets zu vermeiden?

Jo, glaube ich auch.

Wenn man es aber ganz genau betrachtet (und es alle Mapper auf der Welt so machen würden!) könnte man Grenzen auch so erfassen.
Als einfache Fläche, falls kein "Loch" und nur dann als MP, wenn "gelöchert". Das hätte uns viel Arbeit und Ärger erspart.

Ich erhoffe so eine Definition in dem 0.7-er Schema (Area), aber das kann noch lange dauern.

Gruss
walter

ps: Nein, das ist keine Socke von mir 😉

Und wie willst du das ganze dann bearbeiten? Ich höre schon die Fraktion schreien die Landuse nicht an Straßen haben will. Und jetzt schlägst du vor von Gemeinde bis Staatsgrenze alles über einander auf den gleichen Weg zu legen? WOW!

Gehrke wrote:

Das halte bei Grenzen für grundfalsch, ob mit Area-Modell oder ohne.
Eine Grenze zwischen zwei Gebieten sollte auch eine Grenze sein (und nicht 2 oder 100, wenn man PLZ, Kreis etc. auch noch extra hat).
Man sollte das klar definieren und erkennen können (nein, ohne Vergleich aller Wegpunkte).

Und womit arbeiten wir in der Realität? Mit den Flächen, die durch die Grenzen - wie auch immer - definiert werden.

Die Grenze zwischen 2 Städten interessiert mich überhaupt nicht; die ist mMn zum Rendern und zu sonst nix nütze. Ich brauche die Fläche um entscheiden zu können, welches Objekt wo (Land, Ort, Acker, ...) liegt.

Gruss
walter

ps: ist aber alles graue Theorie. Sieh mal zu, dass du den Mapper da oben überzeugst, sich an den Standard zu halten. Und ich träume weiter von API-0.7 😉

wambacher wrote:

Und womit arbeiten wir in der Realität? Mit den Flächen, die durch die Grenzen - wie auch immer - definiert werden.

Wenn man für zwei angrenzende Gebiete unterschiedliche Linienzüge als Grundlage hat, befördert man, dass z.B. unbemerkt Lücken beim Bearbeiten der Wegpunkte entstehen.
Ich interessiere mich auch sehrwohl für die einzelnen Grenzen. Zum einen, weil ich aus verschiedenen Gründen (insbesondere Qualitätssicherung) die Polygone selbst erzeuge und analysiere, zum anderen weil man andernfalls Grenzen nicht einheitlich approximieren kann. Das heißt benachbarte approximierte Grenzen könnten sich z.B. überschneiden oder Lücken entstehen.

Wie fast immer hat beides Vor- und Nachteile:
Bei Grenzen als Relation muss man sich die Umrandung der Fläche aus den Mitgliedern der Relation zusammenklauben. Es ist auch (leider) sehr viel einfacher, eine Relation nicht zusammenhängend zu machen.
Bei Grenzen als area bekommt man sehr viele Redundanzen (übereinanderliegende Linien), die ja auch nicht unproblematisch sind. Sehr praktikabel wäre es mMn auch nicht: Eine neue Grenze (z.B. eine Verwaltungsgemeinschaft) zöge eine stundenlange "Folgen"-Sitzung nach sich, wenn die Gemeindegrenzen sehr genau erfasst sind. Bei Relationen muss man nur wenige Grenzsegmente einfügen. Nicht überall kann man halt fertige Shapes importieren.

Hi,
sehe gerade im OSMI dass im Bereich Marl/Recklinghausen alles "rot" ist.
Wird da gerade was gebastelt an den admin Relationen?
Grüße
Chris

chris66 wrote:

Hi,
sehe gerade im OSMI dass im Bereich Marl/Recklinghausen alles "rot" ist.
Wird da gerade was gebastelt an den admin Relationen?
Grüße
Chris

Jo, bin ich dran. aber das sollte eigentlich ok sein und der OSMI hinkt eventuell hinterher. Meine Boundaries-Karte ist damit aber hochzufrieden. ich prüfe das nochmal.

Gruss
walter

jo, das sind diese blöden Wahlkreise, da hat es leichte Kolateralschäden gegeben. Ich hab den Mapper mal angeschrieben, der die erfasst hat und er meint, daß er die unbedingt braucht.

ich fix die dennoch mal.

Data von 19.6.2014. Also ist der recht aktuell.

war halb so schlimm, sollte jetzt ok sein. Kritische Grenzen (admin/plz) waren eh nicht betroffen. Nur diese blöden Wahlkreise.

Gruss
walter

wambacher wrote:

war halb so schlimm, sollte jetzt ok sein. Kritische Grenzen (admin/plz) waren eh nicht betroffen. Nur diese blöden Wahlkreise.

Würde man die als "abstrakte" Relationen ohne Wege, sondern nur mit Gemeinden/Ortsteilen als "part"-Member abbilden würden sie keinen stören...

Aber dann können die meisten Leute ja wieder nicht damit arbeiten...

Die Stadtbezirke Leipzigs sollten jetzt erstmals drin und komplett sein. Man konnte das weitgehend aus den TMC-Areas dort übernehmen.

Ich habe mich in letzter Zeit mit der Qualität von Grenzgeometrien beschäftigen müssen. Hierbei sieht man immer wieder, wie unterschiedlich die Qualität der Wegsegmente ist. Das reicht von sehr groben Vermutungen (teils nur eine Verbindungslinie quer durch die Landschaft) bis zu wirklich exakten Imports mit ganz offiziellen Koordinaten. Wie gut die Grenze ist, muss man aber meist raten. Selbst Quellenangaben wie "LGL" in BaWü sagen ja nicht, ob es abgemalt wurde oder exakt importiert. Wenn es abgemalt wurde, kann es gut abgemalt oder auch schlampig/grob abgemalt sein.

Mein Gedanke hierzu: Man sollte einen Qualitäts-Tag für Grenzsegemente haben, der Werte mit recht eindeutiger Semantik hat. Die Qualitätsstufen stelle ich mir z.B. so vor:

official (aus Import), very_good/excellent (sehr genauer Trace der offiziellen Grenze; alle Punkte da, aber evtl. nicht 100% genau), good (ordentlicher Trace ö.ä. der Grenze, evtl. auch nur einer Generalisierung davon; evtl. fehlen auch ein paar Punkte oder kleiner Areale liegen im falschen Gebiet), approximate (gute Schätzung anhand offizieller Informationen, Details liegen teils daneben), rough (grobe Schätzung, Ortschaften sind aber richtig zugeordnet), very_rough (sehr grobe Schätzung; evtl. sind größere Flächen, einige Häuser bis ganze Ortschaften nicht im richtigen Gebiet).

Es könnte zur besseren Differenzierung bzgl. "source" auch besser sein, die Art der Datenübernahme zu taggen, z.B. "source:transfer=*" mit Werten wie "import", "trace", "memory".

Gehrke wrote:

Mein Gedanke hierzu: Man sollte einen Qualitäts-Tag für Grenzsegemente haben, der Werte mit recht eindeutiger Semantik hat.

Sorry Jan, aber mit solchen Feinheiten möchte ich mich wirklich nicht herumschlagen.

Gut, ich hab da eine Ecke (kompletter Kreis Recklinghausen), wo ich sowas wie "exact import" dranschreiben könnte, aber die anderen 99,99% mag ich nicht beurteilen. Und erst recht nicht im Nachherein.

Da versuche ich es lieber, den Rest der Welt ein wenig besser zu machen - da bringt es OSM wohl mehr.

Gruss
walter

ps: Freiwillige vor - 'mer beissen nicht.

wambacher wrote:

mit solchen Feinheiten möchte ich mich wirklich nicht herumschlagen.

Gut, ich hab da eine Ecke (kompletter Kreis Recklinghausen), wo ich sowas wie "exact import" dranschreiben könnte, aber die anderen 99,99% mag ich nicht beurteilen

Musst Du ja auch nicht. Aber Du willst ja auch nicht, dass jemand anhand approximierter Grenzen Deine Arbeit wieder kaputt macht, nur weil er denkt, seine Informationen wären besser. Ich glaube, in den Niederlanden habe ich mal einen Tag mit dem Wert "official" gesehen. Wäre ein Anfang.

EDIT: Tag dort ist "authoritative=yes"

Ich würde dann noch vorschlagen "source:transfer=import".

Gehrke wrote:

official (aus Import)

Der Teufel steckt im Detail: Auch die "offiziellen" Grenzshapes sind mehr oder weniger generalisiert. Man kann das grob am Abstand der Stützpunkte abschätzen. Ich kenne LGL-Grenzlinien, die liegen nach Kataster mehr als 10 m daneben, woanders gehen sie fast auf den Zentimeter genau durch einen Reihenhausblock.
Unter diesem Gesichtspunkt ist mir source:transfer als Tag zu inflationär. Ein Zusatz im Changeset-Kommentar sollte reichen.

seichter wrote:

Gehrke wrote:

official (aus Import)

Der Teufel steckt im Detail: Auch die "offiziellen" Grenzshapes sind mehr oder weniger generalisiert. Man kann das grob am Abstand der Stützpunkte abschätzen. Ich kenne LGL-Grenzlinien, die liegen nach Kataster mehr als 10 m daneben, woanders gehen sie fast auf den Zentimeter genau durch einen Reihenhausblock.

Dass die LGL-Linien um ca. 10 m falsch sein können, ist neu für mich. Gibt es überhaupt irgendwo vernünftige Grenzdaten?
Mit den Haltepunkten ist das so eine Sache bzw. mir ein Rätsel. Nakaner hat für NRW den WMS für Gemarkungen/Fluren als genau empfohlen. Die "generalisierten" Grenzlinien anderer WMS-Layer in NRW sind teils "genauer" i.S.v. mit mehr Haltepunkten und mehr Kurven statt Ecken. Die waren aber offenbar nicht besser, sondern eher mit künstlerischer Freiheit gestaltet.

seichter wrote:

Unter diesem Gesichtspunkt ist mir source:transfer als Tag zu inflationär. Ein Zusatz im Changeset-Kommentar sollte reichen.

Changeset-Kommentare liest leider kaum einer, der Änderungen vornimmt. Ich finde "source:transfer" trotzdem gut für Imports. Welche Daten importiert wurden, müsste über "source" bestimmt werden. Aber offenbar heißt "Import" nicht, dass die Daten auch super sind... 🙁

Das Hauptproblem neben teils sehr schlechten Grenzdaten in OSM ist, dass

1. Jeder Mapper Grenzen verschlimmbessern oder gar zerstören kann
2. Die Landesämter trotz OpenData-Wortblasen die Daten nicht rausrücken (oder die falschen)
3. Die Landesämter die abschreckende OSM-Lizenz nicht mögen

Was soll ich jetzt für mich daraus schließen? Vielleicht mache ich mir lieber eine eigene Grenzdatenbank.
Dann muss ich mich auch nicht mehr täglich mit zerschossenen Grenzen rumärgern. 🙁

Gehrke wrote:

Gibt es überhaupt irgendwo vernünftige Grenzdaten?

die mir bekannten einzig nicht generalisierten Grenten sind die, die aus der ALK / ALKIS entstehen. Am besten aus einem ALK-Shape (Flurstücke) oder so selbst bauen. Die sind nicht generalisiert. Aber auch hier muß man sich gewiss sein, daß sich mit die Grenzen durch Lageverbesserung, Neuvermessung ect. jederzeit ändern können.

Sven

streckenkundler wrote:

Gehrke wrote:

Gibt es überhaupt irgendwo vernünftige Grenzdaten?

die mir bekannten einzig nicht generalisierten Grenten sind die, die aus der ALK / ALKIS entstehen. Am besten aus einem ALK-Shape (Flurstücke) oder so selbst bauen. Die sind nicht generalisiert. Aber auch hier muß man sich gewiss sein, daß sich mit die Grenzen durch Lageverbesserung, Neuvermessung ect. jederzeit ändern können.

Das Problem (nicht nur in der Gegend hier) dürfte sein, dass man digitale ALK-Shapes nicht oder nur gegen Gebühr bekommt und dann die Lizenz eine Verwendung für OSM nicht zulassen würde. Daran wird sich auch nicht so schnell etwas ändern, da sich die Vermessungsämter über diese Gebühren zum Teil refinanzieren.

Was zahlt man denn so für digitale ALK-Shapes eines Bundeslandes wie BaWü? oder für ganz Deutschland?

Gehrke wrote:

Was zahlt man denn so für digitale ALK-Shapes eines Bundeslandes wie BaWü? oder für ganz Deutschland?

Beim LGB Brandenburg für Brandenburg: 50 k€ für Flurstücke, 40 k€ Gebäude.

Sven

streckenkundler wrote:

Gehrke wrote:

Was zahlt man denn so für digitale ALK-Shapes eines Bundeslandes wie BaWü? oder für ganz Deutschland?

Beim LGB Brandenburg für Brandenburg: 50 k€ für Flurstücke, 40 k€ Gebäude.

Danke für die schnelle Antwort. Nicht eben billig für öffentliche Daten. Aber es überrascht mich auch nicht.
Eigentlich würden mir Gemarkungen oder Gemeindegrenzen schon reichen. Keine Ahnung wie viele "Objekte" das dann wären.

Habe jetzt alle Regionalschlüssel angepasst (gefühlt über 100) und mit DESTATIS abgeglichen.

Guten Morgen,

könnte sich ein erfahrener Tagger mal die Grenzen von Mohlsdorf-Teichwolframsdorf in Thüringen ansehen ?

Im Rahmen meiner Straßennamenbereinigung in Thüringen habe ich festgestellt, dass der Grenzverlauf zwischen Mohlsdorf-Teichwolframsdorf und Berga/Elster nicht stimmt, da werden ganze Dörfer zu Berga/Elster geschlagen (Waltersdorf,Mühlberg,Rüßdorf).

MfG

Senni

sennewald63 wrote:

könnte sich ein erfahrener Tagger mal die Grenzen von Mohlsdorf-Teichwolframsdorf in Thüringen ansehen ? Senni

Es scheint da ja Anfang 2012 eine Eingemeindung / Fusion gegeben zu haben, oder? siehe http://de.wikipedia.org/wiki/Teichwolframsdorf

Hallo stephan75,

ja !
Der Gemeindezusammenschluß war zum 01.01.2012, siehe "Thüringer Gesetz zur freiwilligen Neugliederung kreisangehöriger Gemeinden im Jahr 2011" §5.
Leider stimmen wie schon beschrieben die Grenzen nicht, die Angaben in dem Wiki-Artikel stimmen mit dem Gesetz überein.

Die Grenzen der Stadt Berga/Elster haben sich dabei aber nicht geändert.
Es wurde nur per Gesetz geklärt, dass die neue Gemeinde Mohlsdorf-Teichwolframsdorf eine eigene Verwaltung aufbaut.

MfG

Senni

Hallo und Guten Morgen,

der Grund weshalb die Grenzen von Mohlsdorf-Teichwolframsdorf und anderen Gemeinden nicht stimmen liegt wohl daran, dass Ende 2012 in Thüringen
flächendeckend Gemeindegrenzen wegen Lizenzproblemen gelöscht wurden ( http://wiki.openstreetmap.org/wiki/Th%C … enzen_2012 ).

Die neu erfassten Grenzen wurden dann in einzelnen Regionen wohl mehr nach dem amerikanischen Prinzip eingezeichnet - "lang und gerade" 😎 .

MfG

Senni

sennewald63 wrote:

Die neu erfassten Grenzen wurden dann in einzelnen Regionen wohl mehr nach dem amerikanischen Prinzip eingezeichnet - "lang und gerade" 😎

"Lang und gerade" ist nicht das amerikanische Prinzip - zumindest bei den Grenzen.

Die machen das ganz anders:

"Drunter und drüber"

In Amiland sind an sehr vielen Stellen die Counties/Kreise (AL6 - pink) und die Cities (AL8 - rot) aus voneinander unabhängigen Datensätzen importiert worden. Dabei wurde natürlich nicht darauf geachtet, dass die gemeinsamen Grenzwege miteinander "verwoben" werden.

130% Pfusch.

Gruss
walter

wambacher wrote:

In Amiland sind an sehr vielen Stellen die Counties/Kreise (AL6 - pink) und die Cities (AL8 - rot) aus voneinander unabhängigen Datensätzen importiert worden. Dabei wurde natürlich nicht darauf geachtet, dass die gemeinsamen Grenzwege miteinander "verwoben" werden.

Keine amerikanische Spezialität. Vor einem Jahr habe ich das ähnlich in BaWü angetroffen.

sennewald63 wrote:

der Grund weshalb die Grenzen von Mohlsdorf-Teichwolframsdorf und anderen Gemeinden nicht stimmen liegt wohl daran, dass Ende 2012 in Thüringen
flächendeckend Gemeindegrenzen wegen Lizenzproblemen gelöscht wurden ( http://wiki.openstreetmap.org/wiki/Th%C … enzen_2012 ).

Schaue mir den Fall Mohlsdorf-Teichwolframsdorf (r1946738) gerade an. Mich würde aber auch interessieren, warum genau die "aus Wikipedia abgezeichneten" Gemeindegrenzen nicht ODbL-konform sein sollen. Dazu sagt der Wiki-Artikel leider nichts, obwohl man doch daraus lernen müsste.

Gehrke wrote:

Keine amerikanische Spezialität. Vor einem Jahr habe ich das ähnlich in BaWü angetroffen.

Das war aber technisch nicht anders machbar und wurde planmäßig nach und nach zu 100% beseitigt. In Amiland dagegen liegt das Zeug seit Jahren unverändert herum.

Gruss
walter

PS: Nee, ich fixe das nicht. Ich sorge nur dafür, dass die Grenzen in sich geschlossen sind, da es dort natürlich auch unachtsame Mapper gibt, die ab und zu etwas zerschießen. Und das auch nur, weil ich keine "Löcher" oder "Fehlfarben" in meiner Karte haben möchte 😉

Gehrke wrote:

sennewald63 wrote:

der Grund weshalb die Grenzen von Mohlsdorf-Teichwolframsdorf und anderen Gemeinden nicht stimmen liegt wohl daran, dass Ende 2012 in Thüringen
flächendeckend Gemeindegrenzen wegen Lizenzproblemen gelöscht wurden (http://wiki.openstreetmap.org/wiki/Th%C … enzen_2012 ).

Schaue mir den Fall Mohlsdorf-Teichwolframsdorf (r1946738) gerade an. Mich würde aber auch interessieren, warum genau die "aus Wikipedia abgezeichneten" Gemeindegrenzen nicht ODbL-konform sein sollen. Dazu sagt der Wiki-Artikel leider nichts, obwohl man doch daraus lernen müsste.

Ich habe jetzt Waltersdorf (mit den Weilern Rüßdorf und Mühlberg) wieder eingemeindet (und auch die PLZ-Grenze entspr. korrigiert). Mich lässt bei dieser Gemeinde schon wieder die Stirn runzeln, dass man 2 Gemeinden anscheinend willkürlich zusammenlegt, die nicht mal richtig per Straße verbunden sind. 🙄

Roter Alarm !!!!!!!!!!!

Relation␣|␣Country␣|␣␣␣␣␣␣␣␣␣␣␣␣␣Missing␣Boundary
----------+---------+-------------------------------------------
1379614␣|␣DEU␣␣␣␣␣|␣Mittelheim␣(9)
62428␣|␣DEU␣␣␣␣␣|␣Munich␣(6)
1379602␣|␣DEU␣␣␣␣␣|␣Oestrich␣(9)
452200␣|␣DEU␣␣␣␣␣|␣Schwalmstadt␣(8)
452219␣|␣DEU␣␣␣␣␣|␣Willingshausen␣(8)

Jemand hat u.A. aus München (6) eine Route gemacht! Oestrich & Mittelheim schau ich mir mal an, weil das bei mir um die Ecke liegt.

Gruss
walter

wambacher wrote:

Oestrich schau ich mir mal an, weil das bei mir um die Ecke liegt.

Jetzt war ich da auch (nicht hochgeladen). Way 95468917 muss wieder hergestellt werden. id-Mapper hat den gelöscht und vielleicht noch mehr (changeset 24125659).

EDIT: Willingshausen und Schwalmstadt sind gefixt (hat mal wieder Grenzen verschlimmbessert ohne richtig zu trennen und ohne zu prüfen)

Gehrke wrote:

wambacher wrote:

Oestrich schau ich mir mal an, weil das bei mir um die Ecke liegt.

Jetzt war ich da auch (nicht hochgeladen). Way 95468917 muss wieder hergestellt werden. id-Mapper hat den gelöscht und vielleicht noch mehr (changeset 24125659).

EDIT: Willingshausen und Schwalmstadt sind gefixt (hat mal wieder Grenzen verschlimmbessert ohne richtig zu trennen und ohne zu prüfen)

Oestrich & Mittelheim jetzt ok - hoffe ich zumindest 😉

Was hat der Typ in München sich wohl dabei gedacht? Newbie, erster Edit und dann noch "ausländischer" Username - Tourist?

Gruss
walter

wambacher wrote:

Was hat der Typ in München sich wohl dabei gedacht? Newbie, erster Edit und dann noch "ausländischer" Username - Tourist?

Hast Du München schon angepasst. ich müsste nur noch hochladen?

EDIT: Ist jetzt passiert.

Hallo,

danke das ihr euch das mal angesehen habt.
Ich hör schon meine Frau schümpfen, dass ich schon wieder mehr graue Haare bekommen habe. 🙂 🙂 🙂
In Ostthüringen sieht es grausam aus !
Da wurden anscheinend auch ganze Dörfer bei Gemeindezusammneschlüssen mit weg geputzt.
Ich tipp mir die Finger fasst wund beim erfassen von dem was alles laut regio-osm fehlt,
von dem was alles in meinem alten Schulatlas drin steht will ich erst gar nicht anfangen.
Es kann allerdings auch sein das dort noch nichts erfasst war, so manche Straße hat das Edit-Datum von 2008.

Ich putze die Straßen erst mal weiter.

Senni

Moin Moin,

ich habe diesen Block mal aus meiner - noch nicht ganz fertigen Auswertung der Internationalen Grenzen rausgezogen, da es hier nur um DEU geht:

Relation␣|␣Country␣|␣␣␣␣␣␣New␣Boundary␣␣␣␣␣␣␣|␣al␣|␣de:amtlicher_gemeindeschluessel
----------+---------+-------------------------+----+---------------------------------
2012699␣|␣DEU␣␣␣␣␣|␣Barsinghausen␣(8)␣␣␣␣␣␣␣|␣8␣␣|␣03241002
2012665␣|␣DEU␣␣␣␣␣|␣Wennigsen␣(Deister)␣(8)␣|␣8␣␣|␣03241020
3901149␣|␣DEU␣␣␣␣␣|␣Eschborn␣(9)␣␣␣␣␣␣␣␣␣␣␣␣|␣9␣␣|
3901135␣|␣DEU␣␣␣␣␣|␣Kronberg␣im␣Taunus␣(9)␣␣|␣9␣␣|
3901150␣|␣DEU␣␣␣␣␣|␣Mammolshain␣(9)␣␣␣␣␣␣␣␣␣|␣9␣␣|
3901151␣|␣DEU␣␣␣␣␣|␣Niederhöchstadt␣(9)␣␣␣␣␣|␣9␣␣|
3901136␣|␣DEU␣␣␣␣␣|␣Oberhöchstadt␣(9)␣␣␣␣␣␣␣|␣9␣␣|
3901137␣|␣DEU␣␣␣␣␣|␣Schönberg␣(9)␣␣␣␣␣␣␣␣␣␣␣|␣9␣␣|
3901138␣|␣DEU␣␣␣␣␣|␣Stierstadt␣(9)␣␣␣␣␣␣␣␣␣␣|␣9␣␣|
3900539␣|␣DEU␣␣␣␣␣|␣Beckeln␣(10)␣␣␣␣␣␣␣␣␣␣␣␣|␣10␣|
3901188␣|␣DEU␣␣␣␣␣|␣Eitzendorf␣(10)␣␣␣␣␣␣␣␣␣|␣10␣|
3900540␣|␣DEU␣␣␣␣␣|␣Groß␣Köhren␣(10)␣␣␣␣␣␣␣␣|␣10␣|
3901189␣|␣DEU␣␣␣␣␣|␣Heesen␣(10)␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10␣|
3901190␣|␣DEU␣␣␣␣␣|␣Hilgermissen␣(10)␣␣␣␣␣␣␣|␣10␣|
3900541␣|␣DEU␣␣␣␣␣|␣Horstedt␣(10)␣␣␣␣␣␣␣␣␣␣␣|␣10␣|
3901191␣|␣DEU␣␣␣␣␣|␣Kirchseelte␣(10)␣␣␣␣␣␣␣␣|␣10␣|
3900542␣|␣DEU␣␣␣␣␣|␣Klein␣Henstedt␣(10)␣␣␣␣␣|␣10␣|
3900543␣|␣DEU␣␣␣␣␣|␣Klein␣Köhren␣(10)␣␣␣␣␣␣␣|␣10␣|
3901192␣|␣DEU␣␣␣␣␣|␣Klosterseelte␣(10)␣␣␣␣␣␣|␣10␣|
3901193␣|␣DEU␣␣␣␣␣|␣Magelsen␣(10)␣␣␣␣␣␣␣␣␣␣␣|␣10␣|
3901194␣|␣DEU␣␣␣␣␣|␣Mehringen␣(10)␣␣␣␣␣␣␣␣␣␣|␣10␣|
3900544␣|␣DEU␣␣␣␣␣|␣Prinzhöfte␣(10)␣␣␣␣␣␣␣␣␣|␣10␣|
3900545␣|␣DEU␣␣␣␣␣|␣Reckum␣(10)␣␣␣␣␣␣␣␣␣␣␣␣␣|␣10␣|
3901195␣|␣DEU␣␣␣␣␣|␣Ubbendorf␣(10)␣␣␣␣␣␣␣␣␣␣|␣10␣|
3901196␣|␣DEU␣␣␣␣␣|␣Wechold␣(10)␣␣␣␣␣␣␣␣␣␣␣␣|␣10␣|
3901197␣|␣DEU␣␣␣␣␣|␣Wienbergen␣(10)␣␣␣␣␣␣␣␣␣|␣10␣|
3900546␣|␣DEU␣␣␣␣␣|␣Winkelsett␣(10)␣␣␣␣␣␣␣␣␣|␣10␣|
(27␣rows)

ok, viele neue AL10 - da war wohl jemand ganz fleissig 🙂

Nur: Was sollen die neuen AL9 ohne Gemeindeschlüssel?

Ich habe das "neue" https://www.openstreetmap.org/relation/3901135 Kronberg im Taunus mal geprüft und die Rel ist absolut deckungsgleich mit der mMn korrekten AL8 https://www.openstreetmap.org/relation/418112

Was geht da ab?

Gruss
walter

wambacher wrote:

Nur: Was sollen die neuen AL9 ohne Gemeindeschlüssel?

AL9 haben keinen Gemeindeschlüssel. Deckungsgleich sollte aber natürlich auch keine mit AL8 sein.

wambacher wrote:

Ich habe das "neue" https://www.openstreetmap.org/relation/3901135 Kronberg im Taunus mal geprüft und die Rel ist absolut deckungsgleich mit der mMn korrekten AL8 https://www.openstreetmap.org/relation/418112

Ich sehe da (jetzt) deutliche Unterschiede.

Gehrke wrote:

Ich sehe da (jetzt) deutliche Unterschiede.

jau ei,

hab al9 mit al7 verwechselt - Kronberg (9) ist natürlich ein Teil von Kronberg (8) und damit völlig in Ordnung. Die anderen wohl auch.

Gruss
walter

ps: Ich hab mir schon eine Ecke zum Schämen ausgesucht - meld mich wieder, wenn ich wach bin. 😉

Moi Moin,

das hat sich getan:

Relation␣|␣Country␣|␣␣␣␣␣␣␣New␣Boundary
----------+---------+---------------------------
535248␣|␣DEU␣␣␣␣␣|␣Belgern␣(9)
1250500␣|␣DEU␣␣␣␣␣|␣Freckenfeld␣(8)
62698␣|␣DEU␣␣␣␣␣|␣Landkreis␣Germersheim␣(6)
(3␣rows)

Relation␣|␣Country␣|␣␣␣␣Missing␣Boundary
----------+---------+------------------------
903983␣|␣DEU␣␣␣␣␣|␣Dahner␣Felsenland␣(7)␣␣␣␣␣␣␣␣␣␣␣done
1251116␣|␣DEU␣␣␣␣␣|␣Fischbach␣bei␣Dahn␣(8)␣␣␣␣␣␣␣␣␣␣done
51676␣|␣DEU␣␣␣␣␣|␣Hamburg␣Neuwerk␣(10)
1251149␣|␣DEU␣␣␣␣␣|␣Lemberg␣(8)␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣done
903980␣|␣DEU␣␣␣␣␣|␣Pirmasens-Land␣(7)␣␣␣␣␣␣␣␣␣␣␣␣␣␣done
(5␣rows)

Gruss
walter

Edit: Im Wattenmeer (Hamburg Neuwerk) haben wir ja fast "amerikanische Verhältnisse":

4 (oder 5?) Administrative und PLZ-Grenzen an einem Fleck. Sorry, aber da mag ich nicht aufräumen. Im Mapnik sieht das ja noch harmlos aus:
https://www.openstreetmap.org/#map=16/5 … 0&layers=N

wambacher wrote:

Edit: Im Wattenmeer (Hamburg Neuwerk) haben wir ja fast "amerikanische Verhältnisse":

https://osm.wno-edv-service.de/DataServer/osm/forum/tn_wattenmeer1.png

4 (oder 5?) Administrative und PLZ-Grenzen an einem Fleck. Sorry, aber da mag ich nicht aufräumen. Im Mapnik sieht das ja noch harmlos aus:
https://www.openstreetmap.org/#map=16/5 … 0&layers=N

Mache das mal.

Gehrke wrote:

Mache das mal.

Und was ist mit demjenigen, der da gerade "rumgeschraubt" hat? Schließlich ist die Ecke nicht von selber kaputt gegangen.

Hab aber net nachgesehen, wer das war, weil ich derzeit Fools 1.2 fertig kriegen will/muß.

Gruss
walter

wambacher wrote:

Gehrke wrote:

Mache das mal.

Und was ist mit demjenigen, der da gerade "rumgeschraubt" hat? Schließlich ist die Ecke nicht von selber kaputt gegangen.

Ich will es nicht wissen. Muss noch zig andere Grenzen von OSM-User-Aktionen korrigieren. Wenn ich da immer nach Verursachern gucke und sogar PNs schreibe, komme ich zu gar nichts mehr.
Meistens hilft es eh nicht. 🙁

Gehrke wrote:

Ich will es nicht wissen. Muss noch zig andere Grenzen von OSM-User-Aktionen korrigieren. Wenn ich da immer nach Verursachern gucke und sogar PNs schreibe, komme ich zu gar nichts mehr.
Meistens hilft es eh nicht. 🙁

schau'n mer mal. gerade läuft eine Irrläufer-Auswertung für Meck-Pomm und da hab ich ein wenig Zeit.

Gruss
walter

wambacher wrote:

Gehrke wrote:

Ich will es nicht wissen. Muss noch zig andere Grenzen von OSM-User-Aktionen korrigieren. Wenn ich da immer nach Verursachern gucke und sogar PNs schreibe, komme ich zu gar nichts mehr.
Meistens hilft es eh nicht. 🙁

schau'n mer mal. gerade läuft eine Irrläufer-Auswertung für Meck-Pomm und da hab ich ein wenig Zeit.

Man sollte noch dazu sagen, dass es davor tatsächlich Korrekturbedarf gab (ist jetzt hochgeladen). Die Bundeslandgrenzen war teils recht deutlich daneben. Leider wurde das von dem anderen User nicht vernünftig korrigiert.

Gehrke wrote:

Man sollte noch dazu sagen, dass es davor tatsächlich Korrekturbedarf gab (ist jetzt hochgeladen). Die Bundeslandgrenzen war teils recht deutlich daneben. Leider wurde das von dem anderen User nicht vernünftig korrigiert.

Dann schau mal hier: http://forum.openstreetmap.org/viewtopi … 78#p438778

Hamburg Neuwerk (10) als missing und nicht korrigiert. Das war die Ursache für den Post.

Ich sehe da jetzt noch eine Coastline mit 1x PLZ und knapp daneben eine AL4 mit den anderen Daten. wenn das ok für dich ist und du 100% fertig bist, würde ich das jetzt gerne bereinigen.

Gruss
walter

wambacher wrote:

Hamburg Neuwerk (10) als missing und nicht korrigiert. Das war die Ursache für den Post.

Ich sehe da jetzt noch eine Coastline mit 1x PLZ und knapp daneben eine AL4 mit den anderen Daten. wenn das ok für dich ist und du 100% fertig bist, würde ich das jetzt gerne bereinigen.

Bei mir sieht Neuwerk richtig aus.
Die PLZ läuft entlang der Coastline. Das fände ich in Ordnung. Ist bisher nicht eindeutig geklärt, was da richtiger/besser ist (dagegen spricht, das die CUX-PLZ jetzt auch in HH liegt)
Coastline und admin sind auf jeden Fall nicht identisch.

Gehrke wrote:

Bei mir sieht Neuwerk richtig aus.

jetzt ja. danke.

Die PLZ läuft entlang der Coastline. Das fände ich in Ordnung. Ist bisher nicht eindeutig geklärt, was das richtiger/besser ist.

Für mich sollten PLZ-Grenzen und ADM-Grenzen gleich sein, solange die nicht Post-bedingt getrennt verlaufen. Was mich halt stört, ist daß die hier einige Meter nebeneinander verlaufen und sich dauernd kreuzen.

5 Minuten Arbeit und das ist "sauber". ok?

Gruss
walter

wambacher wrote:

5 Minuten Arbeit und das ist "sauber". ok?

Ok. Bahn frei für Walter! (bitte JOSM-Daten noch aktualisieren)

Ein bisschen kompliziert ist leider noch, dass hamburgs Grenzen (und das ist tatsächlich so!) die CUX-Küste überlappen. Das kann ich aber später noch fixen.

Gehrke wrote:

wambacher wrote:

5 Minuten Arbeit und das ist "sauber". ok?

Ok. Bahn frei für Walter! (bitte JOSM-Daten noch aktualisieren)

Ein bisschen kompliziert ist leider noch, dass hamburgs Grenzen (und das ist tatsächlich so!) die CUX-Küste überlappen. Das kann ich aber später noch fixen.

ok, bin durch - der südliche Zipfel ist immer noch äußerst "unschön", aber wenn das wirklich so sein sollte, kann ich auch nix machen.

Gruss
walter

wambacher wrote:

Gehrke wrote:

wambacher wrote:

5 Minuten Arbeit und das ist "sauber". ok?

Ok. Bahn frei für Walter! (bitte JOSM-Daten noch aktualisieren)

Ein bisschen kompliziert ist leider noch, dass hamburgs Grenzen (und das ist tatsächlich so!) die CUX-Küste überlappen. Das kann ich aber später noch fixen.

ok, bin durch - der südliche Zipfel ist immer noch äußerst "unschön", aber wenn das wirklich so sein sollte, kann ich auch nix machen.

Gruss
walter

hier kann man den südlichen Zipfel ungefähr erahnen: http://www.nds-voris.de/jportal/docs/an … 6/file.jpg

4rch wrote:

hier kann man den südlichen Zipfel ungefähr erahnen: http://www.nds-voris.de/jportal/docs/an … 6/file.jpg

Bild kann bei mir im Firefox nicht angezeigt werden.

hmpf, blöde Website... Vielleicht geht der Link (Ostblatt):
http://www.nds-voris.de/jportal/?quelle … l&max=true

da steht zumindest "Diesen Link können Sie kopieren und verwenden, wenn Sie immer auf die gültige Fassung der Vorschrift verlinken möchten:" 😉

4rch wrote:

hmpf, blöde Website... Vielleicht geht der Link (Ostblatt):
http://www.nds-voris.de/jportal/?quelle … l&max=true

da steht zumindest "Diesen Link können Sie kopieren und verwenden, wenn Sie immer auf die gültige Fassung der Vorschrift verlinken möchten:" 😉

Geht eigentlich auch nicht. Seite ist einfach buggy und schrottig. Hat wahrscheinlich Millionen gekostet.
Mit ein paar Umwegen konnte ich das Bild anzeigen:

http://www.nds-voris.de/jportal/docs/an … 6/0003.htm

Man sieht aber nicht viel, weil recht grob.

In Anlage 3 sind die Detailkarten. Leider so verwirrend, das ich mich da nicht sehr gut zurechtfinde: http://www.nds-voris.de/jportal/?quelle … l&max=true . Aber unter http://portalu.de/freitextsuche?q=natio … =type:map; findet man vllt. bessere Karten.

Ich habe so meine Zweifel ob die Grenze zwischen Hamburg, NDS und SH stimmt da Teile des Nationalpark Schleswig-Holsteinisches Wattenmeer in Hamburg und Niedersachsen liegen, das ist doch eigentlich nicht möglich, oder? Laut Wikipedia liegt der Nationalpark nur in SH. Soweit ich weiß ist für bundeslandübergreifende Nationalparks ein Staatsvertrag zwischen den Bundesländer nötig (so einer wird jedenfalls gerade zwischen RLP und Saarland ausgearbeitet wegen NP Hunsrück).

Ich denke man sollte die Grenzen etwas südwestlich der Grenze des Nationalparks verschieben, hat irgendjemand Einwände dagegen?

PS: Die Grenze des Nationalpark Schleswig-Holsteinisches Wattenmeer stimmt so auf +-100 Meter

4rch wrote:

Ich habe so meine Zweifel ob die Grenze zwischen Hamburg, NDS und SH stimmt da Teile des Nationalpark Schleswig-Holsteinisches Wattenmeer in Hamburg und Niedersachsen liegen, das ist doch eigentlich nicht möglich, oder? Laut Wikipedia liegt der Nationalpark nur in SH. Soweit ich weiß ist für bundeslandübergreifende Nationalparks ein Staatsvertrag zwischen den Bundesländer nötig (so einer wird jedenfalls gerade zwischen RLP und Saarland ausgearbeitet wegen NP Hunsrück).

Ich denke man sollte die Grenzen etwas südwestlich der Grenze des Nationalparks verschieben, hat irgendjemand Einwände dagegen?

Ja, Einspruch. Ich möchte noch mal schauen, was für Informationen es noch über den Grenzverlauzf gibt. Ich glaube, der aktuelle trifft es recht gut.

EDIT: Habe die Grenzverläufe mit zwei öffentlichen BKG-Karten /BL-Grenzen, WebAtlas.Light) verglichen, die zwar approximativ sind, aber ungefähr stimmen sollten. Das bestätigt in etwa die aktuellen Grenzen in OSM.
Auch DigitalerAtlasNord (für Schleswig-Holstein) bestätigt den Verlauf.

Keine Ahnung wie das mit den Nationalparksgrenzen zusammenpasst... 🤔

Gehrke wrote:

EDIT: Habe die Grenzverläufe mit zwei öffentlichen BKG-Karten /BL-Grenzen, WebAtlas.Light) verglichen, die zwar approximativ sind, aber ungefähr stimmen sollten. Das bestätigt in etwa die aktuellen Grenzen in OSM.
Auch DigitalerAtlasNord (für Schleswig-Holstein) bestätigt den Verlauf.

Keine Ahnung wie das mit den Nationalparksgrenzen zusammenpasst... 🤔

ok, komisch, die Nationalparkgrenze stimmt jedenfalls auch, das muss man dann wohl so akzeptieren 😄

Ich schmeiße dann noch die folgende Sandbank (Gelbsand) aus der Sh-Landmasse und dem Kreis Dithmarschen raus: www.openstreetmap.org/way/4096484 Sollte man die auch aus der deutschen Landmasse auch entfernen? Gelbsand zählt wohl nicht als Insel, jedenfalls ist sie in Wikipedia nicht gelistet: https://de.wikipedia.org/wiki/Liste_deutscher_Inseln

Gehrke wrote:

Keine Ahnung wie das mit den Nationalparksgrenzen zusammenpasst... 🤔

Ich auch nicht.

Aber könnte es nicht sein, daß die Nationalparks vom Bund definiert werden und daher die Ländergrenzen unwichtig sind? Sonst gäbe es doch immer ein riesiges Gezanke zwischen den BL darum, wer denn wieviel "abgibt"?

nur so ne Idee,

walter

wambacher wrote:

könnte es nicht sein, daß die Nationalparks vom Bund definiert werden und daher die Ländergrenzen unwichtig sind?

Es könnte. Ich glaube aber nicht. Letztlich sind die Bundesländer ja Staaten ohne Außenpolitik, mit eingeschränkter Steuerhoheit etc.
Glaube eher, die legen das selbst fest. Die NP-Grenzen werden ja auch durch Landesgesetzte definiert, oder nicht?

Gehrke wrote:

wambacher wrote:

könnte es nicht sein, daß die Nationalparks vom Bund definiert werden und daher die Ländergrenzen unwichtig sind?

Es könnte. Ich glaube aber nicht. Letztlich sind die Bundesländer ja Staaten ohne Außenpolitik, mit eingeschränkter Steuerhoheit etc.
Glaube eher, die legen das selbst fest. Die NP-Grenzen werden ja auch durch Landesgesetzte definiert, oder nicht?

Soweit ich das im Hinterkopf habe wird das Bundesumweltministerium zwar eingebunden, aber festlegen muss die Grenze das jeweilige Bundesland per Gesetz. Für den bundesländerübergreifenden Nationalpark Hunsrück-Hochwald wird gerade ein Staatsvertrag zwischen Rheinland-Pfalz und Saarland ausgehandelt: http://mulewf.rlp.de/fileadmin/mufv/img … taatsV.pdf

Für den Nationalpark Schleswig-Holsteinisches Wattenmeer konnte ich keine entsprechende Vereinbarung zwischen den Bundesländern finden. Nur das entsprechende Nationalparkgesetz. Ich muss allerdings betonen, dass ich in der Hinsicht auch nur über Laienwissen verfüge, ich war halt verwundert, dass der Nationalpark namens "Schleswig-Holsteinisches Wattenmeer" teils in Hamburg und NDS liegen soll. Vielleicht gibt es aber auch unterschiedliche Regelungen zwischen Nationalpark im Meer und an Land.

Die Seegrenzen sind eh ein schwieriges Thema. Zwischen Nds. und Bremen (bei Nordenham/Bremerhaven) gibt es sehr unterschiedliche Grenzverläufe auf offiziellen Karten.

Oh mann, des Rätsels Lösung: "Während die Zugehörigkeit des linkselbischen Wattenmeeres zu Niedersachsen bzw. Hamburg geklärt ist, bestehen über die Zugehörigkeit von Teilen des Elbeflusses selbst und einiger rechtselbischer Wattengebiete zwischen Schleswig-Holstein und Niedersachsen Meinungsverschiedenheiten" (1981, http://books.google.de/books?id=gC5eApe … er&f=false)

4rch wrote:

Oh mann, des Rätsels Lösung: "Während die Zugehörigkeit des linkselbischen Wattenmeeres zu Niedersachsen bzw. Hamburg geklärt ist, bestehen über die Zugehörigkeit von Teilen des Elbeflusses selbst und einiger rechtselbischer Wattengebiete zwischen Schleswig-Holstein und Niedersachsen Meinungsverschiedenheiten" http://books.google.de/books?id=gC5eApe … er&f=false

jaja, diese Niedersachsen.

Im Westen Zoff mit den Niederländern und im Osten mit SH und Hamburg. Ist halt ein ziemlich stures Völkchen.

Gruss
walter - geb in Nordhorn/Niedersachsen 😉

wambacher wrote:

Ist halt ein ziemlich stures Völkchen.

Thumbs up! 🙂 https://www.youtube.com/watch?v=1ZPHWMhiggo

Noch mal an alle: zu der Bemerkung

"Und was ist mit demjenigen, der da gerade "rumgeschraubt" hat? Schließlich ist die Ecke nicht von selber kaputt gegangen.
Hab aber net nachgesehen, wer das war, weil ich derzeit Fools 1.2 fertig kriegen will/muß."

Ich habe "rumgeschraubt" auf Basis des Staatsvertrages zw. HH und NS, s.
http://www.landesrecht.hamburg.de/jport … n=bs&st=lr
Anlage 1, Plan II, wobei der Punkt X, den ich mit +/-100m als Basis genommen habe (Höhe Finkenmoorsee), damals noch nicht endgültig definiert war. Ihr habt nun den Punkt X1 als Basis genommen.

Grüße
Richard

Dopaso wrote:

Noch mal an alle: zu der Bemerkung

"Und was ist mit demjenigen, der da gerade "rumgeschraubt" hat? Schließlich ist die Ecke nicht von selber kaputt gegangen.
Hab aber net nachgesehen, wer das war, weil ich derzeit Fools 1.2 fertig kriegen will/muß."

Ich habe "rumgeschraubt" auf Basis des Staatsvertrages zw. HH und NS, s.
http://www.landesrecht.hamburg.de/jport … n=bs&st=lr
Anlage 1, Plan II, wobei der Punkt X, den ich mit +/-100m als Basis genommen habe (Höhe Finkenmoorsee), damals noch nicht endgültig definiert war. Ihr habt nun den Punkt X1 als Basis genommen.

Grüße
Richard

Hi Richard, hierbeí ging es anfangs nicht um die Korrektheit der Grenzen im rechtlichen Sinn sondern darum, daß diese technisch defekt waren. Die Grenze von Hamburg Neuwerk war schlicht und einfach kaputt.

http://forum.openstreetmap.org/viewtopi … 78#p438778

Dass die ganze Ecke ziemlich chaotisch war und dann auch noch Unsicherheiten ("watt den nu?") auftraten, ist ein anderes Thema.

Gruss
walter

Tut mir leid, ich habe die Grenze wahrscheinlich zerstört. Ich wollte die Nationalpark-Wattenmeer-Hamburg-Grenze nicht mit der Landesgrenze zusammen verschieben, da ich nur wusste, dass Letztere nicht korrekt ist. Zwar ist es wahrscheinlich, dass sie übereinander liegen, aber ich wollte korrekt sein. Die Trennung von Linien in Potlatch ist mir auch nicht so transparent, daher kann es sein, dass ich was zerstört habe. Wahrscheinlich hätte ich nach der Auflösung eines gemeinsamen Punktes und dem Entfernen einer Linie den Rest wieder verbinden müssen?
Grüße
Richard

Dopaso wrote:

Wahrscheinlich hätte ich nach der Auflösung eines gemeinsamen Punktes und dem Entfernen einer Linie den Rest wieder verbinden müssen?

So ähnlich. Ist auf dem Bild nicht so einfach zu erkennen aber die Grenzwege von Hamburg Nordwerk hatten sich überschnitten und daher war das keine gültige Geometrie mehr. War nur ein Node unglücklich verschoben.

Ist normalerweise keine große Sache. Das fixt jeder von uns ohne auch nur zu zögern oder gar zu murren, nur war die Gegend an sich schon recht seltsam.

Gruss
walter

Hi, gestern Abend hat jemand die 51477 (Deutschland AL2) an der Zugspitze geschreddert. Ich habe versucht, das wieder hinzubiegen, bekomme aber noch eine angebliche Überlappung, die ich nicht finden kann. Bayern und eventuell Österreich haben auch gelitten.
Schaun 'mer mal, was morgen Früh rauskommt.

Gruss
walter

cs: https://openstreetmap.org/changeset/24331754

edit: Ist wieder da.

@Gehrke: Was sind denn deine Quellen, wenn du im CS-Kommentar boundary improvements (waypoints) schreibst. Ich müsste mal in der Oberlausitz/Sachsen ein paar Grenzen verschieben, habe aber keine legale Quelle.

Gruß Thomas

Moin,

Thomas8122 wrote:

Ich müsste mal in der Oberlausitz/Sachsen ein paar Grenzen verschieben, habe aber keine legale Quelle.

wenn Du der Meinung bist, dass Du ein paar Grenzen verschieben müsstest, dann hast Du doch wohl auch Anhaltspunkte, warum Du die Grenzen verschieben müsstest.
Z. B.

• Haus liegt in der anderen Gemeinde
• Bauer sagt, das Feld gehört noch zur Gemeinde

Dann kannst Du die Grenzen auch anhand dieser Anhaltspunkte verschieben, ohne eine hochgenaue legale Quelle zu haben.

Es sei denn, Du hast als Anhaltspunkte nur eine "illegale" Quelle ... dann kann man sich auch mal mit den geschätzten OSM-Grenzen begnügen ...

Gruß
Georg

Ich hab mir gedacht, wenn ich schon einmal anfange, kann ich es auch gleich richtig machen. Meine Anhaltspunkte sind übrigens die regio-osm-Straßenliste und gemappte Orteingangsschilder. In eine "illegale" Quelle hab ich interessehalber natürlich auch mal reingeschaut.

Gruß Thomas

Moin,

Thomas8122 wrote:

Ich hab mir gedacht, wenn ich schon einmal anfange, kann ich es auch gleich richtig machen.

Das ist doch schon mal ein guter Ansatz. 🙂
Mangels Quellenlage kann man sich aber eben oft nur dem "Richtigen" annähern.

Thomas8122 wrote:

Meine Anhaltspunkte sind übrigens die regio-osm-Straßenliste und gemappte Orteingangsschilder.

OK - Ist zumindest eine gewisse Ortskenntnis vorhanden?
Stichworte:
- Eine Straße in der Liste der Gemeinde sollte sich in der Regel auch innerhalb der Grenze finden lassen - zumindest anteilig.
- Eine Straße, die nicht in der Liste ist, kann sich durchaus mit wenig oder ohne Bebauung anteilig auf dem Gemeindegebiet befinden.
- Ein Ortseingangsschild kann sich durchaus in Grenzfällen außerhalb der Grenze befinden.

Thomas8122 wrote:

In eine "illegale" Quelle hab ich interessehalber natürlich auch mal reingeschaut.

Klar, wer nicht.
Und dann hast Du zumindest eine Kontrolle, ob Deine Änderungen sich dem Richtigen nähern oder es eher verschlechtern.

Gruß
Georg

Hier zum Beispiel liegt die Hausnummer "Hessenbach 5" auf Gemeindegebiet "Glashütte" ist aber in der Adresse zu 01744 gehörend. Die Gemeindegrenze ist durch Grenzsteine nachweisbar. Habe nun nur die PLZ-Grenze "verlegt".

geri-oc wrote:

Hier zum Beispiel liegt die Hausnummer "Hessenbach 5" auf Gemeindegebiet "Glashütte" ist aber in der Adresse zu 01744 gehörend. Die Gemeindegrenze ist durch Grenzsteine nachweisbar. Habe nun nur die PLZ-Grenze "verlegt".

Das kommt x-Mal vor, es gibt aber auch Ausnahmen. Nicht immer folgt die Zuteilung der PLZ-Gebiete dem gesunden Menschenverstand. Ohne Quelle lasse ich auch Grenzen, die ein einzelnes Haus auf der anderen Straßenseite woanders hin zuordnen, zumächst mal wie sie sind.
Selbst Webseiten sind nicht immer zuverlässig: Wenn ein Geschäft eine andere PLZ angibt als die anderen links und rechts, bin ich etwas skeptisch.

Thomas8122 wrote:

@Gehrke: Was sind denn deine Quellen, wenn du im CS-Kommentar boundary improvements (waypoints) schreibst. Ich müsste mal in der Oberlausitz/Sachsen ein paar Grenzen verschieben, habe aber keine legale Quelle

Das ist je Fall recht unterschiedlich. Im Allgemeinen ziehe ich mehrere Quellen zu rate und mache mir daraus dann ein eigenes Bild über die Grenzlage. Oft sind die unterschiedlichen Angaben ja recht widersprüchlich. Ich kann daher oft auch nur gut raten. Das mache ich natürlich auch nur, wenn ich mir sicher bin, dass es danach besser ist als vorher.

"Illegale Quellen" habe ich nicht und kenne ich nicht (Was auch immer hier "illegal" heißen soll). Mein Wissen (manchmal nur Vermutungen) erlange ich aus öffentlichen Quellen (dazu gehört u.a. auch der recht grobe WebAtlasDe.Light). Wenn ich auf einer Karte sehe, dass ein Haus, Wald, Fluss etc. auf der einen oder anderen Seite einer Grenze ist, sehe ich überhaupt kein Problem darin, dieses erlangte Wissen danach umzusetzen, indem ich die Grenze manuell verschiebe (z.B. mit der OSM-Karte als Hintergrund). Sobald es um das detaillierte oder gar automatisierte Abzeichnen von Karten geht, betreten wir einen rechtlichen Graubereich, den es im Zweifel natürlich stets zu meiden gilt. Wenn man z.B. sieht, dass eine Grenze einem Flusslauf folgt, gibt es keinen erkennbaren rechtlichen Grund, die Grenze in OSM (z.B. mit Bing-Luftbildern) so anzupassen. Insgesamt lässt sich sagen, dass es sehr aufwändig werden kann, Grenzenverläufe für OSM zu verbessern.

Ortschilder u.ä. sind selten hilfreich, da es bei Admin-Grenzen ja nicht um Siedlungsgebiete geht.

EDIT: Typo

Gehrke wrote:

Mein Wissen (manchmal nur Vermutungen) erlange ich aus öffentlichen Quellen (dazu gehört u.a. auch der recht grobe WebAtlasDe.Light).

Das hilft mir schon mal weiter.

Gehrke wrote:

Ortschilder u.ä. sind selten hilfreich, da es bei Admin-Grenzen ja nicht um Siedlungsgebiete geht.

In dem Fall schon, weil die Orte ineinanderübergehen. (Schild mit alt_name)

Eine einfache Idee, um die grobe Qualität der Grenzen zu überprüfen (einfacher als die Flächenabweichungen, die ich auf Anfrage auch mal aktualisieren kann):

Die Referenzkoordinaten von DESTATIS (sind meist bezogen auf die Siedlung) sollten innerhalb des Polygons liegen. das trifft in folgenden Fällen nicht zu:

3659532;"070009999999";"Gemeinsames␣deutsch-luxemburgisches␣Hoheitsgebiet"
1244322;"071345002084";"Siesbach"
540067;"071415006087";"Misselberg"
1258356;"072315001071";"Kommen"
1257092;"072355001093";"Neuhütten"
1255896;"072355006077";"Longen"
1427219;"130715151148";"Utzedel"
3422079;"130755553155";"Neetzow-Liepen"

Werde mir das mal anschauen. Aber ich hatte mehr Fälle befürchtet.

Gehrke wrote:

Eine einfache Idee, um die grobe Qualität der Grenzen zu überprüfen: Die Referenzkoordinaten von DESTATIS sollten innerhalb des Polygons liegen. Das trifft in folgenden Fällen nicht zu:

3659532;"070009999999";"Gemeinsames␣deutsch-luxemburgisches␣Hoheitsgebiet"
1244322;"071345002084";"Siesbach"
540067;"071415006087";"Misselberg"
1258356;"072315001071";"Kommen"
1257092;"072355001093";"Neuhütten"
1255896;"072355006077";"Longen"
1427219;"130715151148";"Utzedel"
3422079;"130755553155";"Neetzow-Liepen"

Alles in RP ist gefixt. Utzedel ist eine größere Sache. Das ist völlig daneben! (Ist jetzt in Ordnung)
Das DE-LUX kondominium hat gar keine DESTATIS-Ref-Koordinaten.
Neetzow-Liepen hat falsche DESTATIS-Ref-Koordinaten (liegen in Schweden! DESTATIS ist informiert).

Ein User (mit 2 Edits) hat die Stadt Mosbach zu einem "dorf Mösbach" geändert (habe ich korrigiert).

Ich sehe durch andere Edits, dass der User auch im echten Dorf Mösbach (Stadtteil von Achern) aktiv war und Gebäudegeometrien gelöscht hat. Prüfe noch, ob Versehen oder Vandalismus vorliegt.

Am gleichen Tag war ein anderer user auch in Mösbach aktiv und hat Häuser anhand ihrer Dachfläche abgezeichnet (schön schief den Giebel entlang). Nun spätestens jetzt wirds wohl OT.

Gehrke wrote:

Am gleichen Tag war ein anderer user auch in Mösbach aktiv und hat Häuser anhand ihrer Dachfläche abgezeichnet (schön schief den Giebel entlang). Nun spätestens jetzt wird's wohl OT.

Sowas hatten wir doch gerade von einigen Wochen. Ich hab den damaligen "Übeltäter" angesprochen. Er hat sich entschuldigt, Besserung gelobt und dann die Fliege gemacht - natürlich ohne seinen Schrott zu bereinigen 🙁 http://www.openstreetmap.org/user/Lucas … 735/8.9804

Nun, hier ist es aber wohl jemand anders.

Gruss
walter

wambacher wrote:

Gehrke wrote:

Am gleichen Tag war ein anderer user auch in Mösbach aktiv und hat Häuser anhand ihrer Dachfläche abgezeichnet (schön schief den Giebel entlang). Nun spätestens jetzt wird's wohl OT.

Sowas hatten wir doch gerade von einigen Wochen. Ich hab den damaligen "Übeltäter" angesprochen. Er hat sich entschuldigt, Besserung gelobt und dann die Fliege gemacht - natürlich ohne seinen Schrott zu bereinigen 🙁 http://www.openstreetmap.org/user/Lucas … 735/8.9804

Nun, hier ist es aber wohl jemand anders.

Häufig sind das Studenten oder Schüler, die das in einem Kurs machen (fast immer iD) und oft nicht wissen was sie tun (u.a. die "echte" Karte für alle verändern).

Hei,

eventuell ist mir in Bezug auf die Stadt Calau http://www.openstreetmap.org/relation/1322899 (genauer einer der Ortsteilgrenzen)
ein Missgeschick passiert, was zu kaputten Grenzen geführt haben könnte... die Internetverbindung riß wegen Gewitter immer wieder ab, und dann auch während des Hochladens... sobald Verbindung wieder stabil ist, schaue ich mit die Sache selbst noch mal an.

meldet Sven

streckenkundler wrote:

Hei,

eventuell ist mir in Bezug auf die Stadt Calau http://www.openstreetmap.org/relation/1322899 (genauer einer der Ortsteilgrenzen)
ein Missgeschick passiert, was zu kaputten Grenzen geführt haben könnte... die Internetverbindung riß wegen Gewitter immer wieder ab, und dann auch während des Hochladens... sobald Verbindung wieder stabil ist, schaue ich mit die Sache selbst noch mal an.

meldet Sven

so wie ich das im Moment sehe, war der Änderungssatz:

http://www.openstreetmap.org/changeset/24501388 defekt und ich konnte ihn anscheinend mit dem Änderungssatz
http://www.openstreetmap.org/changeset/24501514 beheben.

Innerhalb des AL 8 Calau ( http://www.openstreetmap.org/relation/1322899 ) konnte ich keine defekten Grenzen finden...

Die gescheiterten Relationen des o.g. defekten Änderungssatzes:
http://www.openstreetmap.org/relation/3929623
http://www.openstreetmap.org/relation/3929624
http://www.openstreetmap.org/relation/3929625

erfasse ich neu.

Gewittrige Grüße,

Sven

Habe mal wieder die DESTATIS-Gebietsabweichungen geprüft (dieses Mal endlich direkt mit der Datenbank). Bayern hatte ich bisher außen vor gelassen, weil die gem.fr. Gebiete (gfG) von Bayern DESTATIS einfach nicht gemeldet werden und das die Auswertung sehr erschwerte. Jetzt habe ich es doch gemacht (ohne gfG) und fand das Ergebnis überraschend schlecht: https://wiki.openstreetmap.org/wiki/DE: … 9Cbersicht

Insgesamt summieren sich die bayrischen Abweichungen auf 200,98 km². Und: Was ist in Selb (37.93% Abweichung), Painten (166.62%) und Rechtenbach (244.5%) los?
Bei Rechtenbach ist wohl das Prolbem, dass die DESTATIS-Daten die Eingemeindung des gfG Rothenberg nicht berücksichtigen. Bei Selb und Painten sind es wohl ähnliche Fälle 🙄
Manchmal ist OSM eben sogar besser als die offiziellen Daten!

Die Abweichung für Warmensteinach kann ich aber nicht erklären. Gab es da auch Eingemeindungen?

Gehrke wrote:

Habe zum Dank gleich die neu entdeckten Fehler gemeldet (Gemeindeflächen in Bayern).

EDIT: Rückmeldung von DESTATIS: Bayern korrigiert die Flächen der Gemeinden nur einmal im Jahr. 🙄

Gehrke wrote:

EDIT: Rückmeldung von DESTATIS: Bayern korrigiert die Flächen der Gemeinden nur einmal im Jahr. 🙄

Immer diese Extrawürste 🙁

Gehrke wrote:

Die Abweichung für Warmensteinach kann ich aber nicht erklären. Gab es da auch Eingemeindungen?

2013 oder so wurde der Warmensteinacher Forst-Nord wohl arg verkleinert und große Teile nach Warmensteinach eingemeindet. Das bestätigt der Bayern-Atlas. Wikipedia hat das auch nicht mitbekommen. Quellen zu dieser Eingemeindung finde ich auch nicht...

Gehrke wrote:

Gehrke wrote:

Die Abweichung für Warmensteinach kann ich aber nicht erklären. Gab es da auch Eingemeindungen?

2013 oder so wurde der Warmensteinacher Forst-Nord wohl arg verkleinert und große Teile nach Warmensteinach eingemeindet. Das bestätigt der Bayern-Atlas. Wikipedia hat das auch nicht mitbekommen. Quellen zu dieser Eingemeindung finde ich auch nicht...

zum 1. Januar 2013: http://www.regierung.oberfranken.bayern … 012_12.pdf

JohnDoe23 wrote:

Gehrke wrote:

Gehrke wrote:

Die Abweichung für Warmensteinach kann ich aber nicht erklären. Gab es da auch Eingemeindungen?

2013 oder so wurde der Warmensteinacher Forst-Nord wohl arg verkleinert und große Teile nach Warmensteinach eingemeindet. Das bestätigt der Bayern-Atlas. Wikipedia hat das auch nicht mitbekommen. Quellen zu dieser Eingemeindung finde ich auch nicht...

zum 1. Januar 2013: http://www.regierung.oberfranken.bayern … 012_12.pdf

Danke! Und die Bayern haben die neue Fläche noch immer nicht an DESTATIS gemeldet...

Moin Moin,

ausnahmsweise mal hier, da nur DEU ausgewertet wurde:

Relation␣|␣Country␣|␣␣␣␣␣␣␣␣␣␣␣New␣Boundary
----------+---------+----------------------------------
907047␣|␣DEU␣␣␣␣␣|␣Wachenheim␣an␣der␣Weinstraße␣(7)
(1␣row)

Relation␣|␣Country␣|␣Missing␣Boundary
----------+---------+------------------
312076␣|␣DEU␣␣␣␣␣|␣Drewer-Nord␣(10)
312074␣|␣DEU␣␣␣␣␣|␣Drewer-Süd␣(10)
(2␣rows)

Hab mal meinen "Heimvorteil" ausgenutzt und die Sache gleich korrigiert. Da hat ein Newbie im ersten und bisher einzigen Edit mit Potlatch2 wohl ein wenig zu viel rumgefummelt.

Gruss
walter

Hi,

ich bastel arbeite noch an einer kleinen Erweiterung: Anzeige erheblicher Grössenänderungen bei den Flächen.

Grund für diese Auswertung: Wenn komplexe Multipolygone mit inner/outer defekt werden, kann das MP manchmal "überleben". D.h. es ist immer noch vorhanden, aber erheblich kleiner. Da reicht der einfache Vergleich "ist neu?"/"fehlt?" nicht mehr aus.

Hab das bei mehreren Ländern gehabt, wo dann plötzlich ein AL4 nur noch aus einer Insel bestand (outer) aber der Rest weg war.

Hier mal der erste Versuch. Vergleich der Flächen in DEU von gestern und heute früh:

Relation␣|␣Country␣|␣␣␣␣␣␣␣␣city␣␣␣␣␣␣␣␣|␣old␣Km²␣|␣new␣Km²␣|␣%␣diff
----------+---------+--------------------+---------+---------+--------
1451524␣|␣DEU␣␣␣␣␣|␣Lüttow-Valluhn␣(8)␣|␣19.1954␣|␣24.5798␣|␣␣28.05
2900136␣|␣DEU␣␣␣␣␣|␣Zella/Rhön␣(8)␣␣␣␣␣|␣1.40724␣|␣1.71094␣|␣␣21.58
1451580␣|␣DEU␣␣␣␣␣|␣Kogel␣(8)␣␣␣␣␣␣␣␣␣␣|␣36.2827␣|␣␣29.956␣|␣-17.44
2900132␣|␣DEU␣␣␣␣␣|␣Empfertshausen␣(8)␣|␣4.33029␣|␣5.12434␣|␣␣18.34
2900084␣|␣DEU␣␣␣␣␣|␣Andenhausen␣(9)␣␣␣␣|␣␣2.1507␣|␣1.39119␣|␣-35.31
(5␣rows)

Vergleich der Flächen DEU von gestern und heute früh. Angezeigt werden Änderungen ab 10%.

Hab es mal analysiert. Zwischen Lüttow-Valluhn und Kogel wurde die Grenze verschoben. Dabei ist Lüttow-Valluhn größer und Kogel kleiner geworden. Analog für die andere 3 Treffer. Die liegen alle zusammen.

Also alles ok. Es kann aber morgen schon anders aussehen.

Gruss
walter

ps: Erst bei >= 4% kommt eine Grenze mehr. Ich glaube 10% ist vorerst ok.