Pflege und Korrektur der deutschen Admin-Grenzen

[wambacher (Walter Nordmann)]

Moin Moin,

ausnahmsweise mal hier, da nur DEU ausgewertet wurde:

 Relation | Country |           New Boundary           
----------+---------+----------------------------------
   907047 | DEU     | Wachenheim an der Weinstraße (7)
(1 row)

 Relation | Country | Missing Boundary 
----------+---------+------------------
   312076 | DEU     | Drewer-Nord (10)
   312074 | DEU     | Drewer-Süd (10)
(2 rows)

Hab mal meinen “Heimvorteil” ausgenutzt und die Sache gleich korrigiert. Da hat ein Newbie im ersten und bisher einzigen Edit mit Potlatch2 wohl ein wenig zu viel rumgefummelt.

Gruss
walter

[wambacher (Walter Nordmann)]

Hi,

ich bastel arbeite noch an einer kleinen Erweiterung: Anzeige erheblicher Grössenänderungen bei den Flächen.

Grund für diese Auswertung: Wenn komplexe Multipolygone mit inner/outer defekt werden, kann das MP manchmal “überleben”. D.h. es ist immer noch vorhanden, aber erheblich kleiner. Da reicht der einfache Vergleich “ist neu?”/“fehlt?” nicht mehr aus.

Hab das bei mehreren Ländern gehabt, wo dann plötzlich ein AL4 nur noch aus einer Insel bestand (outer) aber der Rest weg war.

Hier mal der erste Versuch. Vergleich der Flächen in DEU von gestern und heute früh:

 Relation | Country |        city        | old Km² | new Km² | % diff 
----------+---------+--------------------+---------+---------+--------
  1451524 | DEU     | Lüttow-Valluhn (8) | 19.1954 | 24.5798 |  28.05
  2900136 | DEU     | Zella/Rhön (8)     | 1.40724 | 1.71094 |  21.58
  1451580 | DEU     | Kogel (8)          | 36.2827 |  29.956 | -17.44
  2900132 | DEU     | Empfertshausen (8) | 4.33029 | 5.12434 |  18.34
  2900084 | DEU     | Andenhausen (9)    |  2.1507 | 1.39119 | -35.31
(5 rows)

Vergleich der Flächen DEU von gestern und heute früh. Angezeigt werden Änderungen ab 10%.

Hab es mal analysiert. Zwischen Lüttow-Valluhn und Kogel wurde die Grenze verschoben. Dabei ist Lüttow-Valluhn größer und Kogel kleiner geworden. Analog für die andere 3 Treffer. Die liegen alle zusammen.

Also alles ok. Es kann aber morgen schon anders aussehen.

Gruss
walter

ps: Erst bei >= 4% kommt eine Grenze mehr. Ich glaube 10% ist vorerst ok.

 Relation | Country |         city         | old Km² | new Km² | % diff 
----------+---------+----------------------+---------+---------+--------
  1451524 | DEU     | Lüttow-Valluhn (8)   | 19.1954 | 24.5798 |  28.05
  2900136 | DEU     | Zella/Rhön (8)       | 1.40724 | 1.71094 |  21.58
  1451580 | DEU     | Kogel (8)            | 36.2827 |  29.956 | -17.44
  2900130 | DEU     | Brunnhartshausen (8) | 11.1257 | 10.6188 |  -4.56
  2900132 | DEU     | Empfertshausen (8)   | 4.33029 | 5.12434 |  18.34
  2900084 | DEU     | Andenhausen (9)      |  2.1507 | 1.39119 | -35.31
(6 rows)

Nachtrag: Etwas ist dennoch merkwürdig - die absoluten Zahlen stimmen nicht ganz.

 Relation | Country |        city        | old Km² | new Km² |  Diff  | % diff 
----------+---------+--------------------+---------+---------+--------+--------
  1451524 | DEU     | Lüttow-Valluhn (8) | 19.1954 | 24.5798 |   5.38 |  28.05
  2900136 | DEU     | Zella/Rhön (8)     | 1.40724 | 1.71094 |    .30 |  21.58
  1451580 | DEU     | Kogel (8)          | 36.2827 |  29.956 |  -6.33 | -17.44
  2900132 | DEU     | Empfertshausen (8) | 4.33029 | 5.12434 |    .79 |  18.34
  2900084 | DEU     | Andenhausen (9)    |  2.1507 | 1.39119 |   -.76 | -35.31
(5 rows)

Nun denn, war halt der erste Versuch.
Grübel, grübel

[Gehrke]

@wambacher

ich bastel arbeite noch an einer kleinen Erweiterung: Anzeige erheblicher Grössenänderungen bei den Flächen.

Grund für diese Auswertung: Wenn komplexe Multipolygone mit inner/outer defekt werden, kann das MP manchmal “überleben”. D.h. es ist immer noch vorhanden, aber erheblich kleiner. Da reicht der einfache Vergleich “ist neu?”/“fehlt?” nicht mehr aus.

Hab das bei mehreren Ländern gehabt, wo dann plötzlich ein AL4 nur noch aus einer Insel bestand (outer) aber der Rest weg war.

Ich kenne das Problem. Super Sache für Deine Grenzauswertung.

Für die angeführten Flächenänderungen zeichne ich übrigens verantwortlich. Die Fälle waren mir durch meine DESTATIS-Auswertung bzw. eine Grenzüberlappung bei Empfertshausen aufgefallen.

[Gehrke]

@wambacher

Nachtrag: Etwas ist dennoch merkwürdig - die absoluten Zahlen stimmen nicht ganz.

 Relation | Country |        city        | old Km² | new Km² |  Diff  | % diff 
----------+---------+--------------------+---------+---------+--------+--------
  1451524 | DEU     | Lüttow-Valluhn (8) | 19.1954 | 24.5798 |   5.38 |  28.05
  2900136 | DEU     | Zella/Rhön (8)     | 1.40724 | 1.71094 |    .30 |  21.58
  1451580 | DEU     | Kogel (8)          | 36.2827 |  29.956 |  -6.33 | -17.44
  2900132 | DEU     | Empfertshausen (8) | 4.33029 | 5.12434 |    .79 |  18.34
  2900084 | DEU     | Andenhausen (9)    |  2.1507 | 1.39119 |   -.76 | -35.31
(5 rows)

Ich kann das Problem auf den ersten Blick nicht entdecken/verstehen…

[wambacher (Walter Nordmann)]

@Gehrke

@wambacher

Nachtrag: Etwas ist dennoch merkwürdig - die absoluten Zahlen stimmen nicht ganz.

 Relation | Country |        city        | old Km² | new Km² |  Diff  | % diff 
----------+---------+--------------------+---------+---------+--------+--------
  1451524 | DEU     | Lüttow-Valluhn (8) | 19.1954 | 24.5798 |   5.38 |  28.05
  2900136 | DEU     | Zella/Rhön (8)     | 1.40724 | 1.71094 |    .30 |  21.58
  1451580 | DEU     | Kogel (8)          | 36.2827 |  29.956 |  -6.33 | -17.44
  2900132 | DEU     | Empfertshausen (8) | 4.33029 | 5.12434 |    .79 |  18.34
  2900084 | DEU     | Andenhausen (9)    |  2.1507 | 1.39119 |   -.76 | -35.31
(5 rows)

Ich kann das Problem auf den ersten Blick nicht entdecken/verstehen…

Ganz einfach: wenn Lüttow-Valluhn um 5.38 Km² größer geworden ist, sollte Kogel um 5.38 Km² kleiner werden. Oder hast du dort noch andere kleinere Flächen geändert? Das könnte sowas erklären.

[Gehrke]

@wambacher

wenn Lüttow-Valluhn um 5.38 Km² größer geworden ist, sollte Kogel um 5.38 Km² kleiner werden. Oder hast du dort noch andere kleinere Flächen geändert? Das könnte sowas erklären.

Ach das meinst Du. Ja, habe dort noch andere Grenzen geringfügig (wohl unter 4%) verändert.

[wambacher (Walter Nordmann)]

Hi, ich musste gerade eine Ecke fixen, wo jemand richtig zugeschlagen hatte und DEU, CHE, Rheinland-Pfalz und alles was in der Gegend war, zerschossen hatte

Ich hoffe, ich habe alle erwischt: https://www.openstreetmap.org/changeset/24564518

So bin ich drüber gestolpert - und hab natürlich erst einmal an einen Fehler in meiner neuen Auswertung gedacht:

 Relation | Country |               city                | old Km²  |  new Km²   |   Diff    |  % diff  
----------+---------+-----------------------------------+----------+------------+-----------+----------
  1957690 | RUS     | ЗАТО Первомайский (6)             |  5.37664 |    5.98113 |  0.604492 |    11.24
  2900136 | DEU     | Zella/Rhön (8)                    |  1.40724 |    1.71094 |  0.303698 |    21.58
    62611 | DEU     | Baden-Württemberg (4)             |  36015.1 |    8.23238 |  -36006.9 |   -99.98
  1115720 | IRL     | Dún Laoghaire-Rathdown (7)        |  127.136 |   0.107209 |  -127.029 |   -99.92
  1451524 | DEU     | Lüttow-Valluhn (8)                |  19.1954 |    24.5798 |   5.38438 |    28.05
  2106112 | DEU     | Regierungsbezirk Freiburg (5)     |  9356.55 |    14.1478 |   -9342.4 |   -99.85
    51477 | DEU     | Germany (2)                       |   381402 |    122.977 |   -381279 |   -99.97
  2903223 | UKR     | Tsukuryne (8)                     |   2.1889 |    3.22287 |   1.03396 |    47.24
  3639334 | USA     | Grand Chute (7)                   |  4.05052 |    5.35859 |   1.30808 |    32.29
  3488555 | USA     | Ackerly (8)                       | 0.805591 |   0.890997 |  0.085406 |    10.60
   251955 | USA     | Little Chute (8)                  | 0.183708 | 0.00399644 | -0.179712 |   -97.82
  2900084 | DEU     | Andenhausen (9)                   |   2.1507 |    1.39119 | -0.759509 |   -35.31
  2900132 | DEU     | Empfertshausen (8)                |  4.33029 |    5.12434 |  0.794051 |    18.34
  1059324 | RUS     | Абазинский район (6)              |  233.849 |    293.775 |   59.9258 |    25.63
  1257060 | RUS     | Ложкарское сельское поселение (8) |   194.45 |    237.002 |   42.5527 |    21.88
  1451580 | DEU     | Kogel (8)                         |  36.2827 |     29.956 |  -6.32673 |   -17.44
    51701 | CHE     | Switzerland (2)                   |  41264.2 |    10.2937 |    -41254 |   -99.98
  1686359 | CHE     | Argovia (4)                       |  1403.39 |  0.0151813 |  -1403.37 |  -100.00
  2842731 | UKR     | Leninskyi Raion (7)               |  26.3354 |    83.7908 |   57.4554 |   218.17
  2842706 | UKR     | Budyonny Raion (7)                |  27.2078 |    77.6499 |    50.442 |   185.40
  3507205 | UKR     | Hruzko-Lomivka (9)                |  4.18186 |    1.72413 |  -2.45772 |   -58.77
(21 rows)

Die Abweichung von -99.92% in Irland war übrigens auch ein Fehler, den ich bereits korrigiert habe.

Gruss
walter

[Gehrke]

@wambacher

Hi, ich musste gerade eine Ecke fixen, wo jemand richtig zugeschlagen hatte und DEU, CHE, Rheinland-Pfalz und alles was in der Gegend war, zerschossen hatte

Ich hoffe, ich habe alle erwischt

In meiner letzten DE-Prüfung sind aktuell nur noch Probleme in BaWü (Grenzgem. Bad Säckingen) aufgefallen, die aber bereits alle behoben waren. Habe nur noch Member-Sequenzen verbessert.

[Gehrke]

Diese Verw.-Relationen sind auch nicht ok: wahrscheinlich Geometrie-Fehler (wie Selbstüberlappung): 1184400, , 62387, 62372; muss ich noch schauen.

Warum machen die osm2pgsql eigentlich nichts aus?

EDIT: Kann das Problem in JOSM nicht finden. Seit meiner Auswertung wahrscheinlich schon behoben.

[wambacher (Walter Nordmann)]

@Gehrke

Diese Verw.-Relationen sind auch nicht ok: wahrscheinlich Geometrie-Fehler (wie Selbstüberlappung): 1184400, , 62387, 62372; muss ich noch schauen.

Warum machen die osm2pgsql eigentlich nichts aus?

manche Fehler bügelt er stillschweigend aus und manche Relationen ignoriert er einfach - auch ohne darüber was zu sagen
Letzteres nervt mich fürchterlich.

Gruss
walter

[Prince_Kassad]

Ich wollte vorhin versuchen, die fehlende AL9 für Bruchköbel hinzuzufügen. Irgendwie scheint da aber etwas nicht zu stimmen, denn es fehlen aus irgendwelchem Grund irgendwelche Grenzelemente (die auch noch sehr komisch aufgeteilt sind) und die benachbarte AL9 von Oberissigheim wird mir in JOSM auch als kaputt angezeigt. In der Boundaries-Map ist aber alles in Butter.

