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:
- es gibt fast nie eine legale Quelle
- die Einteilungen und Benennungen widersprechen den allgemein in der Stadt bekannten Einteilungen und Namen
- bis AL11 wird es auch von der Verwaltung (zumindest in Münster) genutzt, so dass diese Grenzen für uns z.B. bei Hausnummerlisten hilfreich sind
- alles was darunter kommt wird - nach meinem Eindruck - nur in Spezialfällen genutzt
- falls jemand diese Grenzen für eine Auswertung benötigt, wird es voraussichtlich nur eine lokale Auswertung sein, so dass diese Grenzen nicht in einer weltweiten Datenbank vorgehalten werden müssen
Viele Grüße
Daniel
so, ich fang dann mal an.
Es wurde in den letzten drei Tagen fast keine Korrekturen an den LOR gemacht, bis auf die dringenst notwendigen Korrekturen der Außengrenzen von Berlin und der umliegenden Städte (Danke Jan). Die Änderungen von CS 27193182 konnte ich nicht nachvollziehen, weil diese von einem anderen User gelöscht wurden.
Da ich die Rels nur nacheinander mit vorheriger Prüfung löschen werde, kann diese Aktion wohl einige Stunden dauern. Man hat ja sonst nichts besseres zu tun.
Gruss
walter
Puh,
geschafft.
Gruss
walter
Hallo,
ich bin nicht der Grenzspezialist (traue mir aber zu, Grenzen zu bearbeiten) und betrachte diesen Thread ein wenig von außen.
Beim Import von virtuellen Objekten, sollte man den Nutzen für die Allgemeinheit berücksichtigen. Gemeinde-, Kreis-, Regierungsbezirks-, …-Grenzen haben für das praktische Leben eine Bedeutung. Sie werden einerseits zur Lagebeschreibung verwendet. “Nordhausen im Landkreis Heilbronn” oder geben politische Zuständigkeiten an (man muss sein Auto auf dem Landratsamt in Heilbronn anmelden). Selbst wenn Grenzen keine politische Bedeutung haben, sollten sie in OSM rein, wenn sie zur Lagebeschreibung verwendet werden. Das wären z.B. die Grenzen von Ortsteilen, wo es keine Ortschaftsräte und Ortsvorsteher gibt. Dennoch sind diese Namen auch heute noch in Verwendung.
Wenn ich mir den LOR-Datensatz (PDF 27,5 MB) anschaue, dann besteht dieser aus vier Ebenen:
-
Bezirk
-
Prognoseraum
-
Bezirksregion
-
Planungsraum
Der Datensatz scheint für stadtplanerische Zwecke entworfen worden zu sein. Stadt- und Regionalplanung tut (und sollte) grenzüberschreitend denken. (Nicht, dass sich Mainzer für ein Mega-Outlet-Center entscheidet, das die Wiesbadener nicht wollen)
Beispiel 1
Friedrichshain-Kreuzberg – Kreuzberg Süd – Tempelhofer Vorstadt – Urbanstraße.
Ebene 1 sind immer die Bezirksgrenzen, welche schon in OSM vorhanden sind. Ebene 2 ist hier eine virtuelle Grenze, die vermutlich nicht von den Einwohnern zur Beschreibung verwendet werden. Oder sagt jemand “Ich wohne in Kreuzberg Süd”? Ebene 3 klingt für mich nach einer gebräuchlichen Bezeichnung. Ebene 4 ist ein Straßenname und wurde verwendet, weil dem Planer wohl nichts Besseres einfiel. Zusammengefasst kann man sagen, dass in diesem Fall nur die dritte Ebene ein für OSM sinnvolles Datum (Singular von Daten) enthält.
Beispiel 2
Charlottenburg-Wilmersdorf – Charlottenburg-Wilmersdorf 1 – Charlottenburg Nord – Paul-Hertz-Siedlung
Charlottenburg-Wilmersdorf – Charlottenburg-Wilmersdorf 2 – Heerstraße – Kranzallee
Charlottenburg-Wilmersdorf – Charlottenburg-Wilmersdorf 2 – Westend – Reichsstraße
Ebene 2 klingt im Bezirk Charlottenburg-Wilmersdorf nach einer sehr künstlichen, einfallslosen Namensgebung. Das sind IMHO Grenzen, die im CAD (früher auf dem Reißbrett) entstanden sind. Daher sollte Ebene 2 im Bezirk Charlottenburg-Wilmersdorf nicht in OSM eingepflegt werden. Ebene 3 ist teilweise OSM-würdig (Westend), teilweise aber nicht (Charlottenburg Nord). Oder ist Charlottenburg Nord ein allgemein gebräuchlicher Begriff? Ebene 4 ist, wie mal so mal so. Paul-Herz-Siedlung wäre etwas, was ich sehr gerne in OSM sehen würde. Es könnte nämlich Geocoding-Ergebnisse verbessern, sodass der User erkennt (“Ahh, Ergebnis 3 ist der Bäcker in der Paul-Hertz-Siedlung. Ja, genau den habe ich gesucht!”). “Kranzallee” ist jedoch auch ein Straßenname. Das kann man mit Buffern selber berechnen.
Ein blindes Importieren ist hier nicht richtig. Einzelne Inhalte kann man jedoch gerne übernehmen.
Manche Grenzen sind schon drin (z.B. Westend als Admin Level 10). Ob man jetzt AL10 oder 11 nimmt, hängt davon ab, ob es in dem Gebiet schon AL10-Relationen gibt oder nicht. Wenn es schon ein AL10 gibt, dann AL11 (d.h. hierarchisch untergeordnet), ansonsten AL10 (nächst höhere Ebene wäre dann der Bezirk).
Da Ortskenntnis gefragt ist, rate ich dazu, den Import von einem Einheimischen machen zu lassen. Noch besser wäre, wenn du, atpl_pilot den Plan einfach ausplottet, mit zum Stammtisch nimmst und dann gemeinsam mit den anderen entscheidet, was man für OSM-würdig hält. Berlin ist so groß, da habe ich meine Zweifel, ob einer aus Wansee entscheiden kann, wie/ob die einzelnen “Bezirksregionen” und “Planungsräume” in Hellersdorf gebräuchliche Namen oder aussprechbare alphanumerische IDs sind und wie die Hierarchie ist (vielleicht wird AL12 nötig).
Ich möchte “Charlottenburg-Wilmersdorf 2” nicht in OSM sehen.
Viele Grüße
Michael
Hallo Walter,
der User S-D hatte jedes edit von mit in den letzten 10 Tagen sofort wieder gelöscht bzw revertet. Michael (Nakaner) hatte mich gebeten, diese reverts nicht selbst sondern durch die DWG reverten zu lassen. Es lag also nicht primär an mir, dass ich das Problem nicht abarbeiten konnte.
Nun aber mal eine grundsätzliche Frage:
Wenn laut Wiki (https://wiki.openstreetmap.org/wiki/DE:Grenze#Kommunale_Ebene_-Ortsteile-_admin_level.3D9-11) für Berlin die Ebene AL11vorgesehen ist und die von mir verwendete Datenquelle legal freigegeben ist, warum wurde diese Relationen jetzt komplett gelöscht?
Bitte nicht falsch verstehen, aber ich setze mich ja nicht hin und arbeite diese Grenzrelationen AL11 ab, weil ich nichts besseres zu tun habe, sondern in der Annahme, dass diese statistischen Relationen auch zum OSM Projekt gehören und gebraucht werden, es sich aber bisher noch niemand gefunden hatte, diese Relationen in OSM einzuarbeiten.
Ich wünsche allen einen schönen 2. Advent.
Liebe Grüße, Stefan
den hab ich auch versucht zu erreichen, hab aber keine Antwort bekommen. Userid und sonstige Daten (einige Tage dabei, sofort Josm, nur Löschungen in Berlin) läßt auf eine Sockenpuppe (Zweitaccount) schließen.
Weil sie technisch falsch waren. Was alles falsch war, haben wir ja bereits von verschiedenen Seiten analysiert. Eine Bearbeitung dieser Daten (133 Relationen mit einigen hundert Ways) hätte mMn mehrere Wochen bedeutet, wie ich das bei einem ähnlichen Projekt im Kreis Recklinghausen leider erfahren mußte.
Über den Sinn dieser “Lebensräume” wurde ja auch schon heftig nachgedacht; mir ist das relativ egal (zu weit weg), solange die technische Realisierung stimmt.
Kläre dieses mit der Community ab und fange dann gegebenenfalls Schritt für Schritt an. Auf keinen Fall ein Massenupload, der ist schneller draußen als du blinzeln kannst.
walter
Es geht mMn darum, ob diese eher statistischen Gebiete unter “administrativ” laufen sollen.
Löschen ist da aber nach meiner Ansicht die falsche Vorgehensweise, ich würde Umtaggen auf boundary= vorziehen.
Dann kann man z.B. in Ruhe nachsehen, welche der Grenzlinien die genauere ist, ohne dass fast parallele Grenzlinien in der Karte stören.
Hallo,
complex_revert.pl hat die noch nicht revertierten Reverts von S-D revertiert.
Bei meiner oder Reparaturversuchen von atpl_pilot in der Vergangenheit ist eine größere Zahl tag- und mitgliedschaftsloser Nodes und Ways entstanden. Ich habe atpl_pilot gebeten mit den Keepright/OSMI in den Gegenden vorbeizuschauen. Nach aktueller Einschätzung von mir sind Grenzen nicht negativ betroffen.
Viele Grüße
Michael