Sie stellt eben das letzte Mittel da. Insofern ist es sehr schade, dass sie hier genutzt werden musste…
Grüßt euch,
zunächst einmal möchte ich mich dafür entschuldigen, dass der Informationsfluss zu dem beabsichtigten und mittlerweile auch schon gut voran gekommenen Hinzufügen der Straßenschlüssel für das Bundesland MV im Vorfeld wohl etwas unzureichend gewesen ist (https://lists.openstreetmap.de/pipermail/meckpomm/2014-November/002220.html). Demzufolge ist die Aufregung hierzu nur zu verständlich. Dies wird aber nun in Kürze vollumfänglich nachgereicht.
Ich habe in der Vergangenheit viel Zeit mit den Straßen von MV verbracht und am Bildschirm die Straßen geprüft und manuell den Straßenschlüssel zugewiesen.
Die Straßenschlüssel als solche sind auch nicht geheim, sondern über den Link http://www.laiv-mv.de/land-mv/LAiV_prod/LAiV/AfGVK/Liegenschaftskataster/Schluesselverzeichnisse/ einsehbar.
Im Schlüssel stecken die Informationen Kennzahl des Bundeslandes, Regierungsbezirkes, Kreises, Verbandsschlüssels, die Gemeindekennzahl sowie zu Schluss die Straßen ID.
Mit Hilfe eines solchen Schlüssels existiert somit ein eindeutiges Merkmal um unabhängig vom Namen nach Straßen zu suchen. Nehmen wir z.B. Abkürzungen von Str., str. oder Bindestriche im Name, selten ein Apostroph. Das sind alles Aspekte, welche eine Suche - und auch die Qualitätskontrolle - massiv erschweren. Der Schlüssel ist eindeutig!
Das Hinzufügen des Straßenschlüssels dient somit der direkten Qualitätskontrolle und das kann ja nur zum Nutzen von OSM sein.
Hallo,
also ich finde die Überzeugung einiger Mapper, dass OSM und die Mapper-Community alles besser und schneller können ein wenig selbstherrlich.
Jeder kann auf regio-osm.de nachsehen wie gut (oder schlecht) der Erfassungsstand der Straßen in seiner Gemeinde ist.
In Nordthüringen sieht es da teilweise verheerend aus, für MeckPomm habe ich auch mal nachgesehen, durchschnittlicher Erfassungsstand 70 - 90 % mit Ausreißern Richtung 30 %, die 100 ist aber auch oft zusehen.
Wie lange wurde gebraucht diesen Stand zu erreichen und wie lange soll es noch dauern bis überall die 100 % Abdeckung der Straßennamenerfassung erreicht ist ?
Und da wo Straßennamen fehlen fehlen ja auch die Adressdaten.
Wenn Daten mal einen Fehler haben, dann kann das ja nicht so schlimm sein, es wird sich ja immer mit der schnellen Reaktion von OSM gerühmt
z.Bsp. Wochennotiz Nr. 257 “Keiner ist schneller als OSM, …”.
Es gibt aber noch keinen offiziellen “Edward-Snowden-Platz” in Dresden, das Taging ist also falsch.
Wie Harald schon geschrieben hat, haben wir einen Fehler gemeinsam in der Thüringer Straßenliste gefunden, ich habe beim mappen noch 2 entdeckt.
Von welcher Stelle hinter dem Komma sprechen wir bei dieser Fehlerhäufigkeit für ein Bundesland ?
Leider ist die Kommunikation mit unserem Landesvermessungsamt nicht gerade zielführend.
Wie ihr aber seht, sind die Mitarbeiter des Vermessungsamtes von MeckPomm in der lokalen Mailingliste sowie auf Mappertreffen aktiv und reagieren auch auf Kommentare hier im Forum.
Wir sollten vieleicht mal darüber nachdenken welchen Mehrwert uns die Zusammenarbeit mit einem Kataster-, Vermessungs- und Liegenschaftsamt bringt.
Grüße aus Thüringen
Senni
Ein Revert ist das üblich Vorgehen, nach dem Entdecken eines nicht Policy-konformen Imports. Es kann und darf nicht sein, dass durch das Brechen von Regeln Fakten geschaffen werden! Deshalb wird revertiert. Die Konflikte werden wohl gar nicht so zahlreich sein und das Auflösen wird recht einfach sein, da ihr nur ein Tag ergänzt habt. Die schnellste Methode dürfte sein, einfach alle de:strassenschlüssel=* in Mecklenburg-Vorpommern per Overpass-API zu suchen und dann zu löschen.
Viele Grüße
Michael
Als Ergänzung, dass sollte hier auch noch mit reinpassen: (benannte) Straßen (körper) im Katasteramt müssen nicht zwangweise im Liegenschaftsamt einer Gemeinde geführt werden und umgekehrt! (Auch eine eigene leidvolle Erfahrung)
Und das kann man in der Tat dann als “normaler Mapper” wirklich nur noch sehr schwer nachvollziehen 
hmm, bitte nochmal einen Gedanken hierfür verwenden:
Nur allein die Straßenschlüssel rauszuwerfen, bringt also nicht den Ausgangszustand zurück !
Und das sinnvolle Auftrennen einer z.B. durchgehend durch zwei Orte verlaufenden “Dorfstraße” ist ja auch eine echter Qualitätsgewinn - sofern nicht alle der drei so entstandenen Straßenabschnitte den alten Namen = “Dorfstraße” beibehalten - außerorts sollte der Straßenname besser “wech”.
Insofern könnte ich auch mit folgendem leben:
(a) die Quelle wird offengelegt (schon passiert), deren Verwendbarkeit unter der ODbL “nachgewiesen” und auf einer wiki-Seite leicht auffindbar verlinkt oder hinterlegt
(b) die Quelle bleibt auch künftig - regulär aktualisiert - dauerhaft für die Nutzung in OSM unter der ODbL offen
Auf einen revert nur aus Prinzip kann ich persönlich verzichten, wenn hinterher die Daten ohnehin neu eingepflegt würden und so nur der Versionierung erhöhen und die history aufblähen …
Ist halt alles “ein wenig suboptimal” gelaufen, dennoch sollte man sich doch auch nachträglich einigen können, wenn die “Minimalvoraussetzungen” - aus meiner Sicht (a)+(b) - eingehalten werden.
Grüße Rainer
sehe ich auch so.
Fehler können jedem mal passieren. Es wurde sich sogar entschuldigt und da das eine lokale Angelegenheit in Meckpomm ist, kann und darf die deutsche Community natürlich auch was sagen, aber ich persönlich geb trotzdem erst mal mehr auf das was Matthias sagt. Und der sagt: nicht löschen.
Wir haben ja kein automatisch-gegen-regeln-verstoss-revert-bot, sondern menschliche Experten, die jeden neuen Fall begutachten und wohlwollend handhaben können.
Und von allen import Problemen der letzten Zeit sehe ich hier viele Sachen, die man heilen könnte.
Also lieber den Beteiligten helfen, als wir-beharren-auf-unsere-regeln.
Und im Grunde haben WIR das Problem, das den Beteiligten unsere Import-Regeln nicht kennen.
WEIL WIR GAR KEINE HABEN! bzw. KEIN MENSCH FINDET SIE.
(mal schauen, ob es auf dem OSM-Sommercamp interessierte Mapper gibt, die sich dem annehmen. Wer Lust hat und nicht in Essen sein kann, könnte natürlich auch online helfen)
Ich widerspreche Nakaner, dessen Arbeit und Engagement ich sehr schätze, nur ungern, aber nachdem ich diesen Thread “von außen” verfolgt habe, möchte ich doch fragen, ob wir hier nicht ein bisschen übers Ziel hinausschießen. Eines der wenigen ganz praktisch umsetzbaren Dinge, die ich im Philosophiestudium gelernt habe, ist, dass man im Leben nichts nur aus Prinzip machen sollte.(*) Wie die Juristen sag(t)en: summum ius summa iniuria, die extrem Durchsetzung des Rechts wird zum Unrecht. (Juristen können mir hier gerne widersprechen, aber “wir Philosophen” verstehen dieses Rechtssprichwort so ;))
Also: gibt es weitere gute Gründe für ein Revert? Dann ja, bitte. Sollte es aber am Ende nur ums Prinzip gehen, dann würde ich sagen: macht doch mal halblang. 
Edit: Typo korr.; vorhin irgendwie verschütt gegangene Fußnote ergänzt:
(*) Ausgenommen, es handelt sich um ein Grundprinzip der Ethik wie den Kategorischen Imperativ oder das christliche Liebesgebot 
Für alle anderen, untergeordneten oder abgeleiteten Prinzipien gilt dagegen, dass sie nie absolut gesetzt werden sollten, sonst kommt ganz schnell Unrecht dabei heraus.
Allerdings hätte ich noch eine ganz dumme Frage: warum eigentlich
de:strassenschluessel=*
und nicht eher so etwas wie
ref:strassenschluessel=*
? Ich würde letzteres erwarten, vgl. Tags wie
ref:fgkz=*
etc. 
Auf den ersten Blick stimme ich dir zu.
Wir hatten damals abgewogen, uns aber aufgrund dessen, dass er AFAIK schon ein paar mal genutzt wurde dafür entschieden. Er ist unserer Meinung nach analog zu den bestehenden anderen amtlichen Merkmalen ohne ref
Da der tag nicht soooo häufig gebraucht wird, erschien uns die lange Schreibweise vertretbar und eindeutig für andere Mapper.Sollte es aufgrund nachvollziehbarer Gründe den Schlüssel ganz anders zu benennen ist das sicherlich auch machbar. Allerdings bitte nicht einfach eine der langen und unfokussierten tagging-Diskussionen anfangen, denn wie überall gibt es ja meistens immer gute Gründe für/gegen einen Vorschlag 
Danke für die Erklärung! Stimmt, es gibt ja auch schon die von Dir zitierten anderen “amtlichen Merkmal[e]” mit de:… statt ref:…. (Warum auch immer: die Straßenklassifikation und die Fließgewässerkennzahl sind ja auch “amtlich”, haben aber ref:… So ist eben das Leben in OSM. :/)
Ich finde es auf jeden Fall gut, dass ihr eine “lange Schreibweise” gewählt habt: das ist viel besser als noch eine scheinbare bequemere, aber am Ende mehrdeutige und unklare Abkürzung (à la de:strsch=* oder so).
Nein, natürlich nicht! Ich wollte tatsächlich einfach nur mal nachfragen … Letztlich ist es auch egal, wie das Pferd heißt, hauptsache man kann sich den Namen merken (um darauf zu setzen) und es gewinnt.
Edit: ergänzt.
Ich möchte mich für die zahlreichen Beiträge bedanken. Das hilft uns sehr weiter die Arbeitsweise mit OSM-Daten zu verstehen und bedauere es, dass wir die Diskussion nicht früher geführt haben und ich habe wirklich leider nichts von den Policies gewusst.
Hier noch mal der Hinweis. Es wurden wirklich bisher nur Tags angehängt und zwar genau einer und genau de:strassenschluessel und immer mit dem gleichen Nutzernamen streetkeysmv.
Es sollte also einfach sein diese zu finden und zu reverten. Es wurden noch keine Aufteilungen von Strassen hochgeladen.
Problematisch ist folgendes:
- Es kann sein, dass es vorher schon Strassen mit tag de:strassenschluessel gab. Einfach alle zu löschen wäre dann also auch falsch
- Es kann sein, dass Strassen im nachhinein schon von anderen geändert wurden, dann sind die, die von streetkeysmv kamen nur über die History zu finden.
Wenn man generell zustimmt, dass de:strassenschluessel tags zu OSM-Strassen sinnvoll sind halte ich es wirklich auch für nicht zielfuehrend, wenn die jetzt schon vorhandenen revertet werden um sie hinterher wieder hinzuzufügen. Dann wäre nur die History aufgeblasen. Das sehe ich so wie projecter63.
Ich habe auch schon drüber nachgedacht, dass unsere Vorgehensweise für einen zeitversetzten Changeset nicht besonders effektiv war. Beim einfachen Upload der Strassen mit einem zusätzlichen Tag war das nicht zeitversetzt. Wir haben einen bestimmten Stand in die eigene Datenbank mit osm_ids eingelesen. Dann die Zuordnungen gemacht, aber beim Update alle einer Gemeinde per overpass API geholt, an jede die Zuordnung angehängt und den Changeset nach nochmaliger manueller Begutachtung versendet. Zwischen Daten holen und senden liegen also wirklich nur ein paar Sekunden oder wenige Minuten, nicht anders als bei einem normalen Edit mit JOSM oder so. Wenn wir eine osm_id über overpass nicht gefunden haben, haben wir auch nichts geupdated.
Hier müssen wir dann nacharbeiten. Bei den aufgeteilten Strassen ist es schlimmer, weil wir hier nicht nur einen Tag anhängen müssen, sondern auch neue Nodes, Strassen und Zuordnungen zu Relationen einordnen müssen. Hier macht sich das schlecht wenn sich die Geometrie geändert hat.
Hier müssen wir das Verfahren wohl noch mal so ändern, dass wirklich einzelne Aufteilungen separat auf OSM-Hochgeladen werden, so wie wenn man einen Ausschnitt mit einem Editor bearbeitet. Jetzt könnte man fragen warum das nicht gleich manuelle mit einem Editor gemacht wurde. Nun der Grund liegt darin, dass die Anwendung, die wir entwickelt haben speziell auf die Zuordnung und Aufteilung nach Strassenschlüsseln zugeschnitten ist und das viel schneller damit geht. Schließlich sollen hier ja auch tausende Strassen bearbeitet werden und nicht nur ein paar.
Wie geht es jetzt also weiter? Ich habe erstmal aufgehört mit der Weiterentwicklung der Update-die-geteilten-Strassen Funktion. Dürfen wir nun importieren? Wenn generell nicht brauch ich auch nichts auf den Import-Katalog setzen. Oder wird der Import genehmigt, wenn der Eintrag da drin steht?
Ich habe mir gerade nochmal den kompletten Thread durchgelesen und aus dem gehnen im wesentlichen ja die folgenden 4 ursprünglichen Probleme hervor:
-
Quelle für Straßenschlüssel -
Verstoß gegen Import guidelines, Automated Edits code of conduct
-
Mangelnde Kommunikation mit Community -
Sorge vor “stumpfen” Importieren / unnütze Daten / Unklarheit Namensersetzung / …
Ich hoffe ich bin nicht zu optimistisch, denke aber wir sind da auf einem guten Weg um diese Probleme auszuräumen und auf die Sorgen einzugehen. Die policies habe ich nochmal studiert und probiere diese umzusetzen. Kern ist ja die Kommunikation/Dokumentation des Importes, wo wir nun zumindest einen Entwurf im Wiki haben, an dem wir Montag weiter bauen werden. Er fasst viele Infos nochmal zusammen und erklärt den Import im Zusammenhang. EInige Aspekte der policies werde ich noch ergänzen.
Meine Bitte wäre, dass ihr euch äußert was euch dort auf der Seite noch fehlt, das probieren wir nach Möglichkeit dann zügig nachzuliefern. Schaut euch gerne auch die Struktur der Changesets an und sagt uns ob ihr da Vorschläge habt wie man es anders/besser machen kann
Dann würden wir das Feedback nächste Woche berücksichtigen und gemäß den policies auf import ML, talk-de bescheid sagen. Danach würden wir nochmal mit der DWG reden ob ein revert sinnvoll ist, oder ob aus ihrer Sicht andere Gründe gegen eine Fortführung der Ergänzung der Straßenschlüssel sprechen.
(wir sind dann mal im Wochenende. Nach Möglichkeiten probiere ich hier gerne als user:!i! dann zu kommentieren, aber auch das kann etwas dauern. Bitte nicht ungeduldig sein ;))
N’Abend,
Ich hab mir jetzt mal den Entwurf der wiki-Seite angeschaut; hinsichtlich der folgenden beiden Punkte bitte ich um Ergänzung:
(1) auf der verlinkten Seite des laiv-mv steht:
“Die Schlüsselverzeichnisse des Liegenschaftskatasters liegen mit folgenden Inhalten im Excel-Format (xlsx) kostenfrei zum Download vor: …”
Eine pure Kostenfreiheit ist noch nicht gleichbedeutend mit der Kompatibilität zur ODbL! Hier wäre mir mit einem entsprechenden Dokument wohler, in dem der Rechteinhaber der Daten sein Einverständnis zur Übernahme in OSM bestätigt - bzw. konkret: Ich halte ein solches Dokument für erforderlich.
Etwa so: “Sehr geehrte(r) …, hiermit stimme ich der Verwendung der Daten des (…) im Projekt OSM zu. Auf eine spezielle Attributierung der einzelnen OSM-Objekte kann dabei verzichtet werden. …”
(2) Wer die zip-Datei dann herunterlädt, wir nicht unbedingt gleich den Straßenschlüssel für einen bestimmten Straßenabschnitt herauslesen können, um die Angaben in OSM leicht gegenzuprüfen. Hier wünsche ich ‘mir’ im Interesse des allgemeinen Handlings eine leichtverständliche Anleitung, wie der interessierte Mapper von der *.zip zum fertigen Straßenschlüssel kommt.
Grüße Rainer
XSLX? Wirklich? Wenn dann bitte ein freies Format wie CSV oder ODS.
Das stimmt, dass müssen wir noch mal etwas erklären. Urheber der Daten sind die einzelnen Katasterämter der Landkreise. Das LAIV hat von diesen die Erlaubnis bekommen die Daten zusammenfassen und veröffentlichen zu dürfen. Parallel hat das Katasteramt Rostock im Rahmen von REGIS die Erlaubnis bekommen hier ebenfalls stellvertretend für alle Katasterämter die Daten für OSM nutzen und veröffentlichen zu dürfen. Dazu gibt es zwar interne Mails, aber von einer Veröffentlichung würde ich absehen, denn wem ist mit einem gepasteten Text a la “Jo dürft ihr nutzen” geholfen? Das KVLA HRO hat die Erlaubnis und wir erlauben den besagten Partner die Daten einpflegen, von daher sehe ich da kein Problem, dokumentiere das aber gerne im Wiki noch detaillierter…
In der .zip sind CSV (CP1250), ich weise die Kollegen aber gerne auf die veraltete Beschreibung hin. Leider hat das Land noch kein Open Data-Portal, wo man das in bel. Formaten beziehen könnte.
Rainers Hinweis zum Preprocessing würde bedeuten, dass wir dann zwingend eine neue Datei irgendwo (wiki, geoport-mv.de, …) hochladen müssten, welche dann natürlich schnell veraltet und wo für Außenstehende nicht klar ist wie “offiziell” diese Daten sind. Wäre es da nicht sinnvoller bei der Primärquelle zu bleiben? Ich probiere gerne nochmal die Bildungsforschrift im Wiki zu dokumentieren, vielleicht reicht das ja schon?
Ich habe das Vorhaben auch auf Talk-de vorgestellt und die Seite in den normalen Namensraum verschoben.