Es gibt die Mechanical Edit Policy, die solche mechanischen Edits/Importe qualitätsgesichert erlauben soll. Siehe http://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy .
Dann gibts noch den Draft Code of Conduct, in dem steht das man bei größeren Sachen die Community frühzeitig informieren soll http://wiki.openstreetmap.org/wiki/Community_Code_of_Conduct_%28Draft%29#Be_Collaborative .
Wer suchet der findet: Habe ich mich doch richtig erinnert:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#References_2
Dort findet sich:
11 admin_level values for specific countries
Für Deutschland findet sich dort für admin_level = 11
Neighbourhoods statistical or historical / Stadtviertel etc.
Also gibt es den admin_level = 11 und dieser wird für statistische Auswertungen benutzt. Hab ich Recht? - oder habe ich das falsch gelesen/verstanden?
Ich bitte um Aufklärung, wie dieses Wiki zu verstehen ist oder noch anders verstanden werden kann.
@gromo Mechanical Edit Policy trifft nicht zu, weil ich diese Grenzen alle händisch eingezeichnet habe - nichts hier mit Massenimport. Ich habe mehrere Tage daran gearbeitet. Und Draft Code of Conduct betrifft ausschließlich das Kommunikationsverhalten innerhalb er Community und ist auch noch im Entwurfsstadium.
Hallo Walter,
ich freue mich ja schon darüber, dass Du eine Grußformel verwendest.
Ich habe mir das so gedacht:
Du und User Gehrke seid ja die Spezialisten für Multipolygone und boundaries. Nach dem vorstehenden Zitat aus Wiki ist admin_level = 11 ja doch richtig - ODER?!? 
. Aber vielleicht habt Ihr Ideen, ob und wie das zukünftig neu benannt werden kann/soll, oder sollte vielleicht ein neues boundary einführen, wie z.B. boundary =civil; =statistic; =jurisdiction.
In einem zweiten Schritt überprüfe ich anhand gedruckter Werke des Amtes für Statistik Berlin-Brandenburg, wie die Grenzziehung genau ist und vergleiche das gleichzeitig auch mit den anderen admin_level. Dann werde ich immer jedes MP einzeln bearbeiten und hochladen. Oder wird gewünscht, dass ich es jemanden zur Einsicht und Kontrolle erst zusenden soll? Oder gibt es einen Bereich ähnlich wie Teamviewer, wo zumindest zwei in einem geschützten Bereich die Daten bearbeiten/sich abstimmen, bevor diese veröffentlicht werden?
Für heute allen eine gute Nacht,
Stefan
hast du für den WMS auch die richtige Projektion benutzt? Ich kann mich erinnern das dort irgendwie was ganz krummes war. Da kam es zu verschiebungen wenn man nicht genau diese Projektion benutzt hatte.
Friede, Wonne, Eierkuchen hin oder her, jetzt, nachdem du Tatsachen geschaffen hast, willst du die organisatorische Arbeit, die du ja anscheinend zu scheuen scheinst wie der eine Typ das Weihwasser, auf die Community und davon sogar 2 bestimmten Personen abwälzen.
ok, gerne. Am einfachsten geht das für alle, wenn wir einfach den CS reverten und du schön gemütlich nach dem erarbeitete Taggingschema die Grenzen nach und nach einträgst.
Ich “beantrage” hiermit einen Revert und würde gerne die Meinung den Community dazu erfahren.
walter
Ich wäre ja ohnehin anders an die Sache herangegangen… ich hätte mir erst mal die Daten angeschaut… Eben solche Vergleiche zu Admin-Grenzen gezogen…
Das geht auch schon aus der Beschreibung hervor:
.
Dadurch sollte sich +/- Dekungsgleichheit mit den Berliner Admin-Grenzen ergeben. Meiner Meinung nach bauen die nahezu Daten vollständig auf den Admin-Daten Berlins auf…ließen sich also als Ergänzungstag an den bestehenden Admin-Grenzen anwenden. (wenn letztere vollständig sind… ich hab da keinen Überblick).
Ungeachtet dessen erschließt sich mir derzeit nicht die Relevanz der Information… Daten in die Datenbank reinpressen, bloß weil man sie reinpressen kann oder darf?
Nein…
Ich sehe das ganze so, daß wir einen Weg finden müssen zwischen dem, was wir erfassen können und dem was wir erfassen sollten. Lieber etwas weniger, dafür aber in besserer Qualität…
Diese LOR’s , so kann ich mir es vorstellen, unterliegen auch einem Wandel… der Ewige Moloch (=Berlin 
) verändert sich [leider nur Soldner]… Diese Daten sind für mich Vergleichbar mit Daten zur Arbeitslosigkeit in verschiedenen Jahren oder Altersstufen in Berlin…
Wenn man anhand der Grenzen die Statistischen Auswerteeinheiten Berlins als solches unterhalb realer Admingrenzen definieren könnte, dann wäre eine Nutzung für die Ermittlung dieser Grenzen überlegenswert und disskutabel.
Schlußendlich komme ich zur Erkentnis, das solche Daten als Overlay in einer Kartenanwendung geeignet sind, nicht aber als physische Daten in der OS-Datenbank.
Von Daher: ja, für den Revert.
Analytische Grüße,
Sven
Nein, besser und wichtiger als jedes MP einzeln ist, dass die Grenzen nach jedem Upload noch alle intakt sind - nicht nur eins der betroffenen MPs. Gerade sind zumindest mind 14. PLZ/Admin-Relationen in Berlin und Brandenburg defekt (fixe die gleich). Weiß aber nicht durch welche Aktion. Vorher überprüfen durch “Mentoren” halte ich für nicht praktikabel und zumutbar.
Guten Morgen,
na dann schmeißen wir die Daten eben wieder raus. Einverstanden. Aber wie kann ich jetzt daraus einen Overlayer machen, der für OSM nutzbar ist?
Falls jemand einen Revert macht (ich nicht), sollte er oder sie vielleicht vorher auch meine Reparatur-Changesets #27174732 und #27174487, falls das Konflikte vermeidet.
Dafür, dass beim Eintragen der Daten nicht alles optimal vorbereitet und durchdacht war, hat atpl_pilot nun genug Haue eingesteckt, incl Pranger in diesem Thread.
Ein Revert ist eine sehr harte Keule.
Nicht vergessen: Hier hat es weder eine illegale Datenquelle noch Vandalismus gegeben.
Was ich in den 6 Jahren bei OSM immer genossen habe, war erstens der nette Umgangston in den Diskussionen und zweitens das OSM-Selbstverständnis, das Relevanzdiskussionen in ganz engen Grenzen hielt. Die augenzwinkernde Akzeptanz von HKTS in unseren Daten ist für mich ein großer Motivator, um mitzumachen (und bei Wikipedia eben so gut wie nicht).
Leben und leben lassen.
Und nicht reverten.
Edit: 2 Typos
Moin, ich habe gerade die Int. Admin Grenzen ausgewertet. Dabei sind ca 29 Missings um Berlin herum gelistet worden. Immer dort, wo die “Lebensräume” reingeklopft wurden.
siehe: 
Dick: Gosen AL9, dünn oben: Lebensraum, dünn mitte: AL10 Mückelheim, Schmöckwitz
Wird wohl auf einen Revert hinauslaufen.
Gruss
walter
edit: Bild korrigiert
Da die Daten laut Vorpostern großteils redundant sind, eine falsche Projektion benutzt wurde und bestehende Objekte beschädigt wurden, bin ich auch dafür, diese wieder aus der DB zu entfernen.
ok, ich fange mal an.
zu spät: 18 Konflikte. Inzwischen habe mehrere Mapper dran rumgedreht (auch unser Super-Mapper) und da ist wohl nix mehr zu machen.
Ich schlage dem Kollegen vor, dass er sich vorrangig um die 29 defekten Grenzen um Berlin herum kümmert, eine Liste gibt es ja: http://osm.wno-edv-service.de:82/index.php?option=com_content&view=article&id=53
grimmige Grüße
walter
Das geht doch schief. Ich habe angefangen und bringe das Reparieren zu Ende. das heißt aber nur, beschädigte Grenzen fixen. Die “Lebensräume” taste ich nicht an.
Ich hoffe, dass wir hier zumindest für einen Lerneffekt gesorgt haben.
ich würde ihm die Möglichkeit geben, das zu korrigieren.
Beim nächsten Mal. Ich habe es jetzt (hoffentlich) korrigiert, ohne die “Lebensräume” weiter zu beachten.
Gut, dass diese Rechnung nicht ausgestellt wird. Schlecht für mich.
Also ich bin jetzt ein wenig überfordert. Was soll ich machen? Einfach alles was admin_level = 11 und mit Lebensweltlich orientierte Räumen getagt ist wieder löschen? Oder soll ich reparieren laut Liste http://osm.wno-edv-service.de:82/index.php?option=com_content&view=article&id=53.
Ich hätte nie gedacht, dass man hier verbal so “auf die … bekommt”
Und ich wollte auch nicht, dass mir irgend jemand Arbeit abnimmt - verstehe auch nicht, wie durch das Einfügen der Relation admin_level =11 zur bestehenden Grenze Berlin diese Fehler auftrten konnten. JOSM meldete keinen Fehler beim upload.
Heute schaffe ich es nicht mehr, aber gleich morgen werde ich mich ranmachen. Würde mich freuen, wenn ich mit einem der SuperUser Mapper diesbezüglich telefonieren könnte.
Ich will Dich ja nicht entmutigen. Der Umgangston wird halt rauer/genervter, wenn für einige unverschuldet unnötige Arbeit entsteht.
Im Umgang mit JOSM fehlt Dir offenbar eine wichtige Erkenntnis: Wenn Du nur einen Teil der Daten lädst (z.B. nur eine Linie und nur eine MP-Relation) wird auch nur diese (bzw. deren Änderungen) überprüft.
Daher ist es sehr wichtig, dass man beim Editieren von Grenzen (insb. Auftrennen von Sgementen) alle betroffenen Relationen geladen hat. Dazu sollte man das Segment (way) und dessen Endpunkte markieren und im Datei-Menü die Elternelemente (d.h. Relationen und Linien) laden (oder Tastenkombination Strg-Alt-D). Es empfiehlt sich im Zweifel auch, alle geladenen Relationen noch einmal im JOSM-Relationeneditor auf geschlossene Polygonringe zu überprüfen.
Die Relationen der angeführten URL musst Du nicht mehr prüfen. Die habe ich bereits alle korrigiert.
Was kannst Du also machen? Unabhängig davon, ob die LOR relevant sind und in OSM gehören oder nicht, sollte es keine parallelen Grenzführungen aus zwei Quellen geben. Wenn die Berliner Datenquelle besser ist, passe am besten die bestehende, von den AL-Relationen bereits verwendete Linie auf den genaueren Verlauf an und setze ggf. die LOR-Relation auch auf diese gemeinsamen Segmente.
EDIT: Typos
Nun denn, hoffen wir mal das Beste.
Was mich wundert, dass die “Berliner” - also die lokale Community - noch nichts dazu gesagt haben. Die können von Glück reden, dass AL11 in Mapnik nicht dargestellt wird. Das würde einen Aufstand geben, da bin ich mir sicher.
aber jetzt halte ich mich mal für 1-2 Tage zurück.
Gruss
walter
edit: zensiert
Danke für die Hinweise, kannte ich in der Tat noch nicht (laden der Elternrelationen). Ab morgen werde ich mich ran setzen. Stück für Stück und vielleicht hat jemand ein Auge darauf.
Liebe Grüße
Stefan
Hallo,
es zwar nicht optimal gelaufen, wenn aber noch ein bisschen Arbeit reingesteckt wird, könnte es was werden.
Normalerweise ist der Umgangston hier im Forum sehr freundlich, nur einige Kollegen stecken sehr viel Energie in korrekte Grenzen, so dass sie empfindlich reagieren, wenn etwas kaputt oder nicht korrekt gemacht wird. Das hab ich selbst auch schon gemerkt.
Zur Relevanz der Grenzen würde ich sagen, dass wir Grenzen von statistischen Stadteinteilungen nicht brauchen, aber Berlin durchaus ein admin_level=11 vertragen könnte.
In https://wiki.openstreetmap.org/wiki/DE:Grenze#Kommunale_Ebene_-Ortsteile-_admin_level.3D9-11 werden für Berlin auf AL11 195 statistische Gebiete angegeben. Ich kenne es aus NRW, da sind - in kleineren Städten - auf AL11 häufig sogenannte Statistische Bezirke. In Münster werden diese je nach Quelle auch Stadtteile genannt und stimmen noch relativ gut mit den bekannten Stadtteilen überein. Darunter gibt es in Münster noch drei weitere Ebenen der Statistischen Gebietsgliederung, bis hin zu Blöcken http://www.muenster.de/stadt/stadtplanung/pdf/a3_block.pdf.
Aus mehreren Gründen bin ich dagegen, diese weiteren Ebenen in OSM einzupflegen:
Viele Grüße
Daniel