Strassenschlüssel McPom

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 :confused:

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. :sunglasses:

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 :slight_smile: 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. :slight_smile:

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 :wink:

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 … :wink: 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:

  1. Es kann sein, dass es vorher schon Strassen mit tag de:strassenschluessel gab. Einfach alle zu löschen wäre dann also auch falsch
  2. 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 :slight_smile:

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? :wink: 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.

Wir haben uns an die DWG gewendet, um zu klären wie aus ihrer Sicht weiter verfahren werden kann.

Da die meisten Hinweise ja hier aus dem Forum kamen, wollte ich fragen, wie ihr den aktuellen Stand unserers Vorgehens einschätzt? Es kamen zwar keine weiteren Anmerkungen, aber gerne möchte ich nochmal nachhaken, ob ihr Probleme seht, wenn wir mit der Ergänzung der Straßenschlüssel in der kommenden Woche weiter fortfahren? Wir hoffen, dass das ein ausreichender Horizont für weitere Hinweise ist?

Ich habe durch die Info’s in der neu angelegten wiki-Seite nunmehr keine Bedenken mehr gegen eine Fortsetzung der Arbeiten.

Allerdings glaube ich nicht, dass sich ein nenneswerter Anteil der Mapper die Mühe machen wird, einzelne Straßenschlüssel zu kontrollieren oder neu eingetragene Straßenabschnitte auf die Existenz eines Straßenschlüssels hin zu überprüfen. Dafür ist das Verfahren des Downloads, Entkomprimierens, Öffnen der richtigen csv, Aufsuchen des passenden Straßensegments und Bilden des Straßenschlüssels einfach zu umständlich.
Nur so als mittelfristige Idee - vielleicht als Studienarbeit oder größere Fingerübung für den Praktikanten: Die Bereitstellung eines ‘Straßenschlüssel-Generators’ (duckwech) … - ein paar choice-Boxen und als Ergebnis gibt’s das Straßenschlüssel-tag (z.B. Prinzip Verkehrszeichen Tool - http://osmtools.de/traffic_signs/)

So wie’s jetzt ist, wird die Qualität der Versorgung mit den Straßenschlüsseln in McPom de facto an dem künftigen Engagement des Kataster-, Vermessungs- und Liegenschaftsamt der Hansestadt Rostock hängen - und das ist nicht OSM-typisch …

Zusammenfassend aus meiner Sicht: ja, weitermachen - verbunden mit dem Wunsch (keine Forderung) nach einem allgemein-tauglichen Werkzeug

Nach dem Durchlesen des Threads will ich Folgendes dazu sagen:
Erst schießen revertieren und dann fragen wird zum Glück von der Mehrheit nicht unterstützt.

Da es keine unfehlbare, alles regulierende OSM-Hauptinstanz gibt, sondern jeder Mapper OSM vertritt, würde ich dem Tenor dieses Threads folgend sagen:
Ja.

Auf der Import-Katalog-Seite sollen nur Informationen zu dem Import zusammengefasst werden. Der Eintrag dort fällt unter Dokumentation

Beispiele zur Dokumentation entsprechender Kommunikation zur Freigabe von Daten sind hier
zu finden. Eure sollte dort auch erwähnt werden.

Zu

Wenn neue Tags erfunden werden, sollen die menschenlesbar sein.

Was ich gern noch wüsste: Werden die Schlüssel nach dem Import regelmäßig kontrolliert/aktualisiert? Ich weiß zwar nicht, ob es amtsseitig gelegentlich Änderungen gibt, aber ich weiß sicher, dass früher oder später ein paar der Schlüssel aus OSM verschwinden werden. Das kann geschehen durch:

  • versehentliches Löschen
  • das Löschen “unnützer” Tags
  • beim “Überarbeiten” von Straßen, indem die originale Straße gelöscht und eine neue gezeichnet wird, letztere aber nur einen Bruchteil der ursprünglichen Tags bekommt
  • Vereinigen zweier Straßen zu einer mit dem Resultat: de:strassenschluessel=123456;78901212

Diese vier Vorgehensweisen habe ich alle innerhalb Deutschlands gefunden – Wiederholungen halte ich für wahrscheinlich.

Anmerkung: bei

sind die Links und Schreibweisen verbesserungsfähig

Eigentlich sind die Straßenschlüssel ein sehr stabiles Merkmal. Es gibt AFAIK nur in Ausnahmefälle an denen wirklich destruktive Veränderungen (z.B. weil Straßen wegfallen). Aber klar, wenn ein Schlüssel da war und weiterhin da sein müsste, nun aber nicht mehr in OSM ist, kann man mal nachschauen was sich dort verändert hat.

Das geht denke ich in die selbe Richtung wie der Hinweis von Rainer / @projecter63. Unser Zielt ist natürlich gerade auch die langfristige Betreuung der Schlüssel und zumindest ein Monitoring der Änderungen. Da wir aber derzeit noch keinen genauen Ansatz haben, wie wir das realisieren, wollte / möchte ich da aber nicht zu viel versprechen. Was wir uns wünschen würden, wäre eine Lösung ähnlich den Straßenlisten von www.regio-osm.de, nur dass diese eben auf Straßenschlüssel arbeitet. Inwiefern wir da auf bestehende Sachen aufsetzen können, da würde ich erstmal diesen ersten Lauf abwarten und wie wir gemeinsam mit den Ergebnissen umgehen können :slight_smile:

P.S: Stimmt die DE:Permissions gabs ja auch noch… So langsam glaube ich @MGehling hatte recht, dass die Infos bzgl. Importen/mech. edits mal gestrafft werden sollten :wink: