Pflege und Korrektur der deutschen Admin-Grenzen

Gehrke · 2014-06-04 11:56:40

Gehrke wrote:

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

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

Gehrke · 2014-06-04 12:12:06

Habs doch selbst gemacht...

Chenshi · 2014-06-04 13:58:20

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

Last edited by Chenshi (2014-06-04 13:58:37)

Gehrke · 2014-06-04 16:04:53

Chenshi wrote:

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

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

wambacher · 2014-06-04 18:13:43

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

wird sofort gefixt.

Gruss
walter

Edit: User gehrke war schneller

Last edited by wambacher (2014-06-04 18:17:19)

Gehrke · 2014-06-05 09:16:33

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

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

4rch · 2014-06-11 12:48:41

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

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

Chenshi · 2014-06-11 13:24:00

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

Gehrke · 2014-06-11 13:29:10

Chenshi wrote:

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

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

Gehrke · 2014-06-20 09:25:21

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

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

Gehrke · 2014-06-20 10:08:36

Gehrke wrote:

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

So. Habe das Gröbste wohl gefixt.

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

wambacher · 2014-06-20 10:09:19

Gehrke wrote:

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

Jo, glaube ich auch.

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

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

Gruss
walter

ps: Nein, das ist keine Socke von mir

Gehrke · 2014-06-20 10:15:35

wambacher wrote:

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

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

Last edited by Gehrke (2014-06-20 10:27:13)

viw · 2014-06-20 10:21:09

wambacher wrote:

Gehrke wrote:
Führt das dazu, wenn man sagt MPs seien böse und stets zu vermeiden?
Jo, glaube ich auch.
Wenn man es aber ganz genau betrachtet (und es alle Mapper auf der Welt so machen würden!) könnte man Grenzen auch so erfassen.
Als einfache Fläche, falls kein "Loch" und nur dann als MP, wenn "gelöchert". Das hätte uns viel Arbeit und Ärger erspart.
Ich erhoffe so eine Definition in dem 0.7-er Schema (Area), aber das kann noch lange dauern.
Gruss
walter
ps: Nein, das ist keine Socke von mir

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

wambacher · 2014-06-20 10:26:41

Gehrke wrote:

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

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

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

Gruss
walter

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

Gehrke · 2014-06-20 10:33:03

wambacher wrote:

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

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

Last edited by Gehrke (2014-06-20 10:33:35)

seichter · 2014-06-20 10:54:02

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

chris66 · 2014-06-20 17:08:40

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

wambacher · 2014-06-20 17:15:40

chris66 wrote:

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

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

Gruss
walter

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

ich fix die dennoch mal.

Last edited by wambacher (2014-06-20 17:21:08)

chris66 · 2014-06-20 17:18:36

Data von 19.6.2014. Also ist der recht aktuell.

wambacher · 2014-06-20 17:41:17

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

Gruss
walter

Gehrke · 2014-06-20 17:44:19

wambacher wrote:

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

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

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

Last edited by Gehrke (2014-06-20 17:45:23)

Gehrke · 2014-06-21 13:12:24

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

Gehrke · 2014-06-25 18:59:04

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

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

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

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

wambacher · 2014-06-25 19:28:31

Gehrke wrote:

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

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

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

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

Gruss
walter

ps: Freiwillige vor - 'mer beissen nicht.

Announcement

#276 2014-06-04 11:56:40

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#277 2014-06-04 12:12:06

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#278 2014-06-04 13:58:20

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#279 2014-06-04 16:04:53

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#280 2014-06-04 18:13:43

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#281 2014-06-05 09:16:33

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#282 2014-06-11 12:48:41

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#283 2014-06-11 13:24:00

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#284 2014-06-11 13:29:10

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#285 2014-06-20 09:25:21

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#286 2014-06-20 10:08:36

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#287 2014-06-20 10:09:19

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#288 2014-06-20 10:15:35

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#289 2014-06-20 10:21:09

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#290 2014-06-20 10:26:41

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#291 2014-06-20 10:33:03

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#292 2014-06-20 10:54:02

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#293 2014-06-20 17:08:40

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#294 2014-06-20 17:15:40

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#295 2014-06-20 17:18:36

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#296 2014-06-20 17:41:17

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#297 2014-06-20 17:44:19

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#298 2014-06-21 13:12:24

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#299 2014-06-25 18:59:04

Re: Pflege und Korrektur der deutschen Admin-Grenzen

#300 2014-06-25 19:28:31

Re: Pflege und Korrektur der deutschen Admin-Grenzen

Board footer