Habe für alle “alten Bundesländer” ohne Bayern (weil Extrawurst bei Gemeindedaten) die Flächenabweichungen aktualisiert:
https://wiki.openstreetmap.org/wiki/DE:Fl%C3%A4chenabweichungen_zu_DESTATIS
Auf github wird momentan über die Darstellung der Grenzen auf der osm.org Standardkarte diskutiert. Möglicherweise interessiert das ja den ein oder anderen der Grenzspezialisten hier 
Topic 1: Admin-Grenzen sollen nicht mehr angezeigt werden: https://github.com/gravitystorm/openstreetmap-carto/issues/619
Topic 2: Admin-Grenzen sollen prominenter und früher angezeigt werden: https://github.com/gravitystorm/openstreetmap-carto/issues/622
Topic 3: Maritime Grenzen sollen nicht mehr oder weniger prominent angezeigt werden: https://github.com/gravitystorm/openstreetmap-carto/issues/621
sinnvoller wäre es das man die grenzen weg und zu klicken kann
Eine layer-orientierte Karte/Anzeige hätte so manche Vorteile. Mehr und mehr entsteht sonst ein Wuselbild.
In Schleswig-Holstein zerstört ein Mapper Grenzrelationen, indem er einfach eine Linie um die Gemeinden zieht und die relation dann löscht oder deren Elemente entfernt.
Ich habe ihn/sie angeschrieben und werde mal schauen, was man retten kann.
Führt das dazu, wenn man sagt MPs seien böse und stets zu vermeiden?
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.
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 
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).
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!
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
Wenn man für zwei angrenzende Gebiete unterschiedliche Linienzüge als Grundlage hat, befördert man, dass z.B. unbemerkt Lücken beim Bearbeiten der Wegpunkte entstehen.
Ich interessiere mich auch sehrwohl für die einzelnen Grenzen. Zum einen, weil ich aus verschiedenen Gründen (insbesondere Qualitätssicherung) die Polygone selbst erzeuge und analysiere, zum anderen weil man andernfalls Grenzen nicht einheitlich approximieren kann. Das heißt benachbarte approximierte Grenzen könnten sich z.B. überschneiden oder Lücken entstehen.
Wie fast immer hat beides Vor- und Nachteile:
Bei Grenzen als Relation muss man sich die Umrandung der Fläche aus den Mitgliedern der Relation zusammenklauben. Es ist auch (leider) sehr viel einfacher, eine Relation nicht zusammenhängend zu machen.
Bei Grenzen als area bekommt man sehr viele Redundanzen (übereinanderliegende Linien), die ja auch nicht unproblematisch sind. Sehr praktikabel wäre es mMn auch nicht: Eine neue Grenze (z.B. eine Verwaltungsgemeinschaft) zöge eine stundenlange “Folgen”-Sitzung nach sich, wenn die Gemeindegrenzen sehr genau erfasst sind. Bei Relationen muss man nur wenige Grenzsegmente einfügen. Nicht überall kann man halt fertige Shapes importieren.
Hi,
sehe gerade im OSMI dass im Bereich Marl/Recklinghausen alles “rot” ist.
Wird da gerade was gebastelt an den admin Relationen?
Grüße
Chris
Jo, bin ich dran. aber das sollte eigentlich ok sein und der OSMI hinkt eventuell hinterher. Meine Boundaries-Karte ist damit aber hochzufrieden. ich prüfe das nochmal.
Gruss
walter
jo, das sind diese blöden Wahlkreise, da hat es leichte Kolateralschäden gegeben. Ich hab den Mapper mal angeschrieben, der die erfasst hat und er meint, daß er die unbedingt braucht.
ich fix die dennoch mal.
Data von 19.6.2014. Also ist der recht aktuell.
war halb so schlimm, sollte jetzt ok sein. Kritische Grenzen (admin/plz) waren eh nicht betroffen. Nur diese blöden Wahlkreise.
Gruss
walter
Würde man die als “abstrakte” Relationen ohne Wege, sondern nur mit Gemeinden/Ortsteilen als “part”-Member abbilden würden sie keinen stören…
Aber dann können die meisten Leute ja wieder nicht damit arbeiten…
Die Stadtbezirke Leipzigs sollten jetzt erstmals drin und komplett sein. Man konnte das weitgehend aus den TMC-Areas dort übernehmen.
Ich habe mich in letzter Zeit mit der Qualität von Grenzgeometrien beschäftigen müssen. Hierbei sieht man immer wieder, wie unterschiedlich die Qualität der Wegsegmente ist. Das reicht von sehr groben Vermutungen (teils nur eine Verbindungslinie quer durch die Landschaft) bis zu wirklich exakten Imports mit ganz offiziellen Koordinaten. Wie gut die Grenze ist, muss man aber meist raten. Selbst Quellenangaben wie “LGL” in BaWü sagen ja nicht, ob es abgemalt wurde oder exakt importiert. Wenn es abgemalt wurde, kann es gut abgemalt oder auch schlampig/grob abgemalt sein.
Mein Gedanke hierzu: Man sollte einen Qualitäts-Tag für Grenzsegemente haben, der Werte mit recht eindeutiger Semantik hat. Die Qualitätsstufen stelle ich mir z.B. so vor:
official (aus Import), very_good/excellent (sehr genauer Trace der offiziellen Grenze; alle Punkte da, aber evtl. nicht 100% genau), good (ordentlicher Trace ö.ä. der Grenze, evtl. auch nur einer Generalisierung davon; evtl. fehlen auch ein paar Punkte oder kleiner Areale liegen im falschen Gebiet), approximate (gute Schätzung anhand offizieller Informationen, Details liegen teils daneben), rough (grobe Schätzung, Ortschaften sind aber richtig zugeordnet), very_rough (sehr grobe Schätzung; evtl. sind größere Flächen, einige Häuser bis ganze Ortschaften nicht im richtigen Gebiet).
Es könnte zur besseren Differenzierung bzgl. “source” auch besser sein, die Art der Datenübernahme zu taggen, z.B. “source:transfer=*” mit Werten wie “import”, “trace”, “memory”.
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.