Kann mir jemand erklären, woran das liegt?

[wambacher (Walter Nordmann)]

@Prince Kassad

Kann mir jemand erklären, woran das liegt?

ich schau mir die Sache mal an.

done: Ich kann absolut nichts ungewöhnliches oder gar falsches feststellen. Da ist nichts unvollständig oder sonstwie komisch - ansonsten könnte meine Karte die Grenzen ja auch nicht sauber anzeigen.

Ich tippe mal auf Fingertrouble deinerseits.

Ps: wenn der ganze südliche Teil Bruchköber (9) werden soll, hab ich das in 30 Sekunden erledigt - nur fehlt mir diese Info.

https://osm.wno-edv-service.de/boundaries/idx16o.jsp?zoom=13&lat=50.18445&lon=8.95806&layers=0BTF&selected=3292811_535894_3292810_3293000_3293001

hab mal geraten - das ganze Stück müsste Bruchköbel(9) sein und ich hab es so eingetragen.

Gruss
walter

[Prince_Kassad]

@wambacher

hab mal geraten - das ganze Stück müsste Bruchköbel(9) sein und ich hab es so eingetragen.

Das war auch nicht sehr schwer zu erraten, wenn alle Stadtteile außer einem fehlen, kann der sich ja nur aus dem weißen Rest zusammensetzen.

naja - aber in JOSM sieht das Spektakel so aus:

Diese Lücke in der Grenze hat mich verwirrt, aber irgendwie scheint die Relation trotz Lücke komplett zu sein. Merkwürdig…

[wambacher (Walter Nordmann)]

@Prince Kassad

Diese Lücke in der Grenze hat mich verwirrt, aber irgendwie scheint die Relation trotz Lücke komplett zu sein. Merkwürdig…

Nix merkwürdig: Da hatten und haben die Grenze und der Track eigene “Ways”, die übereinander liegen. Sieht nur ein wenig seltsam in der normalen Josm-Ansicht aus.

Mach folgendes: geh rechts im Rel-Editor auf die Relation und mach “Elemente auswählen” dann hast du nur die Grenz-Ways - und die sind ok.

Ich habe oft sogar ein Filter aktiv, daß mir nur die administrativen und postalischen Grenzen zeigt:

Das macht die Sache mit den Grenzen wesentlich übersichtlicher. Wichtig sind alle drei Häkchen und das H.

Gruss
walter

ps: Ja, ich gebe zu, ich habe auch erst ein wenig gestutzt

[Gehrke]

Das Grenzpolygon für OT Honrath (Stadtteil von Lohmar, NRW) ist nicht geschlossen. Ist wohl noch in Arbeit…

EDIT: hab’s eben behoben

[Gehrke]

Was ich an Osm2pgsql u.a. nicht mag: Geometriefehler (gestern und heute in Rhede (Ems)) werden einfach übergangen bzw. “repariert”, ohne dass man es merken würde. Den Fall in Rhede habe ich eben repariert. War ziemlich schwer zu finden - fast hinterhältig.

[Gehrke]

Üble Gebietsabweichung in Brandenburg: OT Marzahne von Stadt Havelsee (ca. 14 qkm) lag in der falschen Gemeinde (Jahre unentdeckt?):

"120695902018";"Beetzsee";21.12;36.23;15.11;71.54;967757
"120695902270";"Havelsee";81.27;67.03;14.24;17.52;967754

[Gehrke]

Kann sich ein Experte für bay. Grenzen bitte mal die Relation des gemfr. Gebiets Geiersberg anschauen?
Die Geometrie war kaputt (Selbstüberschneidung; merkt osm2pgsql nicht) und es fehlte eine Enklave. Das habe ich beides repariert. Aber bedenklich finde ich, dass die äußere Grenze komplett durch einen Fußweg beschrieben ist. Glaube nicht, dass das stimmt. Habe da aber keine genaueren Daten. Ich glaube, mindestens in der Südwest-Ecke und im Norden stimmt etwas nicht.

[Gehrke]

Ein weiteres Beispiel für Geometriefehler, die osm2pgsql nicht findet (behoben):

http://www.openstreetmap.org/changeset/25115808

Punkt zu viel auf den drei Grenzsegmenten.

[berndw]

vergesst es
Bernd