APP zum Überprüfen der amtlichen Grenzen in Deutschland

Hey super Sache! Wenn die Daten nun noch von www.maposmatic.org genutzt werden könnten, hätte das einen enormen Mehrwert 🙂

Danke für die visualisierung.
Die Grenze zwischen Essen und Gelsenkirchen/RegBez Düsseldorf und Münster habe ich gleich mal geschlossen.
Aber warum werden mir bei NRW als Fehler1:
Pobershau, Irrel, Echternacherbrück und Bollendorf angezeigt?
Die liegen alle höchstwahrscheinlich nicht in NRW.

EDIT: Aus Fehler2 ist Hennef(Sieg) jetzt auch "sauber". Da war admin_level als postal_code_level getaggt.

Gruß,
ajoessen

misterboo wrote:

Die Daten sind erstaunlich vollständig in OSM.

In NRW besteht noch das Problem, dass viele der Gemeindegrenzen von einem
nicht-Zustimmer gemalt wurden...

Hatte jemand flohoff mal kontaktiert ob er eventuell eine Sondergenehmigung
erteilt ?

Chris

!i! wrote:

Hey super Sache! Wenn die Daten nun noch von www.maposmatic.org genutzt werden könnten, hätte das einen enormen Mehrwert 🙂

Ja ich habe noch einige Ideen, z.B zumindest die Ausweitung aus Europäische Grenzen mit dem NUTS Schema, da dies auch schon ansatzweise getaggt wird, die Umstellung auf minutly Updates mit einem Liveticker und auch noch die Auswertungen der Straßen, da einige Gemeinden ja schon ihre kompletten Straßenlisten zur Verfügung stellen. Das erstellen und der einfache Download eines kompletten Straßenverzeichnissen einer Gemeinde wird dann auch möglich sein.

ajoessen wrote:

Danke für die visualisierung.
Die Grenze zwischen Essen und Gelsenkirchen/RegBez Düsseldorf und Münster habe ich gleich mal geschlossen.
Aber warum werden mir bei NRW als Fehler1:
Pobershau, Irrel, Echternacherbrück und Bollendorf angezeigt?
Die liegen alle höchstwahrscheinlich nicht in NRW.

EDIT: Aus Fehler2 ist Hennef(Sieg) jetzt auch "sauber". Da war admin_level als postal_code_level getaggt.

Gruß,
ajoessen

Die Fehler werden nicht pro Bundesland angezeigt, das sind alle Fehler deutschlandweit.

Da kann ich nur sagen: Gut gemacht! Und weiter so 🙂

Vielleicht noch als Anregung, es werden öfters bei mir PLZ Verzeichnisse nachgefragt. Die Leute würden sich sicherlich über Flächen/Positions Zuordnungen freuen, aber das geht ein wenig am Thma von Politischen Grenzen vorbei.

chris66 wrote:

misterboo wrote:

Die Daten sind erstaunlich vollständig in OSM.

In NRW besteht noch das Problem, dass viele der Gemeindegrenzen von einem
nicht-Zustimmer gemalt wurden...

Hatte jemand flohoff mal kontaktiert ob er eventuell eine Sondergenehmigung
erteilt ?

Chris

Laut
http://wiki.openstreetmap.org/wiki/User:Flohoff
sind seine edits public domain. Irgendwer hat sie deshalb adoptiert.

Gruß,
ajoessen

misterboo wrote:

Die Fehler werden nicht pro Bundesland angezeigt, das sind alle Fehler deutschlandweit.

Dann sind aber 6 kaputte Relationen in ganz DE schon ziemlich gut.

Gruß,
ajoessen

!i! wrote:

Da kann ich nur sagen: Gut gemacht! Und weiter so 🙂

Vielleicht noch als Anregung, es werden öfters bei mir PLZ Verzeichnisse nachgefragt. Die Leute würden sich sicherlich über Flächen/Positions Zuordnungen freuen, aber das geht ein wenig am Thma von Politischen Grenzen vorbei.

Ja gehört ja auch zu den Grenzen und ich werte das lokal auch schon aus. Die PLZ Grenzen sind ja auch nahezu vollständig erfasst, daher ist das auch eine sinnvolle Erweiterung für die Zukunft.

Gefällt mir sehr gut. Zwei Sachen sind mir aufgefallen

Ich bekomme meinen Gemeindeverband nicht ausgewählt
http://www.openstreetmap.org/browse/relation/916396

Und ist es möglich, die Fehler (1,2,3) zu visualiseren? Dann könnte ich mich in meiner Gegend mal umschauen

ajoessen wrote:

misterboo wrote:

Die Fehler werden nicht pro Bundesland angezeigt, das sind alle Fehler deutschlandweit.

Dann sind aber 6 kaputte Relationen in ganz DE schon ziemlich gut.

Gruß,
ajoessen

ja generell sind die Grenzen in D top erfasst, nur 240 fehlende Gemeinden bei aktuell ca. 11500 Gemeinden und unter 10 kaputte Relationen ist TOP.

Diskutieren müsse man mal noch über die Verbandsgemeinden, die ich noch nicht auswerte aus der Seite, da es momentan kein einheitliches Tagging dafür gibt. Viele Verbandsgemeinden sind schon erfasst. Aber de:de:amtlicher_gemeindeschluessel ist nicht dafür geignet, trotzdem wir der Tag dafür verwendet.

Der AGS ist nicht für Verbandsgemeinden vorgesehen, sondern der 12 stellige Regionalschlüssel, auf den doch sowieso der Bund wechseln will irgendwann. Da die falsche eingetragenen Verbandsgemeinden im AGS die Auswertung erschweren wäre es sowieso eine Überlegung diesen in OSM durch den Regionalschlüssel zu ersetzen. Aus dem Regionalschlüssel lässt sich ja problemlos der AGS auslesen.

SunCobalt wrote:

Gefällt mir sehr gut. Zwei Sachen sind mir aufgefallen

Ich bekomme meinen Gemeindeverband nicht ausgewählt
http://www.openstreetmap.org/browse/relation/916396

Und ist es möglich, die Fehler (1,2,3) zu visualiseren? Dann könnte ich mich in meiner Gegend mal umschauen

Gemeindeverband: siehe mein nächstes Posting. Gemeindeverbände haben keinen allgemeinen Gemeindeschlüssel sondern einen Regionalschlüssel. Diesen sollte man nicht mit dem AGS verwechseln und auch nicht damit taggen. Bis es da einen Konsenz beim Tagging gibt, lasse ich die noch weg.

SunCobalt wrote:

Gefällt mir sehr gut. Zwei Sachen sind mir aufgefallen

Ich bekomme meinen Gemeindeverband nicht ausgewählt
http://www.openstreetmap.org/browse/relation/916396

Und ist es möglich, die Fehler (1,2,3) zu visualiseren? Dann könnte ich mich in meiner Gegend mal umschauen

Visualisierung von Fehler 1 mache ich gerade, ist kein Problem, da die Daten ja in den OSM Daten vorhanden sind. Etwas schwieriger wird die Visualisierung von Fehler 2, da die Grenzen ja meist gar nicht da sind, ich werde da aber dann auf die nächst höhere Ebene zoomen (also den Landkreis z.B) und noch eine Suche nach dem meist vorhandenen Place Node machen und diesen dann anzeigen. Evt. werde ich die Fehler auch noch nach Bundesländern lokalisieren, so dass man leichter die Fehler in seiner Umgebung findet.

Ein Tagging Problem macht die Visualisierung auch deutlich:

Beispiel Hamburg: Hamburg ist ein Bundesland aber auch eine Stadt.

Getaggt ist es mit admin_level=4 (also Bundesland) und AGS=02

Ein Auswerteprogramm kann da nicht erkennen, dass Hamburg auch eine Stadt ist.

Evt. sollte man dann den komplette 8-stellige AGS angeben also 02 0 00 000

damit erkenne ich dann an admin_level=4, dass es ein Bundesland ist, aber auch an dem 8-stelligen AGS, dass es eine Stadt ist.

Gleiches Vorgehen bei z.B kreisfreien Städten, die sind in OSM oft 5 stellig getaggt

z.b. die kreisfreie Stadt Amberg in Bayern AGS: 09361 und admin_level = 6 (Kreis)

Um dies von den Landkreisen unterscheiden zu können, sollte man auch hier den kompletten 8-stelligen AGSverwenden: 09 3 61 000

Den ausgelesenen AGS-tag mit Nullen auf 8 Stellen aufzufüllen sollte aber doch nicht allzu schwer sein.

Gruß,
ajoessen

ajoessen wrote:

Den ausgelesenen AGS-tag mit Nullen auf 8 Stellen aufzufüllen sollte aber doch nicht allzu schwer sein.

Gruß,
ajoessen

ich weiß ja aus den OSM Daten gerade nicht, dass es eine Stadt ist. Ein normales Bundesland wie das Saarland ist ja genauso getaggt. Es sollten eben nur die Städte auf 8 Stellen erweitert werden in den OSM Daten. Dies gilt für die Bundesländer Hamburg, Bremen sowie für die ganzen kreisfreien Städte mit admin_level=6

Klasse!!! 9 von 10 Fehlern bei den nicht geschlossenen Relationen sind schon behoben 🙂 Damit erfüllt die App schon mal ihren Zweck.

misterboo wrote:

ajoessen wrote:

Den ausgelesenen AGS-tag mit Nullen auf 8 Stellen aufzufüllen sollte aber doch nicht allzu schwer sein.

Gruß,
ajoessen

ich weiß ja aus den OSM Daten gerade nicht, dass es eine Stadt ist. Ein normales Bundesland wie das Saarland ist ja genauso getaggt. Es sollten eben nur die Städte auf 8 Stellen erweitert werden in den OSM Daten. Dies gilt für die Bundesländer Hamburg, Bremen sowie für die ganzen kreisfreien Städte mit admin_level=6

Du findest aber beim Nachschauen der AGS in der destatis-Liste genau einen Eintrag, wenn es eine kreisfreie Stadt ist.
05154 ist eben nur der Kreis Kleve; 05124 die kreisfreie Stadt Wuppertal.

Mir wäre ja auch ein eindeutiges tag für Gemeinde/Verbandsgemeinde/Stadt/kreisfreie Stadt lieber.

Gruß,
ajoessen

ajoessen wrote:

misterboo wrote:

ajoessen wrote:

Den ausgelesenen AGS-tag mit Nullen auf 8 Stellen aufzufüllen sollte aber doch nicht allzu schwer sein.

Gruß,
ajoessen

ich weiß ja aus den OSM Daten gerade nicht, dass es eine Stadt ist. Ein normales Bundesland wie das Saarland ist ja genauso getaggt. Es sollten eben nur die Städte auf 8 Stellen erweitert werden in den OSM Daten. Dies gilt für die Bundesländer Hamburg, Bremen sowie für die ganzen kreisfreien Städte mit admin_level=6

Du findest aber beim Nachschauen der AGS in der destatis-Liste genau einen Eintrag, wenn es eine kreisfreie Stadt ist.
05154 ist eben nur der Kreis Kleve; 05124 die kreisfreie Stadt Wuppertal.

Mir wäre ja auch ein eindeutiges tag für Gemeinde/Verbandsgemeinde/Stadt/kreisfreie Stadt lieber.

Gruß,
ajoessen

Welche destatis Liste meinst du ? bei mir ist Wuppertal auch als Stadt drin mit dem AGS: 05124000

Genauso wie bei der Online Abfrage:

http://www.destatis.de/jetspeed/portal/ … __nnn=true

Und genau deshalb sollten wir die Daten auch bei den kreisfreien Städten und den beiden Bundesländern Hamburg und Bremen auf 8 Stellen auffüllen

Oder noch besser: gleich den amtlichen Gemeindeschlüssel auf den 12 stelligen Regionalschlüssel umstellen, damit sind dann auch die Gemeindeverbände abgedeckt.

Das könnte perfekt ein BOT machen , evt noch den Tag abkürzen und international anpassen z.B ref:de:rgs=* oder so was ähnliches

analog könnte man das europäische Sytem nuts mit ref:eu:nuts=* oder das welweite iso System mit ref:world:iso3166-1=* taggen

In SH werden einige Gemeinden nicht gefunden, obwohl sie gemappt sind. Der Grund dafür sind unterschiedliche admin_level. Es gibt hier Gemeinden, die unterhalb von Kreisen über Ämter organisiert sind. Kreise haben admin_level 6, Ämter haben admin_level 7. Gemeinden haben admin_level 8 wenn sie zu einem Amt gehören und admin_level 7 wenn sie amtsfrei und damit Ämtern gleichgestellt sind. Letzere werden nicht mit dieser Suche nicht gefunden. Soweit der Ist-Zustand, wie ich ihn verstehe.

Beispiele aus SH / Kreis Schleswig-Flensburg:
Amt Eggebek http://www.openstreetmap.org/browse/relation/1156153
Gemeinde Wanderup (im Amt Eggebek) http://www.openstreetmap.org/browse/relation/1156126
Gemeinde Handewitt (amtsfrei) http://www.openstreetmap.org/browse/relation/1149297

Jetzt endlich meine Frage ;-)
Sind die admin_level falsch gemappt oder ist das einfach die normale Unschärfe (à la Konsens ist, dass wir keinen Konsens haben) bei der Verwendung von admin_level und es kann erstmal ignoriert werden, dass die App die Gemeinden nicht findet?

Ansonsten: Klasse App!

misterboo wrote:

hier mal die Beta Version meiner kleinen App zum Abgleich des amtlichen Gemeindeverzeichisses
mit den OSM Daten.

Feine Sache. Da soll noch einer sagen, die ganze Diskussion neulich wäre sinnlos gewesen ;-) Bin beeindruckt, wie schnell Du das hinbekommen hast. Bitte auch auf den QS-Seiten verlinken.

Kannst Du "Fehler [123]" noch durch etwas mehr "sprechende" Namen ersetzen, d.h. durch eine Kurzfassung der Beschreibung im Popup. Und "Gemeinden, die nicht zugeordnet werden können" scheint mir auch nicht wirklich deutlich. Eventuell zwei, drei erklärende Sätze als "Hilfe"?

misterboo wrote:

Ja ich habe noch einige Ideen, z.B zumindest die Ausweitung aus Europäische Grenzen mit dem NUTS Schema, da dies auch schon ansatzweise getaggt wird, die Umstellung auf minutly Updates mit einem Liveticker und auch noch die Auswertungen der Straßen, da einige Gemeinden ja schon ihre kompletten Straßenlisten zur Verfügung stellen. Das erstellen und der einfache Download eines kompletten Straßenverzeichnissen einer Gemeinde wird dann auch möglich sein.

Deine Prioritäten mußt Du natürlich selber setzen... aber Aktualisierung in Echtzeit scheint mir bei einer solchen QS-Seite übertrieben. Da würde ich doch eher die Straßenverzeichnisse vorziehen. Bei einer eventuellen Ausweitung auf Europa würde ich aber eher die Schlüsselnummern des jeweiligen Landes verwenden als NUTS. In FR etwa gibt es schon viele Gemeindegrenzen mit ref:INSEE (aber leider wohl noch weniger Interesse an Qualitätssicherung als in DE).

Zartbitter wrote:

In SH werden einige Gemeinden nicht gefunden, obwohl sie gemappt sind. Der Grund dafür sind unterschiedliche admin_level. Es gibt hier Gemeinden, die unterhalb von Kreisen über Ämter organisiert sind. Kreise haben admin_level 6, Ämter haben admin_level 7. Gemeinden haben admin_level 8 wenn sie zu einem Amt gehören und admin_level 7 wenn sie amtsfrei und damit Ämtern gleichgestellt sind. Letzere werden nicht mit dieser Suche nicht gefunden. Soweit der Ist-Zustand, wie ich ihn verstehe.

Beispiele aus SH / Kreis Schleswig-Flensburg:
Amt Eggebek http://www.openstreetmap.org/browse/relation/1156153
Gemeinde Wanderup (im Amt Eggebek) http://www.openstreetmap.org/browse/relation/1156126
Gemeinde Handewitt (amtsfrei) http://www.openstreetmap.org/browse/relation/1149297

Jetzt endlich meine Frage ;-)
Sind die admin_level falsch gemappt oder ist das einfach die normale Unschärfe (à la Konsens ist, dass wir keinen Konsens haben) bei der Verwendung von admin_level und es kann erstmal ignoriert werden, dass die App die Gemeinden nicht findet?

Ansonsten: Klasse App!

Wie gesagt: bei der Auswertung von admin_level 7 und damit den Gemeindeverbänden tue ich mich noch schwer, weil die dazu nötigen Daten(der Gemeindeverbandsschlüssel) nicht Teil des Allgemeinen Gemeindeschlüssels ist sondern nur Teil des Regionalschlüssels, daher brauchen wir dringend einen Konsenz wie wir die Verbandsgemeinden korrekt taggen sollen.

Zartbitter wrote:

Jetzt endlich meine Frage ;-)
Sind die admin_level falsch gemappt oder ist das einfach die normale Unschärfe (à la Konsens ist, dass wir keinen Konsens haben) bei der Verwendung von admin_level und es kann erstmal ignoriert werden, dass die App die Gemeinden nicht findet?

Also konsequent ist das nicht:

In NRW sind alle Gemeinden amtsfrei und in level 8 (oder 6), 7 gibts nicht.
In SH sind amtsfreie in 7, amtsangehörige in 8.

EDIT: In RLP sind amtsfreie Gemeinden admin_level 8, z.B. Herdorf:
http://www.openstreetmap.org/browse/relation/421958

Gruß,
ajoessen

Oli-Wan wrote:

misterboo wrote:

hier mal die Beta Version meiner kleinen App zum Abgleich des amtlichen Gemeindeverzeichisses
mit den OSM Daten.

Feine Sache. Da soll noch einer sagen, die ganze Diskussion neulich wäre sinnlos gewesen ;-) Bin beeindruckt, wie schnell Du das hinbekommen hast. Bitte auch auf den QS-Seiten verlinken.

Kannst Du "Fehler [123]" noch durch etwas mehr "sprechende" Namen ersetzen, d.h. durch eine Kurzfassung der Beschreibung im Popup. Und "Gemeinden, die nicht zugeordnet werden können" scheint mir auch nicht wirklich deutlich. Eventuell zwei, drei erklärende Sätze als "Hilfe"?

misterboo wrote:

Ja ich habe noch einige Ideen, z.B zumindest die Ausweitung aus Europäische Grenzen mit dem NUTS Schema, da dies auch schon ansatzweise getaggt wird, die Umstellung auf minutly Updates mit einem Liveticker und auch noch die Auswertungen der Straßen, da einige Gemeinden ja schon ihre kompletten Straßenlisten zur Verfügung stellen. Das erstellen und der einfache Download eines kompletten Straßenverzeichnissen einer Gemeinde wird dann auch möglich sein.

Deine Prioritäten mußt Du natürlich selber setzen... aber Aktualisierung in Echtzeit scheint mir bei einer solchen QS-Seite übertrieben. Da würde ich doch eher die Straßenverzeichnisse vorziehen. Bei einer eventuellen Ausweitung auf Europa würde ich aber eher die Schlüsselnummern des jeweiligen Landes verwenden als NUTS. In FR etwa gibt es schon viele Gemeindegrenzen mit ref:INSEE (aber leider wohl noch weniger Interesse an Qualitätssicherung als in DE).

Wie gesagt: die Ankündigung kam ja erst vor ein paar Tagen, daher ist dies auch mal eine schnell zusammen gehackte Beta Version. Aber ich wollte sie veröffentlichen weil sie ja schon mal hilft bei der Fehlersuche. Eine Hilfefunktion und etwas aussagekräftigere Fehlerbeschreibungen kommen natürlich noch.

Ich finde das NUTS System schon sehr nützlich. Die EU hat einen riesigen statistischen Datenbestand, der auf den NUTS Daten beruht.

http://epp.eurostat.ec.europa.eu/portal … ostat/home

genauso wie es mittlerweile viele offene Daten für die ganze Welt gibt, zb. von der World Bank, die auf dem iso-3166 System aufbauen.

http://www.worldbank.org/

Eine Verknüfung der NUTS Daten mit OSM würde vielen die Visualisierung von Daten sicher erleichtern. Die nationalen Schlüssel sind eben national nützlich, genauso wie die Eu Nuts Daten oder die Welt ISO-3166 Daten für größere überregionale Anwendungen.

Kennt jemand den Unterschied ziwschen:
http://www.openstreetmap.org/browse/relation/611092
http://www.openstreetmap.org/browse/relation/611084

soll beides admin_level 7 Bad Kreuznach sein.
AGS 0713301 ist aber nicht vergeben.

gruß,
ajoessen

ajoessen wrote:

Zartbitter wrote:

Jetzt endlich meine Frage ;-)
Sind die admin_level falsch gemappt oder ist das einfach die normale Unschärfe (à la Konsens ist, dass wir keinen Konsens haben) bei der Verwendung von admin_level und es kann erstmal ignoriert werden, dass die App die Gemeinden nicht findet?

Also konsequent ist das nicht:

In NRW sind alle Gemeinden amtsfrei und in level 8 (oder 6), 7 gibts nicht.
In SH sind amtsfreie in 7, amtsangehörige in 8.

EDIT: In RLP sind amtsfreie Gemeinden admin_level 8, z.B. Herdorf:
http://www.openstreetmap.org/browse/relation/421958

Gruß,
ajoessen

Gerade bei Herdorf war das ja die letzte Änderung:

Mecklenburg-Vorpommern: an einigen Gemeinde place-Objekten is_in und Gemeindeschlüssel korrigiert; Rheinland-Pfalz: an Gemeinderelation Herdorf admin_level von 7 auf 8 geändert

Eigentlich wäre level 7 aber die sinnvollere Einordnung

misterboo wrote:

Gerade bei Herdorf war das ja die letzte Änderung:

Mecklenburg-Vorpommern: an einigen Gemeinde place-Objekten is_in und Gemeindeschlüssel korrigiert; Rheinland-Pfalz: an Gemeinderelation Herdorf admin_level von 7 auf 8 geändert

Eigentlich wäre level 7 aber die sinnvollere Einordnung

Das passt aber nicht zu den Gemeinden in NRW, die alle 8 sind, und amtsfrei.

Gruß,
ajoessen

ajoessen wrote:

Kennt jemand den Unterschied ziwschen:
http://www.openstreetmap.org/browse/relation/611092
http://www.openstreetmap.org/browse/relation/611084

soll beides admin_level 7 Bad Kreuznach sein.
AGS 0713301 ist aber nicht vergeben.

gruß,
ajoessen

http://www.openstreetmap.org/browse/relation/611084

Das ist die Stadt Bad Kreuznach mit der AGS 07133006 - sollte aber level 8 sein

http://www.openstreetmap.org/browse/relation/611092

Das ist die Verbandsgemeinde Bad Kreuznach in getaggt mit der AGS 0713301

Level 7 ist korrekt ... der AGS aber nicht denn eine Verbandsgemeinde hat keinen AGS sonder einen Regionalschlüssel

der ist korrekt: 07 1 33 5001

und zeigt das dringend ein einheitliches Tagging erforderlich ist.

ajoessen wrote:

misterboo wrote:

Gerade bei Herdorf war das ja die letzte Änderung:

Mecklenburg-Vorpommern: an einigen Gemeinde place-Objekten is_in und Gemeindeschlüssel korrigiert; Rheinland-Pfalz: an Gemeinderelation Herdorf admin_level von 7 auf 8 geändert

Eigentlich wäre level 7 aber die sinnvollere Einordnung

Das passt aber nicht zu den Gemeinden in NRW, die alle 8 sind, und amtsfrei.

Gruß,
ajoessen

Sicher würde Level7 passen ... in NRW gibt es kein level 7 eben weil es keine Ämter oder Verbandsgemeinden gibt. In den Bundesländern wo es die gibt, gibt es dafür level 7

misterboo wrote:

ajoessen wrote:

Kennt jemand den Unterschied ziwschen:
http://www.openstreetmap.org/browse/relation/611092
http://www.openstreetmap.org/browse/relation/611084

soll beides admin_level 7 Bad Kreuznach sein.
AGS 0713301 ist aber nicht vergeben.

gruß,
ajoessen

http://www.openstreetmap.org/browse/relation/611084

Das ist die Stadt Bad Kreuznach mit der AGS 07133006 - sollte aber level 8 sein

http://www.openstreetmap.org/browse/relation/611092

Das ist die Verbandsgemeinde Bad Kreuznach in getaggt mit der AGS 0713301

Level 7 ist korrekt ... der AGS aber nicht denn eine Verbandsgemeinde hat keinen AGS sonder einen Regionalschlüssel

der ist korrekt: 07 1 33 5001

und zeigt das dringend ein einheitliches Tagging erforderlich ist.

Args, Bd Kreuznach ist nicht Teil der Verbandsgemeinde Bad Kreuznach, aber beides im Kreis Bad Kreuznach.
Da soll noch einer durchblicken :-(

Gruß,
ajoessen

Hey Misterboo,

eine Super Arbeit hast du da geleistet mitdeiner Kartendarstellung! Lob!!

Im Nord-Osten von Niedeersachsen stieß ich auf folgendes: Viele Gemeinden im den Landkreisen Harburg und Lüneburg werden mit deren OSM-Relationsnummer NICHT angezeigt (nur Wikipedia-Verweis). Ich vermute, dass dies vielleicht am name= tag liegen könnte, denn hier tragen (u.a. seit kurzem erst) viele Gemeinden auf admin_level=7 oder =8 den tag name=Gemeinde XXX

Kann daran eine richtige Zuordnungder Grenzrelationen zu deiner Liste der AGS scheitern?

Sollte der Zusatz "Gemeinde" nicht eher als name:prefix= getaggt werden?

Und ganz wichtig für mich (fast verbindlich) zu wissen: Wann soll eine einzelne Gemeinde denn nun admin_level=7 oder =8 haben??

Denn hier wurden viele Grenzpolygone auf =7 geändert, welche meiner Meining nach =8 bleiben sollten. Ich plane da sogar schon ein Revert des Changeset Nr. 10394459

Gruß, Stephan

stephan75 wrote:

Hey Misterboo,

eine Super Arbeit hast du da geleistet mitdeiner Kartendarstellung! Lob!!

Im Nord-Osten von Niedeersachsen stieß ich auf folgendes: Viele Gemeinden im den Landkreisen Harburg und Lüneburg werden mit deren OSM-Relationsnummer NICHT angezeigt (nur Wikipedia-Verweis). Ich vermute, dass dies vielleicht am name= tag liegen könnte, denn hier tragen (u.a. seit kurzem erst) viele Gemeinden auf admin_level=7 oder =8 den tag name=Gemeinde XXX

Die Zuordnung soll über den AGS funktionieren, nicht über den Namen.

Kann daran eine richtige Zuordnungder Grenzrelationen zu deiner Liste der AGS scheitern?

Sollte der Zusatz "Gemeinde" nicht eher als name:prefix= getaggt werden?

Wenn es mißveverständlich sein, kann, weil es Kreis, Stadt und Verbandsgemeide mit gleichem Namen gibt (wie oben Bad Kreuznach), macht dier Vorsatz Sinn.

Und ganz wichtig für mich (fast verbindlich) zu wissen: Wann soll eine einzelne Gemeinde denn nun admin_level=7 oder =8 haben??

Besorg dir diese Excel-Tabelle:
http://www.destatis.de/jetspeed/portal/ … y=file.xls
Da steht drin, welche gemeinden zu Verbandsgemeinden gehören, und welche nicht.

Denn hier wurden viele Grenzpolygone auf =7 geändert, welche meiner Meining nach =8 bleiben sollten. Ich plane da sogar schon ein Revert des Changeset Nr. 10394459

Das lass mal lieber bleiben. Z.B. Embsen ist dort geändert, aber auch in der App zu finden. Frag lieber smarties, warum er was geändert hat.
Richtschnur sollte das Wiki sein:
http://wiki.openstreetmap.org/wiki/DE:G … evel.3D7-9

Gruß,
ajoessen

stephan75 wrote:

Hey Misterboo,

eine Super Arbeit hast du da geleistet mitdeiner Kartendarstellung! Lob!!

Im Nord-Osten von Niedeersachsen stieß ich auf folgendes: Viele Gemeinden im den Landkreisen Harburg und Lüneburg werden mit deren OSM-Relationsnummer NICHT angezeigt (nur Wikipedia-Verweis). Ich vermute, dass dies vielleicht am name= tag liegen könnte, denn hier tragen (u.a. seit kurzem erst) viele Gemeinden auf admin_level=7 oder =8 den tag name=Gemeinde XXX

Kann daran eine richtige Zuordnungder Grenzrelationen zu deiner Liste der AGS scheitern?

Sollte der Zusatz "Gemeinde" nicht eher als name:prefix= getaggt werden?

Und ganz wichtig für mich (fast verbindlich) zu wissen: Wann soll eine einzelne Gemeinde denn nun admin_level=7 oder =8 haben??

Denn hier wurden viele Grenzpolygone auf =7 geändert, welche meiner Meining nach =8 bleiben sollten. Ich plane da sogar schon ein Revert des Changeset Nr. 10394459

Gruß, Stephan

Ich habe das für den Anfang mal absichtlich gemacht um mögliche Ungereimtheiten erkennen zu können und darüber auch diskutieren zu können.

Ich suche bei den Gemeinden nach admin_level=8 und nach einem vorhandenen 8 stelligen AGS

Beispiel: Adendorf mit dem AGS 03355001 im Landkreis Lüneburg in Niedersachsen

Die wird in meiner Liste nicht zugeordnet weil es mit admin_level=7 getaggt ist.

Das ist auch gar nicht so verkehrt weil es eine verbandsfreie Gemeinde ist und auch im amtlichen Gemeindeverzeichnis auf dieser Ebene ist.

somit könnte ein Auswerter leicht die verbandsfreien, amtsfreien, kreisfreien oder auch Städte finden, die ja auch Bundesländer sind.

Da das aber momentan noch nicht einheitlich ist, lasse ich meine Suche so, damit man das Problem sieht und ein einheitliches Tagging finden kann.

Also das ist mein Vorschlag: admin_level: jeweils das obere Level, also 3 bei kreisfreien Städten und 7 bei den amtsfreien und verbandsfreien Gemeinden, aber dafür immer den vollen 8 Stelligen ags. Oder natürlich besser noch: auf den 12 Stelligen Regionalschlüssel wechseln, dann gibt es auch keine Probleme wie jetzt, wie man die Verbandsgemeinden taggt.

Zum Zusatz: diese sollten tatsächlich alle einheitlich in name:prefix= getaggt werden

Und noch mal mein Apell: Die Verbandsgemeinden sind momentan das größte Problem. Der AGS ist nicht für Verbandsgemeinden vorgesehen, sondern der Regionalschlüssel. Aus dem Grund ist das Tagging der Verbandsgemeinden auch recht chaotisch und das eintragen einer Nummer in de:amtlicher_gemeindeschluessel für die Ämter oder Verbandsgemeinden erschwert das Auswerten und damit sinkt auch die Qualität der Daten.

Weil es da noch keine Vorgaben gibt, nehmen manche de:regionalschluessel, manche lassen die Nummer ganz weg, manche nehmen 2 Ziffern oder 4 Ziffern in den AGS, eine Auswertung ist somit fast nicht möglich.

Mal noch ein weiteres Beispiel für die Auswertung:

Hamburg hat als Bundesland admin_level=4 und de:amtlicher_gemeindeschluessel=04
Ich erkenne daran nicht dass Hamburg auch eine Stadt ist und kann das somit nicht auswerten

mit admin_level=4 und de:amtlicher_gemeindeschluessel=04000000

wäre eine korrekte Auswertung(Bundesland + Stadt) möglich

Hier vielleicht nochmal ein Hinweis auf eine Möglichkeit zur grafischen/optischen Kontrolle der Gemeindegrenzen nebst Tagging in JOSM:

Grundlagen sind hier beschrieben:
http://wiki.openstreetmap.org/wiki/MapCSS/Examples

in Kurzform:

1. OSM-Daten besorgen für z.B. ein Bundesland oder ganz Deutschland
2. Daten filtern via osmfilter inkl. --drop-authors und --keep="boundary=administrative"
3. ALTERNATIV zu 1. und 2.: Daten besorgen mit Bedingung "boundary=administrative" über Overpass_API o.ä. ?
4. Render-Stil für JOSM als Textdatei aus dem MapCSS/Example abspeichern und ggf. anpassen
5. in den Mappaint-Einstellungen von JOSM diese Stil-Datei laden

in der MapCSS-Datei könnte man z.B. die Regel
text: admin_level;
durch
text: "de:amtlicher_gemeindeschluessel";
oder
text: name;
ersetzen.

ajoessen wrote:

stephan75 wrote:

Hey Misterboo,

eine Super Arbeit hast du da geleistet mitdeiner Kartendarstellung! Lob!!

Im Nord-Osten von Niedeersachsen stieß ich auf folgendes: Viele Gemeinden im den Landkreisen Harburg und Lüneburg werden mit deren OSM-Relationsnummer NICHT angezeigt (nur Wikipedia-Verweis). Ich vermute, dass dies vielleicht am name= tag liegen könnte, denn hier tragen (u.a. seit kurzem erst) viele Gemeinden auf admin_level=7 oder =8 den tag name=Gemeinde XXX

Die Zuordnung soll über den AGS funktionieren, nicht über den Namen.

Kann daran eine richtige Zuordnungder Grenzrelationen zu deiner Liste der AGS scheitern?

Sollte der Zusatz "Gemeinde" nicht eher als name:prefix= getaggt werden?

Wenn es mißveverständlich sein, kann, weil es Kreis, Stadt und Verbandsgemeide mit gleichem Namen gibt (wie oben Bad Kreuznach), macht dier Vorsatz Sinn.

Und ganz wichtig für mich (fast verbindlich) zu wissen: Wann soll eine einzelne Gemeinde denn nun admin_level=7 oder =8 haben??

Besorg dir diese Excel-Tabelle:
http://www.destatis.de/jetspeed/portal/ … y=file.xls
Da steht drin, welche gemeinden zu Verbandsgemeinden gehören, und welche nicht.

Denn hier wurden viele Grenzpolygone auf =7 geändert, welche meiner Meining nach =8 bleiben sollten. Ich plane da sogar schon ein Revert des Changeset Nr. 10394459

Das lass mal lieber bleiben. Z.B. Embsen ist dort geändert, aber auch in der App zu finden. Frag lieber smarties, warum er was geändert hat.
Richtschnur sollte das Wiki sein:
http://wiki.openstreetmap.org/wiki/DE:G … evel.3D7-9

Gruß,
ajoessen

Hi,

ich und Stephan75 lösen das per E-Mail.

Ich habe mich in Niedersachsen bisher daran gehalten:
Landkreise = level 6
Samtgemeinden = Level 7
Gemeinden = Level 8
Ortsgrenze = Level 9

Da Einheitsgemeinden eine Zusammenlegung mehrerer Gemeinden sind, sollten Sie wie Samtgemeinden behandelt werden die ja ebenfalls ein Verbund von mehreren Gemeinden sind. Seit die Einheitsgemeinden gegründet wurden, werden die alten Gemeindegrenzen von der Politik-Verwaltung zwar ignoriert aber von Traditionsvereinen wie z.B. Feuerwehr oder Schützenverein noch streng getrennt.

smarties wrote:

ich und Stephan75 lösen das per E-Mail.

Ich habe mich in Niedersachsen bisher daran gehalten:
Landkreise = level 6
Samtgemeinden = Level 7
Gemeinden = Level 8
Ortsgrenze = Level 9

Dann tragt das Ergebnis bitte auf der Wiki-Seite
http://wiki.openstreetmap.org/wiki/DE:G … evel.3D7-9
ein, damit nachfolgende auch was davon haben.

Gruß,
ajoessen

Ich war von Anfang an skeptisch - zurecht.

Nun wurde hier schon wieder eine Gemeinde nachgetragen, welche aber bereits in eine andere eingemeindet wurde. Und das auch noch vom Tool-Ersteller. Validator-Bingo.

monotar wrote:

Ich war von Anfang an skeptisch - zurecht.

Nun wurde hier schon wieder eine Gemeinde nachgetragen, welche aber bereits in eine andere eingemeindet wurde. Und das auch noch vom Tool-Ersteller. Validator-Bingo.

Sorry, das war natürlich keine Absicht ... ich hatte heute ein paar Grenzen eingetragen, bei denen es schon gleichnamige PLZ Gebiete gab. Die meisten hatte ich visuell noch mit den SVG Dateien in Wikipedia abgeglichen. Welche Gemeinde war denn falsch ?

Ah ... Mengersgereuth-Hämmern und Mutzschen

Dabei habe ich noch extra in meine Hilfe geschrieben, dass OSM teilweise aktueller ist und schon die Eingemeindungen z.B 2012 in THüringen drin hat ...

PS: Als Validator Depp möchte ich trotzdem nicht gerne beschimpft werden

http://www.openstreetmap.org/browse/relation/1300370

Ein etwas anderer Umgangston würde dir sicher nicht schaden.

Moin misterboo,

es werden in der hiesigen Gegend keine Gemeindeverbände zur Listenauswahl gestellt. Zum Beispiel in Niedersachsen -> Landkreis Aurich gibt es zwei nicht auftauchende Samtgemeinden:

Samtgemeinde Brookmerland http://www.openstreetmap.org/browse/relation=898627
und
Samtgemeinde Hage http://www.openstreetmap.org/browse/relation/898196

Liegt das an einem Mangel in der Statistik oder an der Anwendung?

Ein Erweiterungsvorschlag: Wäre es möglich, auch die Ortsteilgrenzen in der Anwendung sichtbar zu machen? Als Beispiel nenne ich mal den

Stadtteil Norddeich http://www.openstreetmap.org/browse/relation/931827
der
Stadt Norden http://www.openstreetmap.org/browse/relation/898195

Man könnte dazu alle niedrigen admin level innerhalb eines Ortes auswerten. Überhaupt wäre etwas in der Richtung "Was gehört wozu" sinnvoll: Kommunen in Kreisen, Kommunen in Samtgemeinden, Kreise in Bundesländern oder Bundesländer in Deutschland. Man könnte das an dem Wert des admin level festmachen. So hätte man einen besseren Überblick, wie komplett man ist. Wenn dann noch das Vierfarben Theorem zur Anwendung käme, und man das Ergebnis zum weiteren Gebrauch exportieren könnte, wäre das ein Sahnehäubchen:
http://de.wikipedia.org/wiki/Vier-Farben-Satz

Grüße
Tirkon

Tirkon wrote:

Moin misterboo,

es werden in der hiesigen Gegend keine Gemeindeverbände zur Listenauswahl gestellt. Zum Beispiel in Niedersachsen -> Landkreis Aurich gibt es zwei nicht auftauchende Samtgemeinden:

Samtgemeinde Brookmerland http://www.openstreetmap.org/browse/relation=898627
und
Samtgemeinde Hage http://www.openstreetmap.org/browse/relation/898196

Liegt das an einem Mangel in der Statistik oder an der Anwendung?

Ein Erweiterungsvorschlag: Wäre es möglich, auch die Ortsteilgrenzen in der Anwendung sichtbar zu machen? Als Beispiel nenne ich mal den

Stadtteil Norddeich http://www.openstreetmap.org/browse/relation/931827
der
Stadt Norden http://www.openstreetmap.org/browse/relation/898195

Man könnte dazu alle niedrigen admin level innerhalb eines Ortes auswerten. Überhaupt wäre etwas in der Richtung "Was gehört wozu" sinnvoll: Kommunen in Kreisen, Kommunen in Samtgemeinden, Kreise in Bundesländern oder Bundesländer in Deutschland. Man könnte das an dem Wert des admin level festmachen. So hätte man einen besseren Überblick, wie komplett man ist. Wenn dann noch das Vierfarben Theorem zur Anwendung käme, und man das Ergebnis zum weiteren Gebrauch exportieren könnte, wäre das ein Sahnehäubchen:
http://de.wikipedia.org/wiki/Vier-Farben-Satz

Grüße
Tirkon

Wie schon weiter oben geschrieben: Es gibt momentan noch kein einheitliches Tagging Schema bei den Gemeindeverbänden und auch nicht bei den Ortsteilen bezüglich einer einheitlichen Kennung. Der amtliche Gemeindeschlüssel ist dafür nicht geeignet. Daher auch noch keine Auswertung dieser Grenzen.

Hey misterboo,
was dein Tool schon sehr schön zeigen kann, sind die nicht geschlossenen Grenzpolygone.

Ganz aktuell hat wohl ein neuer Mapper in Nordfriesland einige Lücken gehauen, wo deine Fehlerauswertung DERZEIT fünf Fehler aufzeigt.

Ursächlich ist wohl diese Änderung: http://www.openstreetmap.org/browse/changeset/10475148

PS: das laden der schadhaften Relationen in in JOSM via Remote-Plugin klappt übrigens super! ;-)

stephan75 wrote:

Ganz aktuell hat wohl ein neuer Mapper in Nordfriesland einige Lücken gehauen, wo deine Fehlerauswertung DERZEIT fünf Fehler aufzeigt.

Ursächlich ist wohl diese Änderung: http://www.openstreetmap.org/browse/changeset/10475148

ui, einen Tag dabei, 25 Relationen mit Potlatch angefasst und jede Menge Wege und Nodes gelöscht. Vermutlich wäre es das beste, wenn man das Changeset zurück setzt und den User anschreibt

Bergenhusen (1157800) und Meggerdorf (1157802) habe ich gerade korrigiert.

Was macht man am besten mit den 5 nicht geschlossenen Relationen des neuen Users in Schleswig-Holstein. Wenn da aus Versehen noch mehr gelöscht wurde, sollte man evt. eher das Changeset rückgängis machen oder ?

Was nebenher FÜR einen Total-Revert spricht sind die mehreren benamten landuse-Flächen pro Dorf, welche knulli04 dort eingefügt hat.

Ich bin für einen Revert, solange es noch geht (soll Frederik mal schauen?) ... und Kommunikation mit dem User dort.

beides erledigt

SunCobalt wrote:

beides erledigt

Danke!

Mit heutigem Datum zeigt ags.misterboo.de insgesamt noch 147 Fehler des Typs 2

Sind dies somit Gemeinden aus der großen AGS-Liste, zu denen also keine Grenzrelation in den OSM-Daten gefunden werden konnte? Oder umgekehrt: Grenzrelationen in den OSM-Daten, denen kein AGS zugeordnet wurde?

Wenn ersteres zutrifft, so sollte vielleicht die Beschreibung des Fehlertyps 2 auf misterboo.de geändert werden, oder?

Die meisten "fehlenden" Gemeinden entfallen wohl noch auf Niedersachsen. Um deren Grenzen für OSM noch erfassen zu können, gäbe es ja vielleicht eine Grundlage in der dt. Wikipedia.
Da gibt es sogar ein eigenes Projekt zur Pflege der Landkreiskarten:
http://de.wikipedia.org/wiki/Wikipedia: … reiskarten

Um generell herauszufinden, wo in Niedersachsen noch Gemeindegrenzen mit admin_level=7 oder =8 fehlen, hab ich mal alle vorhandenen Grenzen mittels JOSM dargestellt, siehe http://wiki.openstreetmap.org/wiki/MapCSS/Examples

Dabei fiel mir auf, dass folgende Grenzrelationen zwar einen AGS gespeichert haben, aber keinen Namen!
1184612 ... AGS=03255019
1184616 ... AGS=03255034
1184624 ... AGS=03255003
1418992 ... AGS=03459005

Die 4 ohne Namen waren von mir, ich hatte etwa 40 Grenzen gefunden, die schon als PLZ Grenzen da waren und bei den 4 vergessen, die Namen nachzutragen.

Habe ich gerade erledigt

Die fehlenden Grenzen in Niedersachsen sind teilweise als PLZ Grenzen vorhanden und müssten nur noch aufgeteilt werden, da die PLZ Grenze für mehrere Gemeinden ist. Den genauen Verlauf kann man annähernd in den SVG Umrissen bei Wikipedia erkennen.

Es können noch ein paar mehr nicht zugeordnet werden, das liegt aber daran dass es Anfang 2012 mehrere Eingemeindungen gab in Thüringen und Sachsen. Da ich aus Versehen selbst so eine Gemeinde "angefasst" habe ohne zuerst bei Wikipedia nachzusehen, habe ich diese jetzt aus den Fehlern rausgenommen.

In Niedersachsen denke ich gab es keine Eingemeindungen Anfang des Jahres, die restlichen Fehler sind also meist noch fehlende Gemeindegrenzen.

Habe mir mal die derzeit 147 "fehlenden" Gemeinden per copy/paste in eine Tabellenkalkulation geholt und nach AGS sortiert zwecks Einteilung in Landkreise.

Dabei fielen mir folgende Einzelfälle auf:

(die AGS von misterboo's Seite als Werte am Zeilenanfang weichen von denen in den OSM-Daten ab)

03153016: Braunlage ... hat derzeit 03 1 53 003

03158038: Börßum ... hat derzeit 03 1 58 003

03255501: Boffzen ... hat derzeit 03 2 55 004

03255012: Eimen und 03255502: Eimen ... doppelt?

03255503: Eschershausen ... hat 03 2 55 013

03255505: Holzminden ... hat derzeit 03 2 55 023

03352059: Beverstedt ...hat derzeit 03352005

03354501: Gartow ... derzeit 03 3 54 005

03354502: Göhrde ... derzeit 03354006

03360030: Wrestedt ... derzeit 03 3 60 028

03454009: Dohren ...hat derzeit 03353006 falls identisch!?

03457002: Borkum hat 03457002 ... wird als Fehler angezeigt ...adminlevel von 9 auf 8 setzen??

Welche AGS-Werte sind denn nun zutreffend?

Gruß, Stephan

Ich habe gerade mal das erste Beispiel Braunlage kontrolliert.

Ich habe gerade vor ein paar Tagen die aktuellsten Daten vom 31.11.2011 eingelesen in die Datenbank

http://www.destatis.de/jetspeed/portal/ … Print.psml

ist den neuen Daten ist die AGS von Braunlage 03153016, in der AGS Liste vom 31.09 war sie noch 03153003

Hat jemand aus der Gegend evt. genauere Infos ob das ein Fehler in der amtlichen Liste ist oder ob es da eine Änderung gab bei Gemeindeschlüssel ?

Edit:

Ich habe gerade mal nachgesehen auf der offiziellen Seite der Stadt:

http://www.stadt-braunlage.de/index.php … &Itemid=51

Dort steht der Gemeindeschlüssel wie im amtlichen Verzeichnis: 03153016

Ich vermute, dies ist der Grund: "Die Fusion der Stadt Braunlage und der Bergstadt St. Andreasberg erfolgt somit zum 01. November 2011."

Bei den anderen Gemeinden sollte man dann jeweils auch nachsehen ob es da Änderungen gab ...

...gelöscht

03354501: Gartow ... derzeit 03 3 54 005

03354502: Göhrde ... derzeit 03354006

Laut Gemeindeverzeichnis stimmen die derzeitigen Nummern.
Es gibt aber noch ein Göhrde (gemeindefreies Gebiet) und ein Gartow (gemeindefreies Gebiet). Diese beiden sind nocht nicht in OSM eingepflegt.
Hiernach besitzen sie die anderen Nummern.

OPerivar wrote:

03354501: Gartow ... derzeit 03 3 54 005

03354502: Göhrde ... derzeit 03354006

Laut Gemeindeverzeichnis stimmen die derzeitigen Nummern.

Habe ich doch gerade erklärt 🙂 Die Änderungen sind in den aktuellen Daten vom 31.12.2011

Die Onlineabfrage hat noch alte Daten vom 31.12.2010

Hier ist der Link zur Excel Datei mit den aktuellsten Daten vom 31.12.2011

http://www.destatis.de/jetspeed/portal/ … y=file.xls

Aber auch da beachten: Anfang des Jahres gab es auch wieder einige Eingemeindungen besonders in Thüringen und Sachsen.

Falls es aktuell eine offizielle Änderung bestimmter AGS gab, so muss es doch darüber eine Verordnung oder Veröffentlichung geben, oder?

Edit: hab was gefunden:
http://www.destatis.de/jetspeed/portal/ … Print.psml

Gemeindefreie Gebiete und Änderungen (in Klammern: weitere AGS, die jetzt zur "neuen" AGS gehören):

03153016 ->neu: Braunlage ... hat derzeit 03153003 -> alt (auch 03153010 war Sankt Andreasberg, Bergstadt

03158038 ->neu: Börßum ... hat derzeit 03158003 -> alt (auch 03158001)

03255501 -> Boffzen, gemfr. Gebiet: Boffzen ... hat derzeit 03255004 ->Gemeinde

03255012 -> Gemeinde: Eimen und 03255502: Eimen ... doppelt? -> Eimen, gemfr. Gebiet

03255503 -> Eschershausen, gemfr. Gebiet: Eschershausen ... hat 0325013 -> Gemeinde

03255505 -> Holzminden, gemfr. Gebiet: Holzminden ... hat derzeit 03255023 -> Gemeinde

03352059 -> neu: Beverstedt ...hat derzeit 03352005 -> alt (auch 03352001 , 03352006 , 03352017 03352021 , 03352023 , 03352026 , 03352033 , 0335201753)

03354501 ->gemeindefrei: Gartow ... derzeit 03354005 -> Gemeinde

03354502 ->gemeindefrei: Göhrde ... derzeit 03354006 -> Gemeinde

03360030 -> neu: Wrestedt ... derzeit 03 3 60 028 -> alt ( auch 03360027 , 03360021)

03454009 -> Regierungsbezirk Weser-Ems: Dohren ...hat derzeit 03353006 -> Regierungsbezirk Lüneburg falls identisch!?

03457002: Borkum hat 03457002 ... wird als Fehler angezeigt ...adminlevel von 9 auf 8 setzen??

ps: Alle Angaben ohne Gewähr

in Anbetracht der nicht wenigen Eingemeindungen:

Könnte man nicht auch einen Check in ags.misterboo.de einbauen, ob es in den OSM-Daten amtl. Gemeindeschlüssel gibt, die in der Liste von destatis.de nicht (mehr) vorhanden sind? Quasi ein neuer Fehlertyp?

Stephan

http://ags.misterboo.de/

Die Gemeindegrenzen sind nun fast komplett. 13 gemeindefreie Gebiete in Niedersachsen kann ich leider mangels Ortskenntnis nicht zuordnen. Wäre schön wenn die noch jemand ergänzen könnte.

Bis auf ein gemeindefreies Gebiet in RLP (Gemeinsames deutsch-luxemburgisches Hoheitsgebiet) sind die Gemeindegrenzen nun komplett 🙂

http://de.wikipedia.org/wiki/Gemeinsame … eitsgebiet

Dann möchte ich auch bald die Gemeindeverbände in meiner kleinen App freischalten zum überprüfen. Allerdings wäre es praktisch wenn wir uns da auf ein Taggingschema einigen könnten.

Bisher ist da kein einheitliches Schema erkennbar. Manche taggen die amtliche Nummer im Gemeindeschlüssel. Der ist aber gar nicht für Gemeindeverbände vorgesehen sondern der (12-stellige) Regionalschlüssel.

Daher würde ich vorschlagen, alle Gemeindeverbände mit de:regionalschluessel zu taggen und später bei allen Gemeinden den Regionalschlüssel ebenfalls noch per BOT zu ergänzen was ja dann recht leicht ist, da nun (fast) alle Gemeindegrenzen erfasst sind.

Auch würde ich gerne nochmal die einheitliche Schreibweise ansprechen. Da der überwiegende Teil den Gemeindeschlüssel zusammen schreibt sollten wir das auch generell so machen.

Könnte sich jemand mal bitte die beiden Deutschland Relationen ansehen, ob da was kaputt ist momentan ?

62781
51477

Nachdem ich endlich mal rausgefunden habe, wie ich überhaupt die großen Relationen in Josm laden kann (mit der overpas api) scheint da wirklich etwas kaputt zu sein.

Ein Stück an der Deutsch-Tschechischen Grenze ist unterbrochen

Da ich bisher noch nie solch eine große Relation bearbeitet habe und schon bei kleineren gemerkt habe, dass der Upload mit Josm ewig dauert: Mit welcher Zeitspanne muss ich denn ungefähr rechnen um so eine große Relation wie Deutschland hochzuladen ?

hmm ... gerade mal ausprobiert ... ging sogar schnell 51477 sollte wieder geschlossen sein

Bei 62781 (Deutschland Landmasse) scheint momentan einiges mehr zu fehlen ... könnte sich das mal jemand ansehen ?

Sollte wieder passen.

umeier wrote:

Sollte wieder passen.

hmm ... habe gerade nochmal die 62781 runtergeladen und überprüft, da fehlt noch einiges im Norden ...

misterboo wrote:

umeier wrote:

Sollte wieder passen.

hmm ... habe gerade nochmal die 62781 runtergeladen und überprüft, da fehlt noch einiges im Norden ...

Örx ... Ich hatte die Relation in JOSM auf Geschlossenheit geprüft, zwei Ways irgendwo in Ostbayern reingebaut und dann war JOSM eigentlich wieder zufrieden ...

habs nochmal runtergeladen ... war wohl eben etwas zu kurz nach deiner Änderung ... jetzt stimmt es wieder

Die App zeigt für den Landkreis Wunsiedel im Fichtelgebirge einen Fehler mit AGS 09479444 der nicht zugeordnet werden kann.
In der excel-Datei von Destatis werden offenbar die 10 einzelnen Gemeindefreien Gebiete zu diesen einzigen AGS zusammengefasst, obwohl in den
Daten der Bay.Verm.Verw. (Shape-Datei, Gemeindegrenzen) einzelne AGS aufgeführt sind. Soweit ich das sehe, erfolgt in der Destatis-Datei diese Zusammenfassung jeweils für alle Landkreise , die dann einen "Pseudoschlüssel" mit der Endung *9444 haben.

geodreieck4711 wrote:

Die App zeigt für den Landkreis Wunsiedel im Fichtelgebirge einen Fehler mit AGS 09479444 der nicht zugeordnet werden kann.
In der excel-Datei von Destatis werden offenbar die 10 einzelnen Gemeindefreien Gebiete zu diesen einzigen AGS zusammengefasst, obwohl in den
Daten der Bay.Verm.Verw. (Shape-Datei, Gemeindegrenzen) einzelne AGS aufgeführt sind. Soweit ich das sehe, erfolgt in der Destatis-Datei diese Zusammenfassung jeweils für alle Landkreise , die dann einen "Pseudoschlüssel" mit der Endung *9444 haben.

Ja das ist richtig. die einzelnen gemeindefreien Gebiete haben in dem amtlichen Verzeichnis alle die Endung 9444 ... Ich habe auch beim Landkreis Wunsiedel mal nachgefragt. Zumindest in Bayern haben alle gemeindefreien Gebiete einzelne Nummern, im Gemeindeverzeichnis sind sie aber alle unter 9444 zusammengefasst.

Ob das jetzt in anderen Bundesländern mit gemeindefreien Gebieten auch so ist, kann ich aber nicht sagen.

Das neueste Update der OSM Datenbank zeigt einige neue Fehler:

http://ags.misterboo.de

ich habe nur mal die ersten beiden kontrolliert:

http://www.openstreetmap.org/browse/relation/1285614
http://www.openstreetmap.org/browse/relation/1285606

Da ersetzt ein Kollege wohl den 8 stelligen Gemeindeschlüssel mit dem 12 stelligen Regionalschlüssel

Dann stimmt aber leider der tag nicht mehr und eine Auswertung ist dann nicht mehr zuverlässig möglich.

de:regionalschluessel gibt es ja schon vereinzelt, das wäre auch der korrekte Tag dafür. So durcheinander wie jetzt ist das falsch und erlaubt keine einfache Auswertung mehr.

In der Tat sind das wohl aktuelle Änderungen durch den User http://www.openstreetmap.org/user/ludwich

Fürmich ist das schon fast ein Fall für einen Revert der Changesets.

Wenn er denn den regionalschlüsel eintragen will, dann auch unter dem richtigen Key.

Wegen Zeitmangel: mag mal wer den ludwich anschreiben, ob er selbst korrigiert oder reverted werden soll?

stephan75 wrote:

Wegen Zeitmangel: mag mal wer den ludwich anschreiben, ob er selbst korrigiert oder reverted werden soll?

Done.

ajoessen

ajoessen hat nun schon eine schöne Arbeit gemacht und die Gemeinden in NRW mit dem Regionalschlüssel versehen

als Tag hat er analog zum Gemeindeschlüssel

de:amtlicher_regionalschluessel

hier auch noch die Info dazu im Wiki:

http://wiki.openstreetmap.org/wiki/DE:K … schluessel

könnte evt. auch noch jemanden den Wiki Eintrag zum Gemeindeschlüssel etwas aktualisieren (ich habe immer noch keinen Account im Wiki)

http://wiki.openstreetmap.org/wiki/DE:A … .C3.BCssel

dort steht noch etwas von Vorschlag und de:osm_gemeindeschluessel

In den OSM Daten sind noch einige alte tags mit de:regionalschluessel drin ... evt könnte jemand diese dann einheitlich
in de:amtlicher_regionalschluessel umändern

misterboo wrote:

ajoessen hat nun schon eine schöne Arbeit gemacht und die Gemeinden in NRW mit dem Regionalschlüssel versehen

als Tag hat er analog zum Gemeindeschlüssel

de:amtlicher_regionalschluessel

hier auch noch die Info dazu im Wiki:

http://wiki.openstreetmap.org/wiki/DE:K … schluessel

könnte evt. auch noch jemanden den Wiki Eintrag zum Gemeindeschlüssel etwas aktualisieren (ich habe immer noch keinen Account im Wiki)

http://wiki.openstreetmap.org/wiki/DE:A … .C3.BCssel

dort steht noch etwas von Vorschlag und de:osm_gemeindeschluessel

In den OSM Daten sind noch einige alte tags mit de:regionalschluessel drin ... evt könnte jemand diese dann einheitlich
in de:amtlicher_regionalschluessel umändern

Wiki ist aufgeräumt; auch mit Links untereinander.
Den Restmüll im Datenbestand mach ich am Wochenende.

Gruß,
ajoessen

ajoessen wrote:

misterboo wrote:

ajoessen hat nun schon eine schöne Arbeit gemacht und die Gemeinden in NRW mit dem Regionalschlüssel versehen

als Tag hat er analog zum Gemeindeschlüssel

de:amtlicher_regionalschluessel

hier auch noch die Info dazu im Wiki:

http://wiki.openstreetmap.org/wiki/DE:K … schluessel

könnte evt. auch noch jemanden den Wiki Eintrag zum Gemeindeschlüssel etwas aktualisieren (ich habe immer noch keinen Account im Wiki)

http://wiki.openstreetmap.org/wiki/DE:A … .C3.BCssel

dort steht noch etwas von Vorschlag und de:osm_gemeindeschluessel

In den OSM Daten sind noch einige alte tags mit de:regionalschluessel drin ... evt könnte jemand diese dann einheitlich
in de:amtlicher_regionalschluessel umändern

Wiki ist aufgeräumt; auch mit Links untereinander.
Den Restmüll im Datenbestand mach ich am Wochenende.

Gruß,
ajoessen

Wenn du so nett wärst und das in der Datenbank auch umschlüsseln könntest. Ich meine nur weil die tags in der Wiki geändert werden machen die Mapper das ja nicht in der DB auch sofort.

viw wrote:

Wenn du so nett wärst und das in der Datenbank auch umschlüsseln könntest. Ich meine nur weil die tags in der Wiki geändert werden machen die Mapper das ja nicht in der DB auch sofort.

Das ist nicht so einfach bei 16000 Relationen. Es wird ja dummerweerise in der Mitte was hinzugefügt, was sich nur durch Blick in die amtliche Tabelle erfahren lässt.

Gruß,
ajoessen

ajoessen wrote:

Den Restmüll im Datenbestand mach ich am Wochenende.

Ist jetzt soweit erledigt, was die Einträge von l. angeht, und diverse Schreibweisen der schluessel/schlüssel.
Die AGS müssten damit alle wieder fehlerfrei sein.

Wer hat sich eigentlich den Begriff "amtlicher Regionalschlüssel" ausgedacht? In den destatis-Tabellen und bei Wikipedia ist immer nur von Regionalschlüssel (RS) die Rede.

Gruß,
ajoessen

wiki wrote:

Tagging An die Grenzrelationen wird der Schlüssel de:amtlicher_regionalschluessel=* mit dem Regionalschlüssel ohne Leerzeichen als Wert gesetzt. Der Regionalschlüssel ist auf die Anzahl Stellen zu kürzen die dem admin_level=* entsprechen also zum Beispiel de:amtlicher_regionalschluessel=14713

Ein komplettes Beispiel für Leipzig:

type=multipolygon
+boundary=administrative
+admin_level=6
+name=Leipzig, Stadt
+de:amtlicher_regionalschluessel=14713

kann ich jetzt nicht zählen oder hat sich das wiki verzählt?
Das Beispiel verwirrt..............

geodreieck4711 wrote:

wiki wrote:

Tagging An die Grenzrelationen wird der Schlüssel de:amtlicher_regionalschluessel=* mit dem Regionalschlüssel ohne Leerzeichen als Wert gesetzt. Der Regionalschlüssel ist auf die Anzahl Stellen zu kürzen die dem admin_level=* entsprechen also zum Beispiel de:amtlicher_regionalschluessel=14713

Ein komplettes Beispiel für Leipzig:

type=multipolygon
+boundary=administrative
+admin_level=6
+name=Leipzig, Stadt
+de:amtlicher_regionalschluessel=14713

kann ich jetzt nicht zählen oder hat sich das wiki verzählt?
Das Beispiel verwirrt..............

das war die Frage wie wie mit kreisfreien Städten umgehen sollen ...

ich würde sagen: admin-level=6 und AGS und RGS mit Nullen aufgefüllt (so ist es auch im Gemeindeverzeichnis)

so wie das beispiel jetzt ist kann man es nicht von einem normalen Land Kreis unterscheiden

wenn das OK ist sollte jemand das noch ändern im Wiki

ajoessen wrote:

ajoessen wrote:

Den Restmüll im Datenbestand mach ich am Wochenende.

Ist jetzt soweit erledigt, was die Einträge von l. angeht, und diverse Schreibweisen der schluessel/schlüssel.
Die AGS müssten damit alle wieder fehlerfrei sein.

Wer hat sich eigentlich den Begriff "amtlicher Regionalschlüssel" ausgedacht? In den destatis-Tabellen und bei Wikipedia ist immer nur von Regionalschlüssel (RS) die Rede.

Gruß,
ajoessen

ich dachte du hättest den WIKI Artikel geschrieben ?

in der DB sind bisher 191 x de:regionalschluessel und 742 x de:amtlicher_regionalschluessel

Wegen mir könnte man für beide Sachen auch kürzere Namen verwenden,
z.B de:ags und de:rgs oder de:AGS und de:RGS

geodreieck4711 wrote:

wiki wrote:

Tagging An die Grenzrelationen wird der Schlüssel de:amtlicher_regionalschluessel=* mit dem Regionalschlüssel ohne Leerzeichen als Wert gesetzt. Der Regionalschlüssel ist auf die Anzahl Stellen zu kürzen die dem admin_level=* entsprechen also zum Beispiel de:amtlicher_regionalschluessel=14713

Ein komplettes Beispiel für Leipzig:

type=multipolygon
+boundary=administrative
+admin_level=6
+name=Leipzig, Stadt
+de:amtlicher_regionalschluessel=14713

kann ich jetzt nicht zählen oder hat sich das wiki verzählt?
Das Beispiel verwirrt..............

Deshalb hatte ich das einklich geändert auf:
http://wiki.openstreetmap.org/wiki/Key: … schluessel

Tagging

An die Grenzrelationen wird der Schlüssel de:amtlicher_regionalschluessel=* mit dem Regionalschlüssel ohne Leerzeichen als Wert gesetzt. Für kreisfreie Städte sollten (wie in der destatis-Liste) die Schlüssel immer auf 12 Stellen mit Nullen aufgefüllt werden, um eine eindeutige Unterscheidung zu den Landkreisen zu schaffen.

wo steht jetzt noch die alte Version?

Gruß,
ajoessen

misterboo wrote:

ich dachte du hättest den WIKI Artikel geschrieben ?

Nur ergänzt, nicht angelegt.

in der DB sind bisher 191 x de:regionalschluessel und 742 x de:amtlicher_regionalschluessel

Wegen mir könnte man für beide Sachen auch kürzere Namen verwenden,
z.B de:ags und de:rgs oder de:AGS und de:RGS

Abkürzungen werden nicht gerne gesehen.
Die quoten stimmen nicht mehr. Die 742 waren von mir, die Minderheit hatte ich heute der Mehrheit angepasst.
Insgesamt sind es jetzt 1155 Regionalschlüssel.

Ich änder das jetzt mal auf de:regionalschluessel in der DB und im Wiki.

EDIT: Hier gehts jetzt lang:
http://wiki.openstreetmap.org/wiki/Key: … schluessel

Heute wurde an vielen Grenzrelationen ein place-Tag angefügt und in type=boundary umgetaggt. Wurde das irgendwo diskutiert? Das durch die place-Tags jetzt doppelt in der Datenbank sind, damit kann ich mich ja noch arrangieren, aber das umgetagge betrachte ich mal als Vandalismus.

Masch wrote:

Heute wurde an vielen Grenzrelationen ein place-Tag angefügt und in type=boundary umgetaggt.

Beispiel?

Gruß,
Mondschein

62405

Masch wrote:

Heute wurde an vielen Grenzrelationen ein place-Tag angefügt und in type=boundary umgetaggt. Wurde das irgendwo diskutiert? Das durch die place-Tags jetzt doppelt in der Datenbank sind, damit kann ich mich ja noch arrangieren, aber das umgetagge betrachte ich mal als Vandalismus.

Ist das Vanadalismus, wenn man eine eindeutige Unterscheidung zwischen Stadt und Gemeinde; sowie zwischen Kreis und kreisfreier Stadt haben will?

Gruß,
ajoessen

Und warum wird dazu das place-Tag "missbraucht", wozu redundante Informationen?

Und wie passt da das boundary rein, nur das habe ich als Vandalismus bezeichnet?

type=multipolygon vs. type=boundary:
http://lists.openstreetmap.org/pipermai … 73593.html

ajoessen wrote:

Ist das Vanadalismus, wenn man eine eindeutige Unterscheidung zwischen Stadt und Gemeinde; sowie zwischen Kreis und kreisfreier Stadt haben will?

Verstehe das Problem auch nicht.

Gruß,
Mondschein

Mondschein wrote:

ajoessen wrote:

Ist das Vanadalismus, wenn man eine eindeutige Unterscheidung zwischen Stadt und Gemeinde; sowie zwischen Kreis und kreisfreier Stadt haben will?

Verstehe das Problem auch nicht.

Wie war das noch mit dem kleinen gallischen Dorf, das gegen den rest der Welt kämpft?

Gibt aber doch ein Problem, mit dem place: mkgmap unterscheidet nicht sauber zwischen city/town/village als Siedlungsfläche und als Grenze. Und bevor sich Leute aufregen, weil sie ihre Regeln anpassen müssen, hab ich die jetzt nach de:place verschoben.

Mondschein wrote:

ajoessen wrote:

Ist das Vanadalismus, wenn man eine eindeutige Unterscheidung zwischen Stadt und Gemeinde; sowie zwischen Kreis und kreisfreier Stadt haben will?

Verstehe das Problem auch nicht.

Es geht darum, dass Orte zweimal eingetragen sind, einmal mit einem place-Node und einmal mit einem place an der Relation. Wie sollen zB Suchfunktionen damit vernünftig umgehen?

Mondschein wrote:

type=multipolygon vs. type=boundary:
http://lists.openstreetmap.org/pipermai … 73593.html

Das Schlimme ist, dass diese Diskussion bei weitem älter ist und der Konsens ist schon lange "In Deutschland wird multipolygon für amtliche Grenzen genutzt". Es ist einfach nur dreist, ohne Rücksprache mit der Community daran was zu ändern!

Masch wrote:

Es geht darum, dass Orte zweimal eingetragen sind, einmal mit einem place-Node und einmal mit einem place an der Relation. Wie sollen zB Suchfunktionen damit vernünftig umgehen?

Da Relation 17661 schon ein "type=city" hat, wäre ein "type=city" bei Relation 62405 redundant.
Was ist mit "type=country" bei Relation 22961?
Das ist doch nicht richtig?
Ist das genaue Vorgehen irgendwo nachzulesen?

Masch wrote:

Das Schlimme ist, dass diese Diskussion bei weitem älter ist und der Konsens ist schon lange "In Deutschland wird multipolygon für amtliche Grenzen genutzt".

Ich bin auch für die "type=multipolygon"-Lösung, allerdings scheint das so bisher nicht eindeutig dokumentiert zu sein.

Gruß,
Mondschein

Mondschein wrote:

Masch wrote:

Es geht darum, dass Orte zweimal eingetragen sind, einmal mit einem place-Node und einmal mit einem place an der Relation. Wie sollen zB Suchfunktionen damit vernünftig umgehen?

Da Relation 17661 schon ein "type=city" hat, wäre ein "type=city" bei Relation 62405 redundant.

Mir gehts um die Grenzpolygone und deren tags. Da nützen mir irgendwelche tags an Punkten innerhalb wenig. Innerhalb eines Landkreises gibts etliche Untergliederungen, die alle beliebige place-nodes haben können.

Was ist mit "type=country" bei Relation 22961?
Das ist doch nicht richtig?

Stammt nicht von mir. Und wurde von mir ignoriert, weil es kein boundary=administrative und keinen AGS hat.

Ist das genaue Vorgehen irgendwo nachzulesen?

http://wiki.openstreetmap.org/wiki/DE:G … che_Grenze
http://wiki.openstreetmap.org/wiki/DE:G … on_anlegen

Masch wrote:

Das Schlimme ist, dass diese Diskussion bei weitem älter ist und der Konsens ist schon lange "In Deutschland wird multipolygon für amtliche Grenzen genutzt".

Ich bin auch für die "type=multipolygon"-Lösung, allerdings scheint das so bisher nicht eindeutig dokumentiert zu sein.

Der Konsens liegt weltweit bei 169 479 Grenzrelationen, davon 109 378 type=boundary.

Aber davon ab, werden die Grenzrelationen ja sowieso nächsten Monat zerstört und von fleißigen Mappern anhand von Bing-Luftbildern im Nullkommanix wieder neu erstellt.

Gruß,
ajoessen

Mondschein wrote:

Ich bin auch für die "type=multipolygon"-Lösung, allerdings scheint das so bisher nicht eindeutig dokumentiert zu sein.

http://wiki.openstreetmap.org/wiki/DE:R … ltipolygon
http://wiki.openstreetmap.org/wiki/DE:Relation:boundary
http://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze

ajoessen wrote:

Mondschein wrote:

Masch wrote:

Das Schlimme ist, dass diese Diskussion bei weitem älter ist und der Konsens ist schon lange "In Deutschland wird multipolygon für amtliche Grenzen genutzt".

Ich bin auch für die "type=multipolygon"-Lösung, allerdings scheint das so bisher nicht eindeutig dokumentiert zu sein.

Der Konsens liegt weltweit bei 169 479 Grenzrelationen, davon 109 378 type=boundary.

Reden wir hier nicht deutschen Grenzrelationen? Aber gut das nach Jahren mal jemand darauf aufmerksam macht.
Am besten konsequent sein und die restlichen deutschen Grenzen von multipolygon auf boundary umstellen, vielleicht gleich für Niederlande und Ecuador dazu. Nicht zu vergessen das Wiki zu ändern, vorher aber auch eine Mail an die Liste, damit jeder von der Lex ajoessen weiss.

ajoessen wrote:

Aber davon ab, werden die Grenzrelationen ja sowieso nächsten Monat zerstört und von fleißigen Mappern anhand von Bing-Luftbildern im Nullkommanix wieder neu erstellt.

Hatte übrigens jemand Antwort vom Kollegen ludwich bekommen ?

http://www.openstreetmap.org/user/ludwich

Dieses Wochenende sind noch mal einige Fehlermeldungen dazu gekommen:

http://ags.misterboo.de/

u.a. ersetzt der Kollege leider immer noch den 8 stelligen Gemeindeschlüssel mit dem 12 stelligen Regionalschlüssel.

Noch ein Wort zu der type=multipolygon vs. type=boundary Geschichte

Auch wenn es bei uns anders ist als im Rest der Welt ... es war bisher einheitlich !! Es gibt nicht viele Sachen in der OSM DB die vollständig und einheitlich sind, die Grenzen in Deutschland waren dies bis vor kurzem: komplett und einheitlich type=multipolygon.

Ich denke wir sollten woodpeek von der geofabrik zu dieser Frage nochmal was sagen lassen. Ich habe mir seine Argumente mal rausgesucht und finde diese sehr sinnvoll, überhaupt generell seine Gedanken zum OSM Datenmodell. Und wie ich die Sache so überblicke, gehört er zu den recht wenigen Fachleuten die von der Programmierung her überhaupt den Durchblick haben und an der nächsten api Version mitarbeiten. Meiner Meinung nach wird das sowie so eine Mammutaufgabe werden, das Datenmodell von OSM an zukünftige Anforderungen anzupassen.

Aber egal wie man sich hoffentlich gemeinsam einigt: ein Durcheinander im tagging wie es sich momentan abzeichnet, sollte unbedingt vermieden werden.

misterboo wrote:

Hatte übrigens jemand Antwort vom Kollegen ludwich bekommen ? http://www.openstreetmap.org/user/ludwich

Dieses Wochenende sind noch mal einige Fehlermeldungen dazu gekommen: http://ags.misterboo.de/
u.a. ersetzt der Kollege leider immer noch den 8 stelligen Gemeindeschlüssel mit dem 12 stelligen Regionalschlüssel.

Da teile ich deine Meinung, dass dies völlig daneben ist.
Der Regionalschlüssel ist nun einmal etwas anderes als der Gemeindeschlüssel.
Daher sollte dafür auch ein anderer Key benutzt werden.

misterboo wrote:

Noch ein Wort zu der type=multipolygon vs. type=boundary Geschichte

Auch wenn es bei uns anders ist als im Rest der Welt ... es war bisher einheitlich !! Es gibt nicht viele Sachen in der OSM DB die vollständig und einheitlich sind, die Grenzen in Deutschland waren dies bis vor kurzem: komplett und einheitlich type=multipolygon.

Ich denke wir sollten woodpeek von der geofabrik zu dieser Frage nochmal was sagen lassen. Ich habe mir seine Argumente mal rausgesucht und finde diese sehr sinnvoll, überhaupt generell seine Gedanken zum OSM Datenmodell. Und wie ich die Sache so überblicke, gehört er zu den recht wenigen Fachleuten die von der Programmierung her überhaupt den Durchblick haben und an der nächsten api Version mitarbeiten. Meiner Meinung nach wird das sowie so eine Mammutaufgabe werden, das Datenmodell von OSM an zukünftige Anforderungen anzupassen.

Aber egal wie man sich hoffentlich gemeinsam einigt: ein Durcheinander im tagging wie es sich momentan abzeichnet, sollte unbedingt vermieden werden.

Es war nie einheitlich. Es gab auch in DE immer Gebiete wo type=boundary genutzt wurde.

Das Flächenmodell wie es durch type=multipolygon favorisiert wird, unterschlägt die zweite Seite von Grenzen, nämlich die Linie, die zwischen zwei Gebieten existiert. Denke nur mal an Begriffe wie Deutsch-Französische Grenze oder Seegrenze (Staat / internationales Gewässer).

Von daher bevorzuge ich das französische Modell mit boundary_segments für jede solche Grenze zwischen zwei Gebieten. Nur leider kann man daraus keine Multipolygone für die Flächen der Gesamtheit aller Grenzen bilden. Multipolygone erlauben leider nur einfache Wege als Mitglieder und nicht Realtionen, die ihrerseits einen kontinuierlichen Weg darstellen. So gibt es immer die doppelte Datenhaltung für Segmente und für die Fläche. Dass man in Multipolygonen weder label noch admin_centre (üblicherweise Punkte) als Rollen als angeben kann, sei nur als ein weiterer Mangel angemerkt.

Edbert (EvanE)

misterboo wrote:

Auch wenn es bei uns anders ist als im Rest der Welt ... es war bisher einheitlich !!

Nö, da kram ich doch mal den alten Thread raus. Und das war nur die Küste
http://forum.openstreetmap.org/viewtopic.php?id=12203

Hat immer noch niemand den Kollegen erreichen können ? Ich habe ihn schon 2 x angeschrieben und erst
gestern seine letzten Änderungen wieder korrigiert. Antwort habe ich leider keine bekommen.

http://www.openstreetmap.org/user/ludwich/edits

Langsam wird es etwas nervig.

http://ags.misterboo.de

Heute hat er wieder bei einigen Gemeinden den Regionalschlüssel in den tag de:amtlicher_gemeindeschluesel geschrieben.

Für den Fehler 1 zeichne ich verantwortlich... 🙂
habe einfach mal versucht, die 10 Gemeindefreien Gebiete dieses einen Landkreises, die ja unterschiedliche AGS haben, zu einer collection zusammenzufassen;
dieser habe ich dann den Einheits-AGS und Regionalschlüssel aus der Destatis-Datei verpasst.

siehe auch Post #65 in diesem Faden.

Ich lass das erstmal so, bis das ganze Gezerre um type=multipolygon bzw type=boundary sich in irgendeiner Weise gelegt/vereinheitlicht hat hat, oder gibt es
zu meiner type=collection Probleme?

geodreieck4711 wrote:

Ich lass das erstmal so, bis das ganze Gezerre um type=multipolygon bzw type=boundary sich in irgendeiner Weise gelegt/vereinheitlicht hat hat, oder gibt es
zu meiner type=collection Probleme?

hi,

ich komme eigentlich ganz gut zurecht mit den beiden Versionen - ich behandle sie als gleichwertige Synonyme. Allerdings krieg ich die Krise, wenn hier plötzlich noch ne dritte Variante auftaucht.

Gruss
Walter

geodreieck4711 wrote:

Für den Fehler 1 zeichne ich verantwortlich... 🙂
habe einfach mal versucht, die 10 Gemeindefreien Gebiete dieses einen Landkreises, die ja unterschiedliche AGS haben, zu einer collection zusammenzufassen;
dieser habe ich dann den Einheits-AGS und Regionalschlüssel aus der Destatis-Datei verpasst.

siehe auch Post #65 in diesem Faden.

Ich lass das erstmal so, bis das ganze Gezerre um type=multipolygon bzw type=boundary sich in irgendeiner Weise gelegt/vereinheitlicht hat hat, oder gibt es
zu meiner type=collection Probleme?

Ja lass das mal auf jeden Fall, ist meiner Meinung nach gut gelöst für den Moment ...

wenn ich mir die ganzen Diskussionen momentan ansehe, die sich mit Relationen, Spurmapping und Komplexität allgemein befassen, wird die nächste API Version nach dem Lizenzwechsel sowieso eine riesen Herausforderung ... mit unbekanntem Ausgang.

wambacher wrote:

...Allerdings krieg ich die Krise, wenn hier plötzlich noch ne dritte Variante auftaucht. ....

Die einzelnen Gebiete liegen ja schon als type=multipolygon vor.
Die ganzen einzelnen outers in eine neue Relation vom type=multipolygon bzw type=border zu packen, um dann eine Relation mit vielen Umgrenzungen zu haben, wäre eine Möglichkeit.

Die andere -Multipolygon in Multipolygon/Boundary-Relation- wird aber (noch?) nicht unterstützt, JOSM meckert dann....

Mittlerweile gibt es ja auch einige Verwaltungsgemeinschaften, die sich aus mehreren Einzelgemeinden (teilweise nicht mit gemeinsamen outer) zusammensetzen.
Hier böte die collection ja auch eine einfachere Möglichkeit der Erfassung, weil die Gemeinderelationen auch schon als MP vorliegen.....

http://www.openstreetmap.org/user/ludwich/edits

Der Kollege ersetzt auch heute wieder eifrig den Gemeindeschlüssel mit dem Regionalschlüssel

hat denn keiner die Möglichkeit ihn mal auf "Pause" zu setzen bis er seine Email liest und mal hier im Forum vorbeischaut ?

misterboo wrote:

hat denn keiner die Möglichkeit ihn mal auf "Pause" zu setzen bis er seine Email liest und mal hier im Forum vorbeischaut ?

Frederik Ramm kann das:
http://www.openstreetmap.org/user/woodpeck
http://forum.openstreetmap.org/profile.php?id=4993

Er ist Mitglied der Data Working Group:
http://wiki.openstreetmap.org/wiki/DE:D … king_group

Gruß,
Mondschein

ajoessen wrote:

Laut
http://wiki.openstreetmap.org/wiki/User:Flohoff
sind seine edits public domain. Irgendwer hat sie deshalb adoptiert.

flohoff hat übrigens soeben den CTs zugestimmt.

Gruß,
Mondschein

misterboo wrote:

Heute hat er wieder bei einigen Gemeinden den Regionalschlüssel in den tag de:amtlicher_gemeindeschluesel geschrieben.

Anscheinend ist er lernfähig. bei seinen letzten edits hat er den Regionalschlüssel hingeschrieben, wo er reingehört. Es gibt aktuell keine 12stelligen Einträge im AGS; elfstellige nur wg. Leerzeichen.

Auf Kreisebene müssten AGS und RS komplett sein. Bei level 7 habe ich bei allen Verbandsgemeinden den 7- bis neunstelligen AGS durch neunstellige RS ersetzt. Nur verbandsgemeindefreie Orte haben im admin_level 7 beide Werte (mit verschiedenen Längen).

Bei admin_level 9 und 10 gab es eine Reihe von AGS-Einträgen, die entweder überholt waren, oder zur übergeordneten Gemeinde gehörten. Die sind jetzt auch weg.

Aktuell gibts 11906 AGS und 2067 RS. Wobei man noch überlegen kann, ob AGS bei Bundesländern, Regierungsbezirken und Kreisen durch gleichlautende RS ersetzt werden können.

Falls jemand Zeit hat und sich mal den Änderungssatz ansehen könnte:

http://www.openstreetmap.org/browse/changeset/11086480

Ein Neuling hat da einige Sachen gelöscht, u.a. sind nun die Grenzrelationen von
Aischwald und Esslingen kaputt:

http://www.openstreetmap.org/browse/relation/902652
http://www.openstreetmap.org/browse/relation/902655

http://ags.misterboo.de/

misterboo wrote:

Falls jemand Zeit hat und sich mal den Änderungssatz ansehen könnte:

http://www.openstreetmap.org/browse/changeset/11086480

Ein Neuling hat da einige Sachen gelöscht, u.a. sind nun die Grenzrelationen von
Aischwald und Esslingen kaputt:

http://www.openstreetmap.org/browse/relation/902652
http://www.openstreetmap.org/browse/relation/902655

http://ags.misterboo.de/

Ich reverte das Changeset. 139 Wege gelöscht und ein neuen Weg. Danach schreibe ich ihn mal an

Falscher AGS TAG

Hallo Kollegen,

sorry für das Durcheinander mit den falschen Tags. Ich habe meine "fehlerhaften" Daten leider nicht mehr bereinigen können, weil ihr als Kontrollinstanz schneller agiert habt!

Wie ich gelesen habe, wurden inzwischen die unterschiedlichen Tags zusammengefasst - sehr schön.
Hat sich den schon jemand mit der Bereinigung der unterschiedlichen Schreibweisen (Formatierung ohne Leerstellen) befasst?

@misterboo Wie gehst du den mit den "falschen" Admin-Level 7 um?

Ich werde 😎 jetzt öfter direkt ins Postfach sehen - meine Benachrichtigung scheint nicht geklappt zu haben ??

ludwich

ludwich wrote:

Wie ich gelesen habe, wurden inzwischen die unterschiedlichen Tags zusammengefasst - sehr schön.
Hat sich den schon jemand mit der Bereinigung der unterschiedlichen Schreibweisen (Formatierung ohne Leerstellen) befasst?

@misterboo Wie gehst du den mit den "falschen" Admin-Level 7 um?

Siehe mein Posting Nr 102 weiter oben:

admin_level 7 enthält nach meiner Aufräumaktion von vor 2 Wochen nur noch dann AGS, wenn es eine verbandsfreie Gemeinde ist. Alles andere habe ich in den de:regionalschlüssel verschoben. Leerzeichen habe ich bei der Gelegenheit auch rausgeworfen. In Level 8 könnten aber noch Orte stecken, dei eigentlich nach 7 gehören.

gruß,
ajoessen

Könnte mal jemand mit Ortskenntnis diese beiden Gemeinden checken in Sachen-Anhalt

Ilberstedt: http://www.openstreetmap.org/browse/rel … 14/history
Alsleben (Saale): http://www.openstreetmap.org/browse/rel … 00/history

Bei der ersten wurde die AGS gelöscht bei der 2. die komplette Relation, ich konnte auf die Schnelle keinen Hinweis finden, dass es da Änderungen gab oder Gemeindezusammenlegungen.

Moin,

in der Gegend bin ich leider nicht ortskundig - aber da kann Win32netsky ja vielleicht direkt darauf antworten, warum er das geändert hat.

Wo ich allerdings ortskundig bin, ist in Schläfrig-Holzbein - und da wundere ich mich, warum man in deiner APP dort keine Gemeindeverbände (Ämter) auswählen kann/darf?

Edit:
Und noch mehr wundere ich mich, dass in der aktuellen GV100 laut Datensatzdefinition jetzt der Regionalschlüssel wieder 8-stellig ist und der Gemeindeverband 4-stellig nachgesetzt ist?
Hat da jemand genauere Informationen?

Gruß
Georg

Eigentlich wollte ich ja mit dem nächsten Update bis nach dem Lizenzwechsel warten.
Da aber der Zeitrahmen nicht absehbar ist und es ja auch nur noch spärliche Infos dazu gibt, habe ich die
Datenbank nun mal aktualisiert und auch die Daten des amtlichen Gemeindeverzeichnis zum 31.03.2012.

Mittlerweile wurden wohl eine Menge nicht odbl konformer Grenzrelationen gelöscht,
besonders in Thüringen wo ein paar 100 Gemeindegrenzen nun fehlen.

Beispiel hier:

http://www.openstreetmap.org/browse/changeset/11576142

Echt schade, die Grenzen in Deutschland waren schon mal vollständig 🙁

Wer also Lust hat, kann die fehlenden Grenzen besonders in Thüringen mal neu anlegen.

Ich hatte es hier schonmal angesprochen...

Die Grenzen in Thüringen stammen aus Daten, die nur unter cc-by-sa zur Verfügung stehen und auch das nicht unter solchen Voraussetzungen, wie wir sie an unsere Quellen stellen.

Es gäbe derzeit nicht viel, was ich lieber mappen würde, als die Gemeindegrenzen, aber ohne zugängliche, legale Quelle ist das sinnlos...

aighes wrote:

Ich hatte es hier schonmal angesprochen...

Die Grenzen in Thüringen stammen aus Daten, die nur unter cc-by-sa zur Verfügung stehen und auch das nicht unter solchen Voraussetzungen, wie wir sie an unsere Quellen stellen.

Es gäbe derzeit nicht viel, was ich lieber mappen würde, als die Gemeindegrenzen, aber ohne zugängliche, legale Quelle ist das sinnlos...

Ich hoffe da ja auf ein positives Signal, das von den Änderungen des Geodatenzugangsgesetzes ausgeht

http://www.heise.de/newsticker/meldung/ … 84540.html

evt. könnte man mal nochmal beim Bund nachfragen ob wir einen Datensatz der Grenzen bekommen können für OSM oder zumindest die Grenzen abzeichnen dürfen.

Joachim wollte sich bei den Ämtern mal erkundigen, bisher noch ohne Ergebnis.

Im Zuge dessen hoffe ich auch, dass da zumindest die Grenzen bei abfallen werden.

aighes wrote:

Ich hatte es hier schonmal angesprochen...

Die Grenzen in Thüringen stammen aus Daten, die nur unter cc-by-sa zur Verfügung stehen und auch das nicht unter solchen Voraussetzungen, wie wir sie an unsere Quellen stellen.

Es gäbe derzeit nicht viel, was ich lieber mappen würde, als die Gemeindegrenzen, aber ohne zugängliche, legale Quelle ist das sinnlos...

Ich kenne mich da nicht so aus. Könntest du kurz mal erklären weshalb die Grenzdaten in Thüringen nicht lizenzkonform waren ?

z.B hier:

http://www.openstreetmap.org/browse/rel … 49/history

dort steht als source http://de.wikipedia.org/wiki/Datei:Muni … in_SHK.svg

Unter dem Link sind mehrere Lizenzen angegeben, ganz unten auch ein paar copyleft Lizenzen. Was ist da das Problem mit diesen Daten ?

misterboo wrote:

Was ist da das Problem mit diesen Daten ?

Das sie aus einem ADAC Atlas abgemalt sind 😉

Edit: bzw. in diesem Fall ein toter Link auf das Thüringer Landesamt für Statistik als Quelle angegeben ist (mir ist dort keine freie Karte mit Gemeindegrenzen bekannt)

Die Wikiseite zum Thema: http://wiki.openstreetmap.org/wiki/Thür … enzen_2012

Gruß
BBO

aighes wrote:

, aber ohne zugängliche, legale Quelle ist das sinnlos...

Falls in den betroffenen Gegenden die Gemeindegrenzen noch mit den PLZ-Grenzen übereinstimmen, dann konnte immer noch http://wiki.openstreetmap.org/wiki/Impo … hland_2010 helfen.

Diesen Layer kann man sich derzeit noch sehr gut als WMS z.B. in JOSM einbinden, den Versatz zurechtrücken und dann schauen.

BBO wrote:

misterboo wrote:

Was ist da das Problem mit diesen Daten ?

Das sie aus einem ADAC Atlas abgemalt sind 😉

Edit: bzw. in diesem Fall ein toter Link auf das Thüringer Landesamt für Statistik als Quelle angegeben ist (mir ist dort keine freie Karte mit Gemeindegrenzen bekannt)

Die Wikiseite zum Thema: http://wiki.openstreetmap.org/wiki/Thür … enzen_2012

Gruß
BBO

Was bedeutet dies denn für andere Grenzen

Ein willkürliches Beispiel aus Rheinland Pfalz :

http://www.openstreetmap.org/browse/relation/1021829

Source: http://de.wikipedia.org/wiki/Datei:Ahrb … _in_AW.svg

Ich kann da jetzt keinen großen Unterschied erkennen, die svg Datei ist wohl auch vom gleichen Autor bei Wikipedia

Was ist mit Grenzen ohne source tag , auch wieder willkürlich ein Beispiel:

http://www.openstreetmap.org/browse/rel … 40/history

Wer sagt mir dass diese Grenze lizenzkonform ist ?

oder anders rum ... war oder ist die Löschung der Thüringer Grenzen so dringend erforderlich ?

Ich habe mich nur mit den Grenzen in Thüringen beschäftigt. Es kann also gut sein das auch welche in anderen Bundesländern unsauber sind.

Zu der von dir verlinkten:
Als Quelle ist dort folgenden Datei angegeben:
http://commons.wikimedia.org/wiki/File: … tinate.svg

dort wiederum folgende:

http://www.statistik.rlp.de/fileadmin/d … s/1902.pdf

Sieht für mich nicht gerade sauber aus. Es kann aber sein das dort wer eine Genehmigung geholt hat.
Meine Erfahrungen sagen aber:
-auf Wikipedia/Commons sieht man es bei solchen Dateien nicht sonderlich eng mit der Lizenz (siehe mein ADAC-Atlas Beispiel)
-Genehmigungen zum Verwenden solcher Dateien bekommt man bei Landesämtern eher nicht

misterboo wrote:

oder anders rum ... war oder ist die Löschung der Thüringer Grenzen so dringend erforderlich ?

Nochmal zum Überblick:

Bei den Grenzen in Thüringen sah die Verteilung so aus:
-aus ADAC-Atlas: ABG,GRZ,SOK,SLF,UH,SON,AP,WAK,SM,HBN
-undurchsichtige Quellenlage (toter Link auf Karte des Landesamt für Statistik): EIC,GTH,SHK
-von Mirko Küster: KYF,NDH,SÖM

Die Notwendigkeit der Löschung der ADAC-Grenzen wurden mir von einem LWG-Mitglied bestätigt. Die Grenzen von Mirko Küster löscht der Bot. Streitbar sind also höchstens EIC,GTH,SHK.

Bei solchen eindeutigen Hinweisen ist die Löschung imho dringend erforderlich, sonst könnten wir uns den ganzen Lizenzwechselprozess sparen.

... meine Frage ist jetzt ... was bedeutet die Löschaktion in Thüringen für die anderen Grenzen in Deutschland bzw. sogar weltweit.

Du hast dich jetzt mit Thüringen beschäftigt ... wer genau beschäftigt sich mit dem Rest der Welt ?

Soll jetzt jede Grenze einzeln untersucht werden ? Es gibt noch viele Grenzen mit einem source tag=wikimedia

Die scheinen ja alle mehr oder weniger keine eindeutige saubere Quelle zu haben. Sollen die jetzt alle gelöscht werden ?

Was ist mit den Grenzen ohne source tag ? Sollen da alle Version 1 Ersteller angeschrieben werden und nachgefragt werden woher die Daten kommen ? Sollen die V1 Ersteller angewiesen werden, noch einen source tag zu erstellen um die Unbedenklichkeit der Quelle zu bestätigen ?

Im Grunde ist mir hier wie immer das Vorgehen egal, nur irgendwie sollte es mal einheitlich koordiniert werden. In Thüringen aufräumen und in anderen Regionen ist es egal weil sich niemand drum kümmert, ist auch nicht das gelbe vom Ei 🙂

Das sollte egtl. die Aufgabe desjenigen sein, der die Daten importiert hat.

Wer Lust zum Remappen hat:

http://ags.misterboo.de/

Dabei sollte man aber vielleicht warten, bis der Redaction-Bot mit Deutschland oder zumindest mit dem Zielgebiet welches man reparieren will, auch wirklich schon fertig ist, oder?

Also die Kästchen auf der Bot-Progress-Karte sollten für die Gegend schon grün sein ...

Irgendwie fördert das nicht gerade die Motivation 🙁

Deutschland war im Februar oder März wohl das einzige Land, das alle Gemeindegrenzen in den OSM Daten hatte. Viele haben dabei geholfen, die fehlenden Grenzen zu ergänzen.

Durch die Lizenzumstellung fehlt natürlich mittlerweile einiges und es werden wohl noch mehr fehlende Grenzen dazu kommen, da der Bot ja noch nicht fertig ist. Meine Motivation zum mappen ist nun erst mal weg. Interessant wird es zu sehen wie lange es dauert bis die Grenzen wieder annähernd komplett sein werden.

Danke mal an die fleißigen Mapper, die sich um die Reparatur der Grenzen kümmern, die dem Redaction Bot zum Opfer gefallen sind.

http://ags.misterboo.de/#x=10.4541&y=51.3615&z=6

aktuell fehlen noch knapp 830 Grenzrelationen, die meisten davon (diese wurden aber schon vor dem Redaction Bot gelöscht) leider immer noch in Thüringen. Aus Mangel an verfügbaren Quellen bleiben wohl nur die etwas älteren PLZ Grenzen.

Bleibt zu hoffen, dass die Grenzen durch die neuen Entwicklungen beim Geodatenzugangsgesetz irgendwann man offen für OSM verfügbar sein werden.

Hallo misterboo

Es gibt eine Webseite, auf der eine Schritt für Schritt Anleitung für die Bedienung von Deiner Seite "Administrative Grenzen in OSM" existiert. Die Anleitung ist möglichst untechnisch geschrieben, so dass sie auch für Wikipedianer verstehbar ist, die relativ neu auf OSM sind. Außerdem wird dort die Abarbeitung sämtliche Kommunen Deutschlands mit Hilfe Deiner Seite organisiert. Vielleicht magst Du diese Webseite von Deiner Seite aus verlinken:

http://de.wikipedia.org/wiki/Wikipedia: … chland/OSM

Gruß
Tirkon

Tirkon wrote:

Vielleicht magst Du diese Webseite von Deiner Seite aus verlinken:

http://de.wikipedia.org/wiki/Wikipedia: … chland/OSM

Vielen Dank. Allerdings steht in dem Link "hhttp" statt "http".

Gruß Tirkon

Hey misterboo,

ich gehe davon aus, dass die ausgewerteten OSM-Daten auf deiner Seite taggenau aktualisiert werden, wie man am Datum oben rechts ja sehen kann.

For die Grenze von Cottbus http://www.openstreetmap.org/browse/relation/62430 spuckt er aber seit Tagen immer noch einen Fehler des Typs 1 aus.

Wenn man nur diese Relation z.B. in JOSM's Relationseditor lädt, so lässt sich da KEINERLEI Datenfehler erkennen. Warum also Fehler1?

Und:
es gab zum 01.07.2012 etliche Eingemeindungen und Zusammenschlüsse in Deutschland, die auch schon in OSM berücksichtigt wurden, siehe auch z.B. http://de.wikipedia.org/wiki/Wikipedia: … 4nderungen

Könnte eine aktuellere Datei mit den Gemeindeschlüsseln schon herangezogen werden?

Gruß, Stephan

Die Daten des amtlichen Gemeindeverzeichnisses erscheinen quartalsmässig. Die letzte Ausgabe ist vom 30.06 (da muss ich mal noch aktualisieren)

Neue Daten vom 01.07 sind dann erst in der nächsten Ausgabe Ende September.

Zu der Grenze von Cottbus. Ich habe 2 Arten meine DB aktuell zu halten, einmal mit osmosis und einmal mit osmupdate. Über längere Zeiträume beobachte ich immer wieder, dass sich scheinbar in beiden Arten ganz selten einzelne Fehler einschleichen, ein Erklärung dafür habe ich noch nicht gefunden.

Cottbus ist in beiden DBs als Fehler drin. Ich lade die nächsten Tage mal nochmal den kompletten Planeten und erstelle die DB daraus neu, dann sollte die DB wieder fehlerfrei sein.

ich habe heute mal das Gemeindeverzeichnis auf den Stand vom 30.06 gebracht und nochmal einen neuen Planeten importiert, da sich über die updates ein paar Fehler eingeschlichen haben.

Mir aufgefallen, dass die Kreise in Sachsen-Anhalt momentan fehlen. Hat da jemand Infos warum die Relationen gelöscht wurden ? Ich dachte die Kreise wurden mal von der Geofabrik importiert. ?

misterboo wrote:

Mir aufgefallen, dass die Kreise in Sachsen-Anhalt momentan fehlen. Hat da jemand Infos warum die Relationen gelöscht wurden ? Ich dachte die Kreise wurden mal von der Geofabrik importiert. ?

Alle da außer Wittenberge!

http://www.openstreetmap.org/browse/relation/62602
http://www.openstreetmap.org/browse/relation/62747
http://www.openstreetmap.org/browse/relation/62639
http://www.openstreetmap.org/browse/relation/62526
http://www.openstreetmap.org/browse/relation/62429
http://www.openstreetmap.org/browse/relation/62477
http://www.openstreetmap.org/browse/relation/62681
http://www.openstreetmap.org/browse/relation/62473
http://www.openstreetmap.org/browse/relation/62502
http://www.openstreetmap.org/browse/relation/62725
http://www.openstreetmap.org/browse/relation/62359

Gefunden über Wikipedia -> Liste der Landkreise in S-A sowie dann über http://nominatim.osm.org gesucht.

Ah ja ... aber die AGS war falsch ... wurde wohl durch den Redaction Bot auf eine frühere Version gesetzt. Habs gerade korrigiert.

Hier mal noch etwas Hilfe für die fehlenden Gemeindegrenzen vor allem in Thüringen:

http://ags.misterboo.de/test/

Leider noch ohne Doku, dürfte aber selbsterklärend sein.

Es gibt Layer für die aktuellen Gemeindegrenzen in OSM, die aktuellen PLZ Grenzen in OSM, ein Layer der original PLZ Grenzen, die damals in OSM importiert wurden (ich glaube die Daten waren von 1999) und einen Layer der Ortsnetzbereiche der Bundesnetzagentur von hier:

http://www.bundesnetzagentur.de/DE/Sach … ?nn=154346

Die Daten entsprechen teilweise auch den Gemeindegrenzen.

Die ONB-Grenzen stehen jedermann zur kostenlosen Nutzung zur Verfügung. Die Information kann auch innerhalb einer freien oder kostenpflichtigen Software genutzt und dritten Personen zur Verfügung gestellt werden.

Zoom man näher ran, gibt es noch einen anklickbaren Vektorlayer mit den AGS Daten. Die roten Punkte sind die Gemeinden, deren Grenzen momentan fehlen in OSM, bei den orangen fehlt noch der Regionalschlüssel. Den kann man einfach kopieren und mit dem Edit Button die Grenze in JOSM laden und dort ergänzen.

Die Layer könnt ihr auch in JOSM als Hintergrund laden

http://tiles.misterboo.de/list/

Den Layer anklicken, Info drücken und die einfach die URL für JOSM kopieren und in JOSM in den TMS Einstellungen verwenden.

Die unterschiedlichen Blautöne des Gemeindelayers helfen, die Gemeinden zu finden, bei denen der Regionalschlüssel noch fehlt (helleres Blau). Die gelben Namen sind die offiziellen Namen im amtlichen Gemeindeverzeichnis, die weißen die Namen in OSM (dies hilft auch bei der Fehlersuche)

Die nächsten Tage baue ich das ganze noch in die Hauptseite ein.

http://ags.misterboo.de

Hier mal noch ein paar Beispiele welche Sachen man mit der Karte z.B. erkennen und korrigieren kann.

Einige Orte haben das Wort "Gemeinde" als Namensteil in OSM z.B:

http://ags.misterboo.de/test/?zoom=12&l … 000TFFFFFF

Hier sollte meiner Meinung nach das Wort "Gemeinde" gelöscht werden (aktuell gibt es noch 224 Orte mit dem Namensteil "Gemeinde")

http://ags.misterboo.de/test/?zoom=11&l … 000TFFFFFF

Hier sieht man die fehlende Grenze Osterheide ... die ist aber da etwas weiter rechts unten unter der Grenze Beedenbostel. Da hat jemand wohl aus Versehen die Grenze am falschen Platz erstellt. An der dunkleren blauen Farbe (leider noch nicht so deutlich anders als der Rest) kann man übereinander liegende Relationen erkennen, da stimmt dann meist auch etwas nicht.

http://ags.misterboo.de/test/?zoom=12&l … 000TFFFFFF

Und hier sieht man dann Grenzen, die durch Zusammenlegungen nicht mehr in den amtlichen Daten sind, Hier z.B. Allrode und Bad Suderode, dort kann man dann den admin_level zu 9 ändern und die noch vorhandene AGS löschen

Wegen dem ONB: In Thüringen scheint das nicht wirklich mit den realen Grenzen übereinzustimmen.

aighes wrote:

Wegen dem ONB: In Thüringen scheint das nicht wirklich mit den realen Grenzen übereinzustimmen.

Ich sagte ja schon: teilweise stimmen die überein. Durch die Kombination mit einem Blick z.B zu Wikipedia kann man den Grenzverlauf schon irgendwie hinbekommen. Viele Grenzrelationen beruhen eh noch auf dem alten PLZ Gebiete Import, teilweise sind da auch noch ein paar alte PLZ Grenzen drin, die man auch verwenden kann.

Richtig befriedigend ist das natürlich nicht. Wie ich in einem anderen Thread gerade angedeutet habe, wäre es schön wenn man mal koordiniert und langsam auch mit Nachdruck mal etwas Lobbyarbeit bei den amtlichen Stellen machen könnte, damit wird die amtlichen Daten offiziell nutzen dürfen, wenn nicht als offizieller Import dann würde ich mir wenigsten die Möglichkeit wünschen, dass wir die grenzen abzeichnen dürfen.

Ich wollte nur drauf hinweisen, nicht das übereifrige Mapper jetzt loslegen und blind diese Grenzen abzeichnen. Die Meinung zu den Wikipedia-Quellen haben Teile der Thüringer Community hier ja schon gesagt. Es wäre schön, wenn das auch berücksichtigt wird.

Kann mir evt jemand da helfen ?

http://ags.misterboo.de

Da wird die Relation 28322 Mecklenburg-Vorpommern als nicht geschlossen angezeigt. Dabei ist ist aber geschlossen und natürlich auch da, wenn ich sie mit josm lade. Aber in meiner osm2pgsql DB fehlt sie komplett.

Da ich immer mal wieder eine eine Relation habe, die bei den daily updates verschluckt wird habe ich gerade noch mal die europe.osm.pbf von der geofabrik neu runtergeladen, die Grenzen extrahiert mit

osmfilter de.o5m --keep="boundary= land_area= admin_level=" -o=de-grenzen.o5m

Und danach nochmal mit osm2pgsql die DB erstellt. Dummerweise fehlt dann immer noch die Relation 28322 Mecklenburg-Vorpommern in der DB.

Könnte mal jemand in seiner aktuellen osm2pgsql DB nachsehen, ob das auch noch bei jemand anderem so ist ? Oder hat jemand ein Erklärung an was das liegen könnte ?

misterboo wrote:

osmfilter de.o5m --keep="boundary= land_area= admin_level=" -o=de-grenzen.o5m

ist sie denn danach in de-grenzen.o5m drin?

Könnte mal jemand in seiner aktuellen osm2pgsql DB nachsehen, ob das auch noch bei jemand anderem so ist ? Oder hat jemand ein Erklärung an was das liegen könnte ?

kann ich leider nicht, da ich das anders mache.
ich hab bei mir die Version 126 online und die läßt sich prima -mit meinen Programmen- in eine Grenzlinie konvertieren. Also sind keine verborgenen Datenprobleme drin (doppelte Nodes oder Überkreuzungen).

wenn die in de-grenzen.o5m fehlen sollte, ist der Extrakt schon put. Ansonsten müsstes du checken, ob alle Member der Relation auch wirklich da sind.

Gruss
walter

... danke für den Tip ... habs jetzt mal genauer analysiert.

Dieser way fehlt mir als Teil der Relation 28322

http://www.openstreetmap.org/browse/way/178084194

und noch genauer fehlt genau dieser einzelne node:

http://www.openstreetmap.org/browse/node/418944814

kann mir noch jemand kurz erklären mit welchem Befehl man checken kann ob der node 418944814 auch in einem pbf extrakt ist ?

misterboo wrote:

kann mir noch jemand kurz erklären mit welchem Befehl man checken kann ob der node 418944814 auch in einem pbf extrakt ist ?

1.) in ein .osm konvertieren (ich mach das mit osmosis)
2.) dann unter linux grep "id=\"418944814\"" xyz.osm
oder in win mit find ... (bin mir nicht ganz sicher)

Gruss
walter

wambacher wrote:

misterboo wrote:

kann mir noch jemand kurz erklären mit welchem Befehl man checken kann ob der node 418944814 auch in einem pbf extrakt ist ?

1.) in ein .osm konvertieren (ich mach das mit osmosis)
2.) dann unter linux grep "id=\"418944814\"" xyz.osm
oder in win mit find ... (bin mir nicht ganz sicher)

Gruss
walter

so habe ich es gemacht um den fehlenden node in dem Extrakt der Grenzen zu finden. Um die 9GB europe.osm.pbf in eine xxx GB .osm umzuwandeln fehlt mir der Platz. Ich wollte aber noch sicher gehen dass der node auch dort fehlt und nicht evt. osmfilter einen bug hat beim Filtern.

misterboo wrote:

so habe ich es gemacht um den fehlenden node in dem Extrakt der Grenzen zu finden. Um die 9GB europe.osm.pbf in eine xxx GB .osm umzuwandeln fehlt mir der Platz. Ich wollte aber noch sicher gehen dass der node auch dort fehlt und nicht evt. osmfilter einen bug hat beim Filtern.

nimm dir doch den kleinsten Extrakt der Ecke und schau da nach. Alle Extrakte einer Nacht werden von EINEM Datenbestand erstellt. Sie sollten also - bis auf die Fläche- den gleichen Inhalt haben.
Wenn der fehlende Way nicht gerade an der Polnischen Grenze liegt, müsste germany eigentlich ok sein. Obwohl: MP.osm sollte auch reichen .
Gruss
walter

wambacher wrote:

misterboo wrote:

so habe ich es gemacht um den fehlenden node in dem Extrakt der Grenzen zu finden. Um die 9GB europe.osm.pbf in eine xxx GB .osm umzuwandeln fehlt mir der Platz. Ich wollte aber noch sicher gehen dass der node auch dort fehlt und nicht evt. osmfilter einen bug hat beim Filtern.

nimm dir doch den kleinsten Extrakt der Ecke und schau da nach. Alle Extrakte einer Nacht werden von EINEM Datenbestand erstellt. Sie sollten also - bis auf die Fläche- den gleichen Inhalt haben.
Wenn der fehlende Way nicht gerade an der Polnischen Grenze liegt, müsste germany eigentlich ok sein. Obwohl: MP.osm sollte auch reichen .
Gruss
walter

Fehler gefunden ... ich hatte wohl an der Stelle ein etwas knappes polyfile zum schneiden. Den betreffenden node hatte wohl jemand etwas verschoben, was dann aber ganz knapp außerhalb des Schnittbereiches war.

Kann mal bitte jemand Kerstin Inger, King-Kelch, Alex Grimme und keine Ahnung wer da noch so alles herum fummelt, bremsen? Die hauen hier massenhaft Grenzen rein, allerdings göber als grob, als geschlossene Kreise, existierende Grenzstücke nimmt man nicht mit, alles sich zigfach überlagernd und dabei nehmen die auch noch andere Pois und Wege mit. Keine Ahnung wie man das noch fixen soll, außer mit einem kompletten Revert.

Ich habe die alten von mir erfassten Grenzen noch da und den Kyffhäuserkreis bereits wieder vollständig versorgt. Wenn man sich noch ein bisschen geduldet, kommt das andere auch wieder. Nur finde ich hier bein der Fülle an zu wiederherzustellenden Daten weder Anfang noch Ende. Da machen es solche Aktionen bei weitem nicht einfacher.

geokyf wrote:

Kann mal bitte jemand Kerstin Inger, King-Kelch, Alex Grimme und keine Ahnung wer da noch so alles herum fummelt, bremsen? Die hauen hier massenhaft Grenzen rein, allerdings göber als grob, als geschlossene Kreise, existierende Grenzstücke nimmt man nicht mit, alles sich zigfach überlagernd und dabei nehmen die auch noch andere Pois und Wege mit. Keine Ahnung wie man das noch fixen soll, außer mit einem kompletten Revert.

Ich habe die alten von mir erfassten Grenzen noch da und den Kyffhäuserkreis bereits wieder vollständig versorgt. Wenn man sich noch ein bisschen geduldet, kommt das andere auch wieder. Nur finde ich hier bein der Fülle an zu wiederherzustellenden Daten weder Anfang noch Ende. Da machen es solche Aktionen bei weitem nicht einfacher.

Ja du.
Schreib sie einfach an, dass du die Grenzen mit deinen Daten wiederherstellst und daher ihre Grenzen gutgemeinte aber unnötige Zwischenschritte sind.

Edbert (EvanE)

Das sind keine Zwischenschritte sondern eher schon Katastrophen. Die verbinden ganzen Straßen und Hochspannungsleitungen mit Waldrändern etc. Wahrscheinlich zeichnen die ohne Rücksicht auf Verlusste aus 10 km Höhe. Zudem oft auch Wege ohne Tags und Relationen die keiner auswerten kann und somit weiter Fehler sind. Das habe ich jetzt nur durch Zufall am Rand gesehen, keine Ahnung wie weit das geht, wahrscheinlich durch halb Sachsen-Anhalt und Thüringen. Und da sind zig Objekte dutzender Mapper einbezogen oder gar verschoben. Mit dem Anschreiben gut und schön, den Spaß habe ich nahezu täglich und wenn das so weiter geht, habe ich zwei Jahre diskutiert und 5 Nodes geschaft. Da kann ich mir die Arbeit auch sparen.

geokyf wrote:

Das sind keine Zwischenschritte sondern eher schon Katastrophen. Die verbinden ganzen Straßen und Hochspannungsleitungen mit Waldrändern etc. Wahrscheinlich zeichnen die ohne Rücksicht auf Verlusste aus 10 km Höhe. Zudem oft auch Wege ohne Tags und Relationen die keiner auswerten kann und somit weiter Fehler sind. Das habe ich jetzt nur durch Zufall am Rand gesehen, keine Ahnung wie weit das geht, wahrscheinlich durch halb Sachsen-Anhalt und Thüringen. Und da sind zig Objekte dutzender Mapper einbezogen oder gar verschoben. Mit dem Anschreiben gut und schön, den Spaß habe ich nahezu täglich und wenn das so weiter geht, habe ich zwei Jahre diskutiert und 5 Nodes geschaft. Da kann ich mir die Arbeit auch sparen.

Das ist nun einmal die abgestufte Methode, wie das bei OSm geregelt werden soll:
- Anschreiben + Hilfe anbieten
- Von Mapper zu Mapper diskutieren
(auf Wunsch Reverts durchführen)
- Wenn es zu keiner Einigung kommt, hier oder in talk-de nachfragen.
- Notfalls die Data-Working-Group einschalten

Eine genaue Identifikation der betroffenen Objekte und Changesets wäre übrigens jetzt hilfreich, bei Einschaltung der Data-Working-Group notwendig.

Edbert (EvanE)

Dann lasse ich es lieber vorerst liegen. Ich habe noch hundertausende Objekte vor mir die erst einmal wieder rein müssen. Wer und was alles betroffen ist, keine Ahnung, das nimmt kein Ende. Bisher konnte ich nur Burgenlandkreis, Saalekreis und Nordhausen anschauen. Das jetzt mit zig Leuten zu diskutieren, noch um Erlaubnis zu betteln den offensichtlichen Murks wieder entfernen zu dürfen und notfalls noch einen Beamtendreikampf mit irgendwelchen Arbeitskreisen zu führen, übersteigt jegliches zuträgliche Maß.

geokyf wrote:

Dann lasse ich es lieber vorerst liegen. Ich habe noch hundertausende Objekte vor mir die erst einmal wieder rein müssen. Wer und was alles betroffen ist, keine Ahnung, das nimmt kein Ende. Bisher konnte ich nur Burgenlandkreis, Saalekreis und Nordhausen anschauen. Das jetzt mit zig Leuten zu diskutieren, noch um Erlaubnis zu betteln den offensichtlichen Murks wieder entfernen zu dürfen und notfalls noch einen Beamtendreikampf mit irgendwelchen Arbeitskreisen zu führen, übersteigt jegliches zuträgliche Maß.

Das ist doch normales menschliches Miteinander.
- Ansprechen und die Hintergründe erkunden.
- Eigene Probleme mit dem bisherigen Vorgehen erklären.
- Versuchen eine gemeinsame Lösung zu finden.

Aber wenn du dir das zu ... ist, dann lasse es halt. 🙄

Edbert (EvanE)

geokyf hat seit den nicht ganz 6 Wochen die er dabei ist, fast 2,400 Relationen bearbeitet. Ist mir fast unheimlich. Er schafft lieber als zu reden 😉

Könnte mich mal noch jemand aufklären. Die Grenzen in Thüringen wurden gelöscht weil die entsprechende Wikipedia Quelle wohl aus einen Atlas abgemalt wurden.

Ich habe nur mal eine Stichprobe gemacht und konnte kein source tag sehen für die neu erstellten Grenzen in Thüringen. Aus welcher Quelle wurden die Grenzen denn jetzt erstellt ?

Wie schon geschrieben. Ich habe hier ein riesiges Loch zu stopfen, an dem man auch mit Sonderschichten noch Wochen und Monate zu tun hat. Konflikte gibt es hier und da auch so täglich. Nun gibt es zwei Möglichkeiten. Entweder mache ich Meter und vervollständige das was durch den LW verloren gegangen ist, oder ich verbringe Stunden nur mit Hintergründen, Erklärungen usw. und ziehe das ganze womöglich auf ein Jahr. Die Zeit habe ich leider nicht und ich bin auch leider nicht der Typ Erklärbär. Dann muss es leider so bleiben wie es ist und ich konzentriere mich auf das wo es keine Probleme gibt, bevor ich wieder weniger Zeit habe.

SunCobalt wrote:

geokyf hat seit den nicht ganz 6 Wochen die er dabei ist, fast 2,400 Relationen bearbeitet. Ist mir fast unheimlich. Er schafft lieber als zu reden 😉

Der Großteil davon sind Landuses, die ich früher dummerweise als geschlossene Flächen an den Kannten übereinander gelegt hatte. Fürchterlich zu bearbeiten und mit den Multipolys funktionierte das damals auch nicht richtig. Und das geht desshalb so schnell, weil ich noch aus meinem Altbestand (vorher Mirko Küster) schöpfe, der gleich aktuallisiert und verbessert wird. Nun kann man sich ausmalen, wie viele Daten das sind und was ich da für einen Druck habe, dass wieder sauber und möglichst Konfliktfrei wieder einzubauen. Alles kommt aber nicht wieder.

geokyf wrote:

Kann mal bitte jemand Kerstin Inger, King-Kelch, Alex Grimme und keine Ahnung wer da noch so alles herum fummelt, bremsen?

Ich habe die drei Mapper soeben angeschrieben und um Stellungnahme gebeten.

Gruß,
Mondschein

Hm, "Kerstin Inger" hat sich soeben in "Superkirsche" umbenannt.
Seit wann kann man denn eigentlich den Benutzernamen ändern?
Habe erst jetzt bemerkt, dass das geht. 🤔

Gruß,
Mondschein

Danke für deine Mühe. Ich hoffe, da kommt wenigstens eine Antwort, da wartet man leider oft vergeblich. Deswegen wollte ich das auch erst einmal liegen lassen. Keine Ahnung was man nun machen soll, wenn da nichts kommt. Revert wird schwierig, weil da teilweise paralel gearbeitet wurde und eben zigfach andere Objekte eingebunden sind. Ich könnte das nur wieder Stück für Stück aufdröseln und durch meinen alten ersetzen.

Mondschein wrote:

Ich habe die drei Mapper soeben angeschrieben und um Stellungnahme gebeten.

Gruß,
Mondschein

Hallo, ich hatte den User "Superkirsche" auch unabhängig davon angeschrieben.
Die Gruppe neuer Benutzer will die Gemeindegrenzen in Thüringen vervollständigen, ist aber wohl etwas übers Ziel hinaus geschossen.

Ich habe alexgrimme vorgeschlagen, deren Idee und Projekt hier um Forum vorzustellen, in der Hoffnung, die alten Hasen können bei der weitern Umsetzung und Fehlerkorrektur untersützen.

Die Idee und die Daten -und auch die investierte Arbeit- sind sicherlich eine prima Sache, wenn man etwas Feintuning reinbringt. Und Zusammenarbeit wird ja hier sowieso groß geschrieben. 🙂

Gruß Markus

Markus366 wrote:

Die Gruppe neuer Benutzer will die Gemeindegrenzen in Thüringen vervollständigen, ist aber wohl etwas übers Ziel hinaus geschossen.

Das ist aber noch milde ausgedrückt. Da wurde teilweise zu dritt oder gar viert paralel die gleich Grenze angelegt, alle anders, oft auch ohne Tags. Alles geschlossene Ringe, die in teils nicht auswertbaren Relationen liegen. Dabei hat man die Linien oft auch schön aufeinander gelegt, oder Objekte anderer mitgenommen und verschoben. Das zieht sich von Niedersachsen bis Sachsen. Die sollen sich bitte erst einmal im Wiki in Grenzen und Realtionen einarbeiten. Gut und schön wenn man helfen will, nur wird das wieder aufräumen mindestens 5 mal so lange dauern.

Ja, das Problem besteht jetzt.

Wenn die neue Gruppe (ich nenn das jetzt einfach mal so) jedoch unter erfahrener Hilfe das ganze weiter durchzieht und gemachte Fehler korrigiert bzw neu gestalltet, sehe ich großen Nutzen darin. Die neuen Eintragungen und die damit verbundenen Probleme sind nunmal da. Wenn jetzt die "alten Hasen" über die Neuen schimpfen und kurzfirstig das große Löschen und Reparieren anfangen, dann wird das am Ende für keinen Beteiligten ein befriedigendes Ergebnis bringen.
In "meiner" Gegend (an der auch "gewerkelt" wurde) wäre ich grundsätzlich echt froh, wenn dort endlich Gemeindegrenzen (vernünftig) eingezeichnet werden.

Ich hoffe sehr, dass sich die Gruppe im Forum oder sonst wo meldet, und dann in Zusammenarbeit mit erfahrenen Usern die Sache weiter verfolgt.

Markus

Mondschein wrote:

Hm, "Kerstin Inger" hat sich soeben in "Superkirsche" umbenannt.
Seit wann kann man denn eigentlich den Benutzernamen ändern?
Habe erst jetzt bemerkt, dass das geht. 🤔

Das ging immer schon. Die Daten "wandern" aber mit, d.h. die von "Kerstin Inger" erstellten Objekte erscheinen jetzt bei "Superkirsche"

Gruss
walter

wambacher wrote:

Mondschein wrote:

Hm, "Kerstin Inger" hat sich soeben in "Superkirsche" umbenannt.
Seit wann kann man denn eigentlich den Benutzernamen ändern?
Habe erst jetzt bemerkt, dass das geht. 🤔

Das ging immer schon. Die Daten "wandern" aber mit, d.h. die von "Kerstin Inger" erstellten Objekte erscheinen jetzt bei "Superkirsche"

Hallo Walter

Nur zum Teil. In der Objekt-History steht weiter der damalige Name. Die UID bleibt natürlich gleich.

In der Liste der Changesets unter dem neuen Usernamen sollten aber alle Edits einer User-ID versammelt sein auch die früheren, die noch unter dem alten Namen erstellt wurden. Dumm nur, wenn man den User unter dem alten Namen sucht. Über die Nummer des Changesets geht es natürlich.

Edbert (EvanE)

Markus366 wrote:

Wenn die neue Gruppe (ich nenn das jetzt einfach mal so) jedoch unter erfahrener Hilfe das ganze weiter durchzieht und gemachte Fehler korrigiert bzw neu gestalltet, sehe ich großen Nutzen darin.

Da muss ich jetzt mal weiter ausholen. Bis vor zwei Jahren war ich hier unter Mirko Küster aktiv, warum dann nicht mehr usw. steht im Lizenzwechsel Thread. Die von mir u.a. erfassten Grenzen wurden wegen Nichtzustimmung mit dem Lizenzwechsel gelöscht. Daher kommt das große Loch in in süd S-A und Nordthüringen. Ich habe die Daten aber alle noch fix und fertig da, auch die Grenzen, die ich, natürlich an zwischenzeitliche Veränderungen und neue Tags angepasst, direkt wieder einbauen kann. Das wieder einbauen geht aber asymetrisch, weil es so viel ist und mich auch Leute anschreiben, die gerne dieses und jenes gerne wieder hätten. In den zwei Jahren meiner Abweseheit war da nämlich nicht viel mit Remapping. Nur geht das eben nicht alles und sofort, sondern nur in Häppchen. An den Grenzen war ich gerade dran, als die "Gruppe", hier rundherum loslegte.

So und nun habe ich das Problem. Das ich mit diesen neuen Daten nicht viel, oder besser gesagt gar nichts anfangen kann. Die bis dato extrem goben Sachen dann irgendwie hinzubiegen und das vielleicht noch unter Anleitung, ist mir zeitlich nicht möglich und bei fertigen vorhandenen Daten auch eher suboptimal. Die ganzen zerfetzten Relationen und Linien sind kompliziert genug. Die müssen gefunden, identifiziert und entsprechend behandelt werden. Das sitzt man so schon manchmal 30 Minuten an nur einem Ort, mit neu drüberbügeln ist es leider nicht getan.

Nun ist die Frage, was nun? Entweder fixe ich das wie gehabt und baue die alten Grenzen wieder ein, was in 7 Tagen maximal komplett durch sein sollte. Oder ich schmeiß meine Daten weg und lass die "Gruppe" weiter machen. Nur kann ich da leider nicht mithelfen, da liegen noch tausende andere Sachen, zig Leute drängeln, ich ziehe in drei Wochen um und ich sehe hier kein Licht. Ich kann es nicht entscheiden.

geokyf wrote:

Da muss ich jetzt mal weiter ausholen.

Der Umfang der Sache war mir vollkommen unbewusst, aber erstmal Danke für die Einarbeitung der "neuen/alten" Daten.

Die "Gruppe" besteht aus vermutlich aus Superkirsche axelgrimme und king-kelch.
Mit axelgrimme hatte ich kurz geschrieben. Mein Eindruck ist, dass man mit gutem Willen und viel Motivation gearbeitet hat - nur leider ging der Schuss nach hinten los und nach dem lesen deines Post's wohl noch mehr, als ich dachte. Die heftige Reaktion im Forum und die Mails kamen dann wohl recht überraschend für die Gruppe.
Eine Rückantwort seit heut Nachmittag habe ich aber noch nicht.

Ich glaube/hoffe aber, dass die User kooperationsbereit und vernünftig sind. Sobald ich wieder Verbindung habe, bitte ich die User, erstmal die Füße still zu halten und ihre Aktion zu pausieren.

Wer Welche Daten einbringen soll, kann ich auch nicht sagen - hier bin ich ja nur die kleinste Leuchte mit begrenzter Ahnung.
Vielleicht könnten sich hier kurzfristig ein paar "Schwergewichte" einbringen, um das mal durchzudiskutieren.

Markus

Markus366 wrote:

Die "Gruppe" besteht aus vermutlich aus Superkirsche axelgrimme und king-kelch.

Seite heut frisch dabei "annsin", der im Burgenlandkreis und im Ecihsfeld was gemacht hat. Auch mit gleicher Art Kommetar, dürfte also definitiv dazu gehören.

Mit axelgrimme hatte ich kurz geschrieben. Mein Eindruck ist, dass man mit gutem Willen und viel Motivation gearbeitet hat - nur leider ging der Schuss nach hinten los und nach dem lesen deines Post's wohl noch mehr, als ich dachte. Die heftige Reaktion im Forum und die Mails kamen dann wohl recht überraschend für die Gruppe.

Wenn mal irgendwo was daneben geht, ist das ja nicht so schlimm. Passiert jedem mal und auch ich habe schon massig Murks fabriziert. Nur hier hat man wohl den Sinn und Aufbau der Relationen nicht, oder nur halb gelesen, Objekte Dritter, die eigetlich nichts mit der Grenze zu tun haben - Stichwort Filter setzen- , verschoben und das über ein riesen Gebiet. Als ich das enddeckte, wurde ich ganz kurz weiß im Gesicht.

Wer Welche Daten einbringen soll, kann ich auch nicht sagen - hier bin ich ja nur die kleinste Leuchte mit begrenzter Ahnung.
Vielleicht könnten sich hier kurzfristig ein paar "Schwergewichte" einbringen, um das mal durchzudiskutieren.

Da gab es schon Anmerkungen zu. Ausdiskutieren und wenn nötig die Datenarbeitsgruppe involvieren. Wenn ich aktuell die Zeit hätte, kein Problem, habe ich aber nicht. Mir wäre am liebsten, wenn das auf dem kleinen Dienstweg schnell und einfach zu klären wäre. Ich will nur wissen, geo hau rein oder geo hau ab. Da muss man keinen Passierschein A38 draus machen. 😄

geokyf wrote:

Ich will nur wissen, geo hau rein oder geo hau ab. Da muss man keinen Passierschein A38 draus machen. 😄

Ok, Problem verstanden.

Trotzdem möchte ich dich zumindest bis morgen (Abend) um Geduld bitten, ich habe den Leuten geschrieben und das nochmal mit Nachdruck dargelegt. Auch auf den Beitrag intensiv hingewiesen.

Ich fänds Klasse, wenn deine alten, umfangreichen Daten wieder da wären, finde es aber auch nicht richtig, jungen "übereifrigen" - vielleicht auch unvernünftigen Usern so einen Dampfhammer zu verpassen und deren (sicher auch harte Arbeit) wegreißen --- solange es anders geht.

Können wir uns darauf verständigen?

Markus

PS: Ich bin hier als kleine Leuchte eigentlich immer noch der falsche Ansprechpartner, da gibts Leute mit Millionen Edits und Milliarden Forenbeiträgen - wär schön, zumindest da noch kurzfristig ne zweite/dritte Idee und Unterstützung zu bekommen.

PPS: vielleicht sind's ja die Borg von Captain Picard - WIR WERDEN EURE GEMEINDEGRENZEN ASSIMILIEREN - WIDERSTAND IST ZWEKCKLOS 🤣 - musste mal sein

Bei OSM gibt es kein "Du darfst das hochladen und ihr dürft es nicht". Wenn man meint, dass Daten fehlen, dann kann und soll man die fehlenden Daten ergänzen. Das Problem solltet ihr untereinander versuchen zu lösen. Eine Möglichkeit wäre, dass Mirko seine Grenzdaten in einer Datei zur Verfügung stellt und die Gruppe pflegt die Daten mit ein.

Markus366 wrote:

Trotzdem möchte ich dich zumindest bis morgen (Abend) um Geduld bitten, ich habe den Leuten geschrieben und das nochmal mit Nachdruck dargelegt. Auch auf den Beitrag intensiv hingewiesen.

Ist kein Problem, solange wird etwas anderes gemacht.

aighes wrote:

Bei OSM gibt es kein "Du darfst das hochladen und ihr dürft es nicht". Wenn man meint, dass Daten fehlen, dann kann und soll man die fehlenden Daten ergänzen.

Ich habe erst einmal drumherum gearbeitet. Nordhausen ist soweit wieder da. Irgendwo gab es da in der Ecke aber einen Fehler in der AGS Karte. Da war irgendwo eine dieser neuen Verbandsgemeinden, eigentlich alt weil seit glaube 2010 so und die zählen ja eigentlich als eines, der Rest sind Ortsteile. Bei Kaiserpfalz, Finne etc. ist das auch so in der AGS Karte. Dort war aber die Verbandsgemeinde in den Daten der AGS Karte nicht existent und nur die Einzelgemeinden ausgewiesen. Das muss ich nochmal prüfen.

aighes wrote:

Das Problem solltet ihr untereinander versuchen zu lösen. Eine Möglichkeit wäre, dass Mirko seine Grenzdaten in einer Datei zur Verfügung stellt und die Gruppe pflegt die Daten mit ein.

Das wäre wieder doppelte Arbeit, weil die in einem ganzen Backup stecken und ich die Neuer- und Verbesserungen direkt mache und nur Teile der Geometrien kopiere. Das geht extrem schneller direkt umzusetzen, als es irgendwie fehlerunanfällig und und kopierfertig bereit zu stellen. Die ganz neuen Ortsteilgrenzen gehen sowieso nicht, die habe ich nur anhand historischer Beschreibungen und vor Ort gefundener Grenzsteine vorliegen. Die muss ich, wenn ich Ruhe habe, ersteinmal zeichnen. Dafür braucht es aber erst einmal fertige Ortsgrenzen.

Hallo liebe OSM Community,
Sorry für die verspätete Meldung, aber wir mussten uns intern erstmal abstimmen.
Unsere "Gruppe" besteht aus mir, king-kelch, superkirsche und annsin.

Wir wollten um Gottes Willen nichts Böses ... unser Anliegen war nur die offenen Löcher zu stopfen.
Das wir dabei so ein Chaos anrichten bzw. diese Grenzen früher bereits vorhanden waren wussten wir nicht. Sorry dafür!

Ich habe mir hier alle betreffenden Beiträge durchgelesen und bin wirklich erschrocken. Damit hatten wir überhaupt nicht gerechnet.
Es ist natürlich auch in unserem Interesse, dass hier möglichst alles nach Norm und schön sauber durchgeführt wird.
Aktuell haben wir sämtliche Arbeiten vorerst eingestellt - bis wir hier eine Lösung gefunden/erarbeitet haben.
Nach Durchsicht aller Beiträge also nun ein paar Fragen meinerseits:

Wie geht es weiter?
Da laut User geokyf wohl alle Grenzen an denen wir arbeiten noch vorhanden sind (in ordentlicher Form) ist es sicherlich sinnvoller diese Daten auch wieder zu verwenden, oder?
Wenn ja, sollten alle unsere Arbeiten gelöscht werden.

Ist es möglich alle unsere geschaffenen Grenzen und Daten wieder zu löschen?
Ich hoffe das ist möglich ... wir haben aber auch detailierte Logs und eigene Aufzeichnungen zu allen erstellten Grenzgebieten erstellt.

MEIN VORSCHLAG
Falls möglich, so könnten wir alle von uns angelegten Daten löschen und würden geokyf mit den bereits vorhandenen Daten diese Gebiete auch wieder überlassen.

_____________________________________________________________________

Noch eine Bitte: Wir haben nun mehrfach PNs bekommen oder Emails. Lasst uns alles weitere bitte hier im Forum klären - rein aus Gründen der Übersicht.
Ich vertrete hier unsere "Gruppe".

Wir sind natürlich an einer Lösung interssiert, welche für Alle hier die Beste ist - also lasst uns daran arbeiten.
Das bekommen wir schon hin. Nochmals sorry für das Choas - es war gut gemeint.

Freue mich auf Antworten.
Liebe Grüße und vorab schonmal ein schönes Wochenende!

Alex (nicht Axel 😄)

Hallo Alex,

es nimmt euch keiner krumm, dass ihr da etwas machen wolltet. Grenzen sind eine teils komplexe Sache und die meisten sind sicher froh, wenn da ein Haken hinter ist und der Kelch ihrer erfassung an ihnen vorüber ging. Das Problem ist nur, wie das passierte und welche Auswirkungen das so hat. Als erstes solltet ihr euch wirklich mal in die Sache richtig einlesen, vorhandene Beispiele anschauen, richtig abstimmen und dann in Ruhe loslegen.

Grenzen sind in OSM keine Shapes, sondern aufgeteilte Linien, die im Multipolgon zusammen gefasst werden. Angrenzende Grenzen teilen sich die selben Wege. Deshalb nutzt man das Multipolygon, was bei einem geschlossenen Kreis überflüssig wäre, weil man die Daten z.B. mit einem zusätzlichen area=yes auch direkt daran taggen könnte. Das machen wir aber nicht, weil sich überlagernde Linien schlecht bearbeiten lassen, Überschneidungen der gleichen Wegeart grundsätzlich Fehler sind und das dürfte euch Josm in Form von Warnungen und Fehlern auch oft genug angemeckert haben. Ausserdem gibt es machmal innenliegende Sachen die zu etwas anderem gehören und ausgeschnitten werden müssen. Das was da raus muss, gehört dann zusätzlich zu etwas anderem.

Wenn man keine exakten Grenzen oder exakt liegende Grenzsteine hat, zeichnet man die am besten in einem eigenen Layer, oder blendet mit Hilfe vom Filter alles aus, verbindet das dann erst hinterher. So kann es nicht passieren, dass man irgendetwas anderes berührt und vielleicht ungewollt mit einbindet oder gar verschiebt. Auch hier gilt, keine Linien stapeln. Habe ich die wirklich offizielle exakte Information, genau Wegmitte oder Flussmitte ist Grenze, kann ich den Abschnitt dieses Weges aufspalten und als Grenzteil mit in der Grenzrelation nutzen. Das mache ich aber auch nicht, weil wir keine exakten Daten haben und Angaben manchmal missverständlich sind. Dann lege ich paralel. Als Beisüpiel hattet ihr z.B. die Unstrut irgendwo bei Nebra mitgenommen. Die Information Flussmitte stimmt, aber hier ist die Flussmitte von vor der Begradigung zur Schiffbarmachenung gemeint. Die Grenze schlängelt da also in Wahrheit eher hin und her und hat mit der heutigen Unstrut nicht mehr viel gemein. Gewässer wandern auch. Was 1800 schlagmichtot mal fesgelegt wurde, kann heute auch bei unbegradigten Flüssen weitab liegen. . Wenn also unklar, dann zur Sicherheit erst einmal paralel legen und auf exaktere Informationen warten.

An eurer Abstimmung müsst ihr arbeiten. Da wurde teilweise paralel an der gleichen Grenze gearbeitet und die liegen dann nicht einmal übereinander und grenzen aneinander, da hat jeder seine eigene Interpretation hochgeladen. Das Ergebniss sind zahlreiche Doppelungen, Überlagerungen und viele Überschneidungen. Teils auch schlecht zu identifizieren, weil manche Wege komplett ohne Merkmale sind, Relationen ganz fehlen oder nicht dir zur Identifikation nötigen Informationen haben.

Reverten muss man das alles nicht, auch wenn dass natürlich erstmal suboptimal für das verschobene ist, aber das dürfte nun auch nicht mehr konfliktfrei funktionieren. Das geht nur sauber bei Objekten, die hinterher nicht mehr angefasst wurden. Durch die paralele Bearbeitung eurerseits und dadurch das hier und da sicher schon einer tätig wurde, bei dem riesen Gebiet mehr als wahrscheinlich, ist das Kind nun in den Brunnen gefallen. Man kann es versuchen, wird aber durch die Konflikte nicht ohne. Bin ich aber gewohnt, weil ich beim wieder einpflegen und involvierten großen Relatiionen sowieso immer das Problem habe, Konflikte auflösen zu müssen, weil man arbeitet ja nunmal nicht immer alleine an so langen Wegen.

Ich weiß nun nicht wie weit ihr schon tätig gewesen seit. Ich habe alles für KYF, NDH, SÖM, MSH, SK und BLK und die eine oder andere kleine angrenzende da. Die kann ich wieder einpflegen, wenn ich grünes Licht zum Revertversuch und zum Fiixen bekomme. Der Rest war nicht von mir und da kann ich auch nichts zu sagen, geschweige denn irgendwas entscheiden. Südthüringen war soweit ich mich erinnere Lobelt Gebiet. Der ist weg und da dürfte nichts mehr zurück kommen. Da könntet ihr euch unter Berücksichtigung des oben genannten und in Abstimmung mit vielleicht aktuell Betroffenen, die sich schon bei euch gemeldet haben, komplett austoben.

Gruß
Mirko

Hi, und vielen Dank für die schnelle Antwort.
Okay, also ich bin zu wenig in der Materie als dass ich selbst bei deinem Kommentar alles verstanden habe ... aber das ist ja nun auch egal bzw. nicht mehr änderbar.
Ich habe wie gesagt aktuell alle Arbeiten meiner Gruppe angehalten. Wenn nötig werde ich hier eine komplette Liste der Grenzen anheften, welche wir bearbeitet haben.
Von meiner Seite gäbe es dann also auf jeden Fall ein deutliches JA für den Revertversuch. Wie das im Einzelnen abläuft weiß ich aber nicht?!

Also wenn die erwähnte Liste hilfreich ist, dann bitte Bescheid sagen.
Ansonsten würde wir uns raushalten und nun dir/euch die Grenzen dieses Gebietes überlassen.

Liebe Grüße
Alex

Sorry, musste zwischendruch zur Kabelreparatur in meiner KGA.

Ok, so eine Liste für einen Überblick wäre nicht schlecht, da können dann Ortskundige gezielt schauen und entscheiden ob sie das lassen, verbessern oder besser doch ganz reverten. Das muss man im einzelnen begutachten. Zum Revert. Zum Glück habt ihr ja jede Grenze in ein einzelnes Set gesteckt. Ich versuche dann, in den oben genannten Ecken, die ich verarzte, jedes Set einzeln rückgängig zu machen, wenn es nötig ist. D.h. ich reverte nur das jeweils einzelne Set für die Grenze, wenn da andere Objekte mitgenommen wurden. Es wird dann quasi der Zustand von vor eurer Arbeit wiederhergestellt. Schade um eure Arbeit, aber so werden die verschobenen Sachen anderer wieder richtig gerückt. Sollte das nicht ohne unlösbare Konflikte möglich sein, versuche ich das manuell zu fixen. Also Linie heraus und Objekte die verschoben wurden, anhand eines alten Backups wieder dahin setzen, wo sie ursprünglich lagen.

Das Rad wird also nicht komplett zurück gedreht. Da wo vorher nichts war und auch keiner mehr etwas zusteuern kann, könntet ihr unter Mithilfe der lokalen eure Sachen ja noch weiter bearbeiten und in die übliche Form bringen. Das wäre dann gleich auch die Praxisübung, bevor ihr wieder woanders ganz neue Grenzen einbaut. Wenn man erst einmal weiß wie, ist das gar nicht so schwer. Der mögliche Shitstorm erübrigt sich und lokalen dürften sich eher freuen.

Hallo Axel und Kollegen,

wenn euer Tatendrang ungebremst ist, es gäbe da noch etwas :-)
Ich habe Gemeinden, Ämter etc. herausgelfiltert die keinen Regionalschlüssel oder Namensprobs haben.
Wenn ihr daran Interesse habt kann ich euch gerne in das Thema einführen. Freiwillige vor !

ludwich

Kann es sein, dass die Karte bei manchen Grenzen etwas hängt?

Folgende Grenzen sind schon lange wieder drin, haben alle Angaben, sind sortiert, geschlossen und entventuell vorhandene alte Doppelungen entfernt, werden aber weiterhin als fehlerhaft oder nicht existent bemängelt.

15084207 Gutenborn
15084235 Hohenmölsen
15084315 Lützen
15084442 Schnaudertal
15084550 Weißenfels
15084590 Zeitz
15088020 Bad Dürrenberg
15088065 Braunsbedra

Da gab es teilweise schon Grenzen, allerdings oft nur die jeweiligen Kernorte. Die sind raus und nun wieder korrekt.

Bugenlandkreis und Saalekreis sind auch wieder komplett da, inklusive O/ST, PLZ und auch den TMC die ich noch hatte. Protected Areas mache ich später, die sind nicht so eilig. Mansfeld-Südharz ist in Arbeit, Arnstein habe ich wieder nach Anhalt geholt, nachdem Superkirsche einen preußischen Brückenkopf im bayerischen Arnstein errichtet hatte. 😄 Danach steht nur noch Sömmerda aus, bis zum Wochenende dürfte ich dicke durch sein. Zum Rest kann ich leider nichts beitrage, da sind die dortigen lokalen gefragt.

Edit: Kaum hatte ich das abgeschickt, war der Fehler auch schon behoben. Da hatten wohl zwei gerade den gleichen Gedanken.

geokyf wrote:

Kann es sein, dass die Karte bei manchen Grenzen etwas hängt?

Folgende Grenzen sind schon lange wieder drin, haben alle Angaben, sind sortiert, geschlossen und entventuell vorhandene alte Doppelungen entfernt, werden aber weiterhin als fehlerhaft oder nicht existent bemängelt.

15084207 Gutenborn
15084235 Hohenmölsen
15084315 Lützen
15084442 Schnaudertal
15084550 Weißenfels
15084590 Zeitz
15088020 Bad Dürrenberg
15088065 Braunsbedra

Keine Ahnung ob ich dich richtig verstanden habe, aber zumindest die letzten drei Relationen gibt es nicht (mehr) in den OSM-Daten. Die anderen hab ich nicht geprüft.

Gruss
walter

wambacher wrote:

Keine Ahnung ob ich dich richtig verstanden habe, aber zumindest die letzten drei Relationen gibt es nicht (mehr) in den OSM-Daten. Die anderen hab ich nicht geprüft.

Gruss
walter

Er hat sicher meine Karte gemeint, da waren die Gemeinden vor meinem Update heute noch als Fehler drin

Die Zahlen sind keine OSM IDs sonder der AGS, die angegebenen Gemeinden sind schon alle in den OSM Daten drin, nur wurden sie bei mir versehentlich noch als Fehler gelistet.

Mansfeld-Südharz und Sömmerda sind nun auch wieder komplett und damit bin ich vorerst durch. Legendäre Orte wie Muschwitz oder Unterkaka sind nun auch wieder per Grenze auffindbar. 😄

Ich weiß aber nicht, ob ich auch alles erwischt habe. Mit Revert war zwecklos, weil da teilweise schon andere dran waren oder manche Grenzlinie ohne Tags bis zu 5 mal übereinender vorhanden war. Da muss was ganz heftig schief gelaufen sein. Da lagen auch noch tote Lines von anderen herum. Ganz zu schweigen von dutzenden sinnlosen Luftbildgrenzen, die keiner braucht und die da nur stören. Von den alten Relationen werde ich auch nicht alle erwischt haben, einige könnten auch zu angrenzenden Gebieten gehören und habe die so gelassen.

Wollte mal nur bemerken, dass heute am 12.09.2012 (zufällig auch der Wechseltag zur ODbL) auf ags.misterboo.de die Anzahl der Fehler vom Typ 1 (vorhandene, aber kaputte Grenzrelation) auf 1 (!) gesunken ist, und dies innerhalb ganz weniger Wochen!!

Vielen Dank an alle fleißigen Grenzmapper und -reparierer!

PS: da dieser Thread ja schon sehr lang ist, wie wärs jetzt mal mit einem neuen Tread zu ags.misterboo.de, quasi in der ODbL-Ära?

Hallo Misterboo,

kannst Du Admin-Relationen als fehlerhaft kennzeichnen, wenn
type=boundary gesetzt ist und admin_level=* vorhanden ist, aber boundary=administrative fehlt?

Gemäß [1] soll das in Kombi vorkommen, Ich hatte eben bei Neumünster (AGS 01004000) festgestellt, das dort der Key boundary fehlt und nur auf admin_level prüfen ist mir zu unsicher, um eindeutig eine administrative Grenze zu erkennen. Es gibt noch einige wenige weitere Fälle (admin_level=4 oder 6 oder größer als 8).

Grüße

Dietmar aka okilimu

[1] http://wiki.openstreetmap.org/wiki/DE:Relation:boundary

Hallo Allgemein und auch speziell Misterboo,

ich habe bei Lübeck gesehen, das es eine Relation gibt für die städtische Admin-Grenze #27027 (boundary=administrative) und wohl eine für die Kreisstadtgrenze #62463 (land_area=administrative).

Auf der deutschen OSM-Wiki-seite [1] fehlt eine Erläuterung des land_area Keys. Dieser wird nur auf der englischsprachigen Seite beschrieben [2].
Im englischen steht eigentlich, das 2 Relationen dann genommen werden sollen, wenn es Gebietsunterschiede gibt, die sehe ich aber nicht.
Ich werde den deutschen Text nicht ergänzen, weil ich davon heute zum erstenmal gelesen habe und nicht mitbekommen habe, wo darüber schonmal diskutiert wurde.

Die Kreisstadt-Relation enhält neben dem Gemeindeschlüssel auch den 12stelligen Regionalschlüssel, das ist doch verkehrt, oder?

Für Neumünster gibt es nur die Kreisstadt-Relation, also keine Relation mit boundary=administrative.

Nach meiner Recherche sind das wenige Einzelfälle. Sind diese berechtigt und fehlen ggfs. Relationen bei den weiteren kreisfreien Städten Deutschlands?

[1] http://wiki.openstreetmap.org/wiki/DE:Relation:boundary
[2] http://wiki.openstreetmap.org/wiki/Relation:boundary

okilimu wrote:

Hallo Misterboo,

kannst Du Admin-Relationen als fehlerhaft kennzeichnen, wenn
type=boundary gesetzt ist und admin_level=* vorhanden ist, aber boundary=administrative fehlt?

Gemäß [1] soll das in Kombi vorkommen, Ich hatte eben bei Neumünster (AGS 01004000) festgestellt, das dort der Key boundary fehlt und nur auf admin_level prüfen ist mir zu unsicher, um eindeutig eine administrative Grenze zu erkennen. Es gibt noch einige wenige weitere Fälle (admin_level=4 oder 6 oder größer als 8).

Grüße

Dietmar aka okilimu

[1] http://wiki.openstreetmap.org/wiki/DE:Relation:boundary

Keine Ahnung wie das da hinkam. Ich vermute mal ich habe aus Versehen 2 Relationen markiert als ich bei Wismar was geändert habe (Da wismar in dem gleichen Änderungssatz ist) Ich habs gerade korrigiert.

okilimu wrote:

ich habe bei Lübeck gesehen, das es eine Relation gibt für die städtische Admin-Grenze #27027 (boundary=administrative) und wohl eine für die Kreisstadtgrenze #62463 (land_area=administrative).

Das war in [1] schon mal Thema.

Getan hat sich seitdem wohl nichts mehr.

Christian

[1] http://article.gmane.org/gmane.comp.gis … uebeck/436

Ich bin aktuell nicht so ganz auf dem Laufenden und konnte auf die Schnelle nichts finden

In der neuen Wochennotiz sind ja die neunen Geodaten des Bundes erwähnt, für die Grenzen ist der VG250 Datensatz interessant

http://www.geodatenzentrum.de/geodaten/ … _user_id=0

Erlaubt die Open Data Lizenz des Bundes ein verwenden der Daten ?

Hier mal ein Vergleich des Grenzverlaufes der VG250 Daten

http://ags.misterboo.de//test/?zoom=12& … 00000TTFFT

blau = Gemeindegrenzen in den OSM Daten
rot = Gemeindegrenzen VG250

Eine Bereicherung wäre es wohl in vielen Gegenden.

Also ich finde die Daten mal nach ersten Begutachten gut, in manchen Gebieten sind die Grenzen genauer als die vorhandenen OSM Daten.

Es sollte auf jeden Fall eine Hilfe sein für die momentan noch fehlenden knapp 200 Gemeinden.

Laut Info dürfen wir die Daten verwenden.

Wer den Layer in Josm einbinden möchte als Hintergrund:

Layer VG250 Gemeinden © GeoBasis-DE / BKG

http://tiles.misterboo.de/list/#VG250/

misterboo wrote:

Laut Info dürfen wir die Daten verwenden.

Link?

Oli-Wan wrote:

misterboo wrote:

Laut Info dürfen wir die Daten verwenden.

Link?

Link habe ich keinen. Ich hatte Joachim per Email gefragt. Ich vermute ja, da er die Sachen etwas koordiniert, dass er entsprechend beim Ministerium nachgefragt hat.

Die genauen Nutzungsbestimmungen sind hier

http://www.geodatenzentrum.de/docpdf/geonutzv.pdf

misterboo wrote:

Link habe ich keinen. Ich hatte Joachim per Email gefragt. Ich vermute ja, da er die Sachen etwas koordiniert, dass er entsprechend beim Ministerium nachgefragt hat.

Die genauen Nutzungsbestimmungen sind hier

http://www.geodatenzentrum.de/docpdf/geonutzv.pdf

Ich hatte schon im Parallelfaden, wo Du die gleiche Frage gestellt hast wie hier, geschrieben, daß nach meinem Verständnis die Nutzungsbedingungen die Verwendung für OSM nicht erlauben. Um die von Dir verlinkte GeoNutzV (gelesen?) zu zitieren:

§ 3 GeoNutzV wrote:

Die Nutzer haben sicherzustellen, dass
1. alle den Geodaten, Metadaten und Geodatendiensten beigegebenen Quellenvermerke und sonstigen rechtlichen Hinweise erkennbar und in optischem Zusammenhang eingebunden werden;
2. Veränderungen, Bearbeitungen, neue Gestaltungen oder sonstige Abwandlungen mit einem Veränderungshinweis im beigegebenen Quellenvermerk versehen werden oder, sofern die geodatenhaltende Stelle dies verlangt, der beigegebene Quellenvermerk gelöscht wird.

Diese Bedingungen können bei einer Datenübernahme in OSM nicht eingehalten werden. Eine Übernahme von Daten in OSM wäre nur dann möglich, wenn das BKG zu unseren Gunsten auf die Bedingung des Quellenvermerks verzichtet oder eine Nennung auf der OSM-Quellenseite für ausreichend erklärt.

Dann würde ich mal DD1GJ bitten, etwas dazu zu sagen, ob er mit dem Ministerium schon gesprochen hatte.

Das "Problem" der Namensnennung bei CC-BY bzw. der "Datenlizenz Deutschland - Namensnennung" wurde von mir bereits vor einem Jahr dem Bundesinnenministerium (BMI) mitgeteilt. Man hat sich, wie in Baden-Württemberg und Bayern, nicht dazu entschlossen, die Daten auch unter ODbL zu veröffentlichen bzw. in den Verordnungen auf die Vererbungsproblematik näher einzugehen. Baden-Württenberg und Bayern akzeptieren die Nennung auf der OSM-Quellenseite und mir sind keine Gründe bekannt, wieso es der Bund nicht auch so handhaben sollte.

In persönlichen Gesprächen und Mails wurde mir gegenüber wiederholt bestätigt, dass wir die freigegebenen Geodaten aller Bundesbehörden für OSM-Zwecke nutzen können. Um dies nochmals öffentlich zu dokumentieren, werde ich den Vertreter des BMI bitten, nächsten Donnerstag (11.04.2013, 09:15) in seiner Open Data Keynote eine Erklärung zur Nutzung für OSM-Zwecke abzugeben.

http://www.rtg.bv.tum.de/index.php/en/f … r/programm

DD1GJ wrote:

In persönlichen Gesprächen und Mails wurde mir gegenüber wiederholt bestätigt, dass wir die freigegebenen Geodaten aller Bundesbehörden für OSM-Zwecke nutzen können. Um dies nochmals öffentlich zu dokumentieren, werde ich den Vertreter des BMI bitten, nächsten Donnerstag (11.04.2013, 09:15) in seiner Open Data Keynote eine Erklärung zur Nutzung für OSM-Zwecke abzugeben.

Das würde ich sehr begrüßen. Es ist wichtig, daß eine solche Erlaubnis auch für den gewöhnlichen Mapper, der an den persönlichen Gesprächen bzw. dem Mailverkehr nicht teilgenommen hat, nachvollziehbar dokumentiert wird. Ich möchte nur allzu gerne die hiesigen Gemeindegrenzen (wo möglich) mit den freigegebenen Daten verbessern - aber dazu muß ich sicher sein können, daß das zulässig ist. Alle Hochachtung vor Deinen vielfältigen Bemühungen bei diesem Thema - aber daß Dir jemand eine mündliche Zusage gegeben hat, reicht mir nicht. Wenn dieser Jemand sich nach einiger Zeit an eine solche Zusage "nicht erinnern" kann oder der nächsthöhere Beamte (bzw. Politiker) oder ein Nachfolger eine gegenteilige Auffassung vertritt, haben wir den Schlamassel und müssen die übernommenen Daten, die inzwischen vielleicht weiterbearbeitet wurden, entfernen und im Gegenzug den vorigen Bestand wieder ausgraben.

Da schließe ich mich an. Für neue Mapper ist das eh schwierig zu überblicken, welche Daten verwendet werden dürfen und auch zu verstehen dass "Open Data" nicht immer das heißt, was man als Laie vermuten würde. Ich muss zugeben, ich blicke da selbst immer noch nicht ganz durch.

Es wäre schön wenn Joachim einfach mal eine schriftliche Bestätigung anfragen könnte, so dass die Mapper die Sicherheit haben, dass sie die Daten, hier ganz besonders die VG250 mit den Gemeindegrenzen nutzen können.

Belibt doch mal locker. Joachim hat doch gerade geschrieben, dass er sich genau darum bemüht.
Die Frage ist allerdings wo man solche Dinge dann hinterlegt. Ja im Wiki. Aber meint ihr das es dort gefunden wird? Spätestens nach dem 10. dieser Schriftstücke wird das doch alles unübersichtlich, oder?

ein kurzer vergleich in meiner ecke zeigt aber, das diese VG250 Gemeindegrenzen auch nicht alle korrekt sind, vielleicht auf 50m genau. ein anderer vergleich mit örtlichen amtlichen karten zeigt dies auf.

Chenshi wrote:

ein kurzer vergleich in meiner ecke zeigt aber, das diese VG250 Gemeindegrenzen auch nicht alle korrekt sind, vielleicht auf 50m genau. ein anderer vergleich mit örtlichen amtlichen karten zeigt dies auf.

Das sagt ja schon der Name : VG250 bedeutet ein Massstab 1:250.000. Aber in vielen Gegenden sind die Grenzen ja bisher noch ungenauer. In Gegenden wo lokale Quellen da sind mit besserem Massstab sind diese natürlich zu bevorzugen.

misterboo wrote:

Dann würde ich mal DD1GJ bitten, etwas dazu zu sagen, ob er mit dem Ministerium schon gesprochen hatte.

DD1GJ wrote:

Um dies nochmals öffentlich zu dokumentieren, werde ich den Vertreter des BMI bitten, nächsten Donnerstag (11.04.2013, 09:15) in seiner Open Data Keynote eine Erklärung zur Nutzung für OSM-Zwecke abzugeben.

In der Keynote wurde OSM mehrfach positiv erwähnt. Das BMI kann prinzipiell unserer Lösung mit der Copyright-Seite zustimmen, allerdings entspricht die Verlinkung auf openstreetmap.org bzw. .de nicht den Vorstellungen des Ministeriums:

...
Ein Hinweis auf die Datenquelle als Link zu der von Ihnen angeführten Wiki-Seite muss daher zwingend in unmittelbarem optischem Zusammenhang mit der Kartendarstellung erfolgen.
...
Im Grunde ist es nur Fachleuten möglich, über die mehr oder weniger gut auffindbaren Hinweise bzw. mehrfach hintereinandergeschalteten Links auf die Wiki-Seite zu gelangen. Ich bitte Sie daher zu prüfen, ob es OSM technisch möglich ist, den Link auf die Wiki-Seite in unmittelbarem optischem Zusammenhang mit der Kartendarstellung anzubringen.
...

Einzelanfragen an die verschiedenen Datenbereitsteller des Bundes sind zwecklos, da alle Lizenzangelegenheiten zentral entschieden werden.

Oli-Wan wrote:

Ich hatte schon im Parallelfaden, wo Du die gleiche Frage gestellt hast wie hier, geschrieben, daß nach meinem Verständnis die Nutzungsbedingungen die Verwendung für OSM nicht erlauben.

Hier muss ich Dir zum jetzigen Zeitpunkt leider Recht geben. Ich habe bereits mit Frederik telefoniert und werde mich nächste Woche mit ihm treffen. Da es in Großbritannien wohl ähnliche Probleme gibt, soll sich die OSMF mit dem Thema befassen.

Hallo,
das ist doch aber nicht sehr sinnvoll. Soll dann jeder Kartenanbieter (meint nicht Renderer, sondern jemand der die Karte in seine Website einbaut) oder die Daten anderweitig nutzt auf die Wiki-Seite verlinken? Evtl. wäre es eine Lösung, die lange Liste aus dem Wiki in osm.org/copyright zu integrieren. Zugeklappt natürlich. Bei Interesse an weiteren Datenquellen, kann man das aufklappen. Evtl. ist das den Leuten direkt genug, auch wenn es technisch nicht viel anders ist, als das klicken eines Links.

Und mit verlaub: Kein normaler Nutzer interessiert sich dafür, aus welchen Quellen die Daten kommen.

Woran mag es eigentlich liegen, dass gefühlt seit Anfang 2013 der Dienst ags.misterboo.de die Relation für "Bremen" als Fehler1 meldet?

Hatte mir die Relation dazu wiederholt in JOSM geladen und konnte keine direkten Fehler finden.

Woran mag das liegen?

stephan75 wrote:

Woran mag es eigentlich liegen, dass gefühlt seit Anfang 2013 der Dienst ags.misterboo.de die Relation für "Bremen" als Fehler1 meldet?

Hatte mir die Relation dazu wiederholt in JOSM geladen und konnte keine direkten Fehler finden.

Woran mag das liegen?

Ich hatte nur mal kurz drüber gesehen ... da ist wohl ein Stück wo sich Ways kreuzen.

Edit: Obwohl das kann es eigentlich nicht sein, da das Stück bei der Relation 62559 (Bremen) exakt genau so drin ist

Hab mir Bremen auch noch mal genauer angeschaut:
Vielleicht liegt es daran, dass das outer mit einem Element (unten in der JOSM Liste) einen gemeinsamen Punkt mit dem größten outer-ring hat.

Der type "land_area" erscheint mir auch zumindest ungewöhnlich.

fx99 wrote:

Hab mir Bremen auch noch mal genauer angeschaut:
Vielleicht liegt es daran, dass das outer mit einem Element (unten in der JOSM Liste) einen gemeinsamen Punkt mit dem größten outer-ring hat.

Der type "land_area" erscheint mir auch zumindest ungewöhnlich.

type=land_area ... das könnte es sein, erkennt osm2pgsql überhaupt dieses type ?

Andere Landmassen haben type=boundary, sollen wir das ändern?

Nachdem jetzt Bremen gelöst ist, und auch die vielen thüringischen Gemeinden vollständig sind bleiben als "Fehler" nur noch:
Rheinland-Pfalz(1): 07000999: Gemeinsames deutsch-luxemburgisches Hoheitsgebiet und
Mecklenburg-Vorpommern(1): 13000999: Küstengewässer einschl. Anteil am Festlandsockel

zu 07000999 habe ich in Wikipedia folgendes Dokument gefunden: http://dip21.bundestag.de/dip21/btd/11/004/1100477.pdf

Hier heißt es:

Artikel␣1
(1)␣Wo␣Mosel,␣Sauer␣und␣Our␣nach␣dem␣Vertrag␣vom␣26.␣Juni
1816␣die␣Grenze␣bilden,␣sind␣sie␣gemeinschaftliches␣Hoheits-
gebiet␣beider␣Vertragsstaaten.
(2)␣Das␣gemeinschaftliche␣Hoheitsgebiet␣umfaßt␣die␣Luft-
säule␣oberhalb␣sowie␣den␣Erdsockel␣unterhalb␣der␣Wasserflä-
che␣innerhalb␣seiner␣seitlichen␣Begrenzung;␣dies␣gilt␣auch␣bei
oberirdischen␣und␣unterirdischen␣Bauwerken␣und␣Anlagen
jeder␣Art.␣Inseln␣im␣gemeinschaftlichen␣Hoheitsgebiet␣gehören
zu␣diesem␣Gebiet.

Wie kann man das in OSM realisieren?
Muss die Staatsgrenze zw. D und Lux, die soweit gesehen in der Flussmitte verläuft, in zwei Äste jeweils an einem Ufer
aufgeteilt werden? Oder gibt es andere Ideen?

Kann man statt der Linie im Fluss den way/relation "waterway=riverbank" in der Landesgrenze aufnehmen?
Schließlich ist die Grenze immer identisch mit der Wasserfläche...

reneman wrote:

Kann man statt der Linie im Fluss den way/relation "waterway=riverbank" in der Landesgrenze aufnehmen?
Schließlich ist die Grenze immer identisch mit der Wasserfläche...

nee, dann fliegen dir/uns die Multipolygone/Boundaries um die Ohren. Dort können nur Linestrings (also osm-Ways) Member sein. (*)

Gruß
walter

• ) wenn man mal von den Administrativen Zentren als Node absieht.
  

wambacher wrote:

reneman wrote:

Kann man statt der Linie im Fluss den way/relation "waterway=riverbank" in der Landesgrenze aufnehmen?
Schließlich ist die Grenze immer identisch mit der Wasserfläche...

nee, dann fliegen dir/uns die Multipolygone/Boundaries um die Ohren. Dort können nur Linestrings (also osm-Ways) Member sein.

Gruß
walter

Wenn man waterway=riverbank auch als Relation anlegt und rechtes und linkes Ufer trennt, dann sollte das schon gehen.

Das ist insofern auch gut, da im Vertrag steht, dass die Grenze immer mit dem Flussufer wandert.

fx99 wrote:

Wenn man waterway=riverbank auch als Relation anlegt und rechtes und linkes Ufer trennt, dann sollte das schon gehen.

Das ist insofern auch gut, da im Vertrag steht, dass die Grenze immer mit dem Flussufer wandert.

jo, das macht schon mehr Sinn. Jedes Land bekommt immer das Stück vom "andren Ufer". Dann überlappen sich deren Hohheitsgebiete zwar, aber das ist ja Sinn der Übung.

Gruss
walter

p.s. sieht aber beim Rendern etwas "komisch" aus 😉

jo, das macht schon mehr Sinn. Jedes Land bekommt immer das Stück vom "andren Ufer". Dann überlappen sich deren Hohheitsgebiete zwar, aber das ist ja Sinn der Übung.

Gruss
walter

p.s. sieht aber beim Rendern etwas "komisch" aus 😉

Bin gerade mal dabei, die Aufteilung lokal auszuprobieren ( am südlichen Ende der Grenze DE LUX, also Mosel)
Ist ein riesen Aufwand, da nicht nur die Staatsgrenzen gesplittet werden müssen, sondern alle
anderen administrativen levels ( typisch 4,6,8 beidseitig) sowie die diversen Variationen wie Landmasse DE usw.
Ich weiß nicht, wer sich die Mühe machen wird und ob sich das lohnt.

Beim Rendern sollte man zwei Level 2 Grenzen in nahem Abstand bekommen.

Nur mal als Frage: Bezieht sich das o.g. Dokument nur auf die Staatsgrenze oder auch auf die administrativen Grenzen?
Oder bleiben vlt. die administrativen Grenzen wo sie waren (in der Flussmitte)?
Und noch eins: Es ist eine Grenze zu einem Nachbarland, sollte man von diesem nicht auch eine Meinung einholen? 😉

reneman wrote:

Nur mal als Frage: Bezieht sich das o.g. Dokument nur auf die Staatsgrenze oder auch auf die administrativen Grenzen?
Oder bleiben vlt. die administrativen Grenzen wo sie waren (in der Flussmitte)?

Laut Wikipedia http://de.wikipedia.org/wiki/Gemeinsame … eitsgebiet gehört das Gebiet zu einem Bundesland aber zu
keiner untergeordneten Verwaltungseinheit.

reneman wrote:

Und noch eins: Es ist eine Grenze zu einem Nachbarland, sollte man von diesem nicht auch eine Meinung einholen? 😉

Guter Punkt: wie erreicht man die LUX Community?
Das oben zitierte Gesetz ist schon zweisprachig verfasst.

hab nur dies gefunden: http://lists.osm.org/listinfo/talk-lu

Edit: oder schau mal hier: http://wiki.osm.org/wiki/WikiProject_Luxembourg
http://wiki.osm.org/wiki/Category:Users_in_Luxembourg

Ich finde es zumindest bemerkenswert, dass in den OSM-Daten nun die Grenzen aller politischen Gemeinden (jene mit AGS) in Deutschland enthalten sind!!!

Vielen Dank an die fleißigen Lückenfüller!

Sollte es dazu eine kleine Meldung in den OSM- Blogs geben?

Aktuell sind alle Bundesländer, Kreise und auch alle Gemeinden mit den Grenzen erfasst samt amtlichem Gemeindeschlüssel und Regionalschlüssel

Es fehlen nur nur noch einige Grenzen bei den admin_level=7 Gemeindeverbänden.

Wer da mithelfen will, hier als Hilfe eine Übersicht der noch fehlenden Grenzen:

http://ags.misterboo.de/test/?zoom=6&la … FFTFFFFTFT

Funktioniert die Fehleranzeige in der Standard-Anzeige nicht mehr?
Schon seit Tagen steht hier trotz aktualisierter Daten 0 / 2 ( was allein aufgrund der Kreativität von Mappern schon unwahrscheinlich
ist), aber auch beim Draufklicken kommen bei mir (Firefox 21, Window 7 64b) keine Einzelheiten mehr.

fx99 wrote:

Funktioniert die Fehleranzeige in der Standard-Anzeige nicht mehr?
Schon seit Tagen steht hier trotz aktualisierter Daten 0 / 2 ( was allein aufgrund der Kreativität von Mappern schon unwahrscheinlich
ist), aber auch beim Draufklicken kommen bei mir (Firefox 21, Window 7 64b) keine Einzelheiten mehr.

Sollte eigentlich korrekt sein, die letzten Tage gab es wohl keine Fehler bei den Grenzrelationen außer einer falschen RGS bei einem Gemeindeverband

Jetzt (27.5., 19:30) sind die schönen grünen und roten Punkte bei den Verwaltungsgemeinschaften verschwunden!
Schade, das machte das Aufspüren von fehlenden Einträgen sooo einfach.

fx99 wrote:

Jetzt (27.5., 19:30) sind die schönen grünen und roten Punkte bei den Verwaltungsgemeinschaften verschwunden!
Schade, das machte das Aufspüren von fehlenden Einträgen sooo einfach.

Sorry da war ein kleiner Datenbankfehler ... sollte jetzt wieder gehen

misterboo wrote:

Sorry da war ein kleiner Datenbankfehler ... sollte jetzt wieder gehen

Perfekt, tut weider. Das nenne ich Service, danke!

Kann da mal jemand drauf schauen:
http://www.openstreetmap.org/browse/relation/2967184
de:amtlicher_gemeindeschluessel = 083165005
name = Verwaltungsverband Nördlicher Kaiserstuhl

sieht mMn ok aus, ist bei misterboo aber immer noch rot : http://ags.misterboo.de/test/?zoom=11&l … FFTFFFFTFT

RGS 083165005
Name Nördlicher Kaiserstuhl
Bezeichnung Verwaltungsverband

fx99 wrote:

Kann da mal jemand drauf schauen:
http://www.openstreetmap.org/browse/relation/2967184
de:amtlicher_gemeindeschluessel = 083165005
name = Verwaltungsverband Nördlicher Kaiserstuhl

sieht mMn ok aus, ist bei misterboo aber immer noch rot : http://ags.misterboo.de/test/?zoom=11&l … FFTFFFFTFT

RGS 083165005
Name Nördlicher Kaiserstuhl
Bezeichnung Verwaltungsverband

wenn jemand aus dem de:amtlicher_gemeindeschluessel = 083165005 ein de:regionalschluessel = 083165005 macht

.. dann wird es grün 🙂

misterboo wrote:

wenn jemand aus dem de:amtlicher_gemeindeschluessel = 083165005 ein de:regionalschluessel = 083165005 macht

.. dann wird es grün 🙂

Danke, nach zu vielen Gemeindeverbänden werde ich einfach betriebsblind!

fx99 wrote:

misterboo wrote:

wenn jemand aus dem de:amtlicher_gemeindeschluessel = 083165005 ein de:regionalschluessel = 083165005 macht

.. dann wird es grün 🙂

Danke, nach zu vielen Gemeindeverbänden werde ich einfach betriebsblind!

Ihr habt ja auch schon eine Menge ergänzt ... vor einer Woche fehlten noch 550 ... jetzt sind es schon wesentlich weniger.

Die Verwaltungsgemeinschaften nähern sich der Vollendung:
jetzt taucht eine kleine Diskrepanz in den Daten auf:
Mit identischen Grenzen gibt es die Stadt Pausa-Mühltroff hier: http://ags.misterboo.de/#x=11.9543&y=50.5682&z=12 und
die Verwaltungsgemeinschaft Pausa/Vogtl. hier : http://ags.misterboo.de/test/?zoom=12&l … FFTFFFFTFT
Was ist richtig? siehe auch http://de.wikipedia.org/wiki/Pausa-M%C3%BChltroff

PS: Ähnlich sieht es bei Malschwitz aus.

Anscheinend wurde die Verwaltungsgemeinschaft Malschwitz zm 1.1.13 aufgelöst: http://de.wikipedia.org/wiki/Verwaltung … Malschwitz
dto. Verwaltungsgemeinschaft Pausa http://de.wikipedia.org/wiki/Verwaltung … haft_Pausa

Wikipedia hat natürlich recht ...

Die Daten für die Verbandsgemeinden kommen bei meiner APP aus dem Datensatz VG250, der ist vom 31.12.12

die beiden Gemeindeverbände wurden ja erst nach diesem Datum aufgelöst, sind also noch nicht im amtlichen Datensatz enthalten.

misterboo wrote:

Die Daten für die Verbandsgemeinden kommen bei meiner APP aus dem Datensatz VG250, der ist vom 31.12.12

Wieso nimmst Du nicht auch diese Daten aus dem Gemeindeverzeichnis? Neben den dreimonatigen Excel-Dateien gibt es auch ein ASCII-Format, in dem die Daten monatlich aktualisiert werden (siehe 'GV100AD zum 31.05.2013' auf https://www.destatis.de/DE/ZahlenFakten … rativ.html).

Eine Datensatzbeschreibung liegt als PDF in der ZIP-Datei. Das Parsen ist nicht wirklich schwer und im Zweifel könnte ich Dir mit meinem Python-Skript weiterhelfen.

Ich habe mal die angegebene Datei mit den OSM-Daten verglichen und es gibt ca. ein Dutzend Gemeinden, bei denen sich seit Silvester der Regionalschlüssel geändert hat.

Schö
Adjuva

adjuva wrote:

misterboo wrote:

Die Daten für die Verbandsgemeinden kommen bei meiner APP aus dem Datensatz VG250, der ist vom 31.12.12

Wieso nimmst Du nicht auch diese Daten aus dem Gemeindeverzeichnis? Neben den dreimonatigen Excel-Dateien gibt es auch ein ASCII-Format, in dem die Daten monatlich aktualisiert werden (siehe 'GV100AD zum 31.05.2013' auf https://www.destatis.de/DE/ZahlenFakten … rativ.html).

Eine Datensatzbeschreibung liegt als PDF in der ZIP-Datei. Das Parsen ist nicht wirklich schwer und im Zweifel könnte ich Dir mit meinem Python-Skript weiterhelfen.

Ich habe mal die angegebene Datei mit den OSM-Daten verglichen und es gibt ca. ein Dutzend Gemeinden, bei denen sich seit Silvester der Regionalschlüssel geändert hat.

Schö
Adjuva

Die Gemeinden sind ja aus diesem Verzeichnis ... nur die Verbandsgemeinden hatte ich aus dem VG250 Datensatz. Grund war, dass ich so einfach an die Geodaten kam zum hinzoomen beim Anklicken, in der GV100AD sind nur die Geodaten für die Gemeinden.

Die "null" -Fehler scheinen immer häufiger zu werden:
null (62763) - edit
null (62775) - edit
null (69951) - edit
null (451362) - edit
null (454192) - edit

Anscheinend werden de:amtlicher_gemeindeschluessel und de:regionalschluessel für modifizierte Gebiet (Landmasse) verwendet.

Was ist davon zu halten?

fx99 wrote:

Anscheinend werden de:amtlicher_gemeindeschluessel und de:regionalschluessel für modifizierte Gebiet (Landmasse) verwendet.

Was ist davon zu halten?

Da wurden in Relationen für eine Landmasse (bis zur Wasserlinie) type=land_area zusätzlich zu land_area=administrative verwendet. Diesen Relationstyp habe ich nirgends gefunden, es müsste mMn type=boundary oder höchstens noch type=multipolygon heißen.

[edit]boundary=administrative, admin_level und AGS gehören ebenfalls nicht in die Landmasse-Relation hinein: Es kann nur eine offizielle Grenze geben, sonst bekomme ich einen doppelten AGS-Eintrag.