Als ich hier bei OSM angefangen hatte, war ich total begeistert. Irgendwann, so 2008/2009 rum, hatte ich mich dann aus OSM zurückgezogen. Der Grund war hauptsächlich, dass mich das Datenmodell genervt hat und ich mit den Diskussionen auf der Mailingliste psychisch nicht zurecht kam. Ich lit damals an einer rezidivierenden Depression, aber das wusste ich nicht, ahnte es noch nicht einmal.
Inzwischen hat sich einiges geändert, sowohl beim Datenmodell, als auch bei meiner psychischen Gesundheit. Zu letzterem kann ich sagen: Ich bin inzwischen die Depression komplett los geworden.
Nur: So richtig glücklich bin ich mit dem Datenmodell nach wie vor nicht. Dann kam die Diskussion zur landuse=flowerbed-Problematik auf. Das hab’ ich zum Anlass genommen, mir das Datenmodell mal genauer anzuschauen. Wobei: Bis zu landuse=flowerbed bin ich dabei letztend Endes gar nicht vorgedrungen. Ich hab’ mich mehr auf die Basics konzentriert und selbst da das Gefühl, dass noch einiges fehlt.
Den Schwerpunkt der Untersuchung habe ich auf die Probleme des Datenmodells gelegt. Das heißt aber nicht, dass ich nicht auch die Stärken sehen kann (sonst wäre ich nicht hier) - mir wäre das nur zu schwammig geworden, wenn ich beides berücksichtigt hätte.
Die Ergebnisse der Untersuchung habe ich ausgearbeitet (weil mir das hilft, meine Gedanken zu ordnen und ich sowas auch ganz gerne mache). Die daraus resultierende Studie zum Datenmodell habe ich mal im Wiki hochgeladen.
Mir fällt es gerade schwer, das Ganze einzuordnen. Das kann meinem Gefühl nach von “Uraltes Zeug, hammer schon 100mal diskutiert” bis “das muss unbedingt in die nächste OSM-Weekly” alles sein. Wie dem auch sei, ich würde mich freuen, eure Meinung dazu zu erfahren.
Tolle Studie, Viele Punkte angesprochen, äh, jede Menge Salz in offene Wunden gestreut – Nicht ganz gelesen, zu spät heute.
OSM-Auskenner - wird das je ein Anforderungsprofil für Stellenbewerbung? Nicht trivial das! Kunden/Interessenten sollte es wohl geben? Momentan wird das wohl inner-betrieblich von Auswerter zu Auswerter eigens behandelt. Insbesondere Router könnten Leute mit dieser Qualifikation brauchen.
Satz mit TeX - Word 2090 wird dann irgendwann dieselbe Qualität bieten?
Ja irgendwann wird man die Probleme angehen Aber im Laufenden Betrieb ist das immer schwierig… und das ganze “Ökosystem” um OSM muss ja auch noch mit. Eine kleine Änderung… und tausende Programme müssten angepasst werden.
Ich als alter CAD/GIS Hase… würde mir ja wünschen wenn die Daten in verschiedenen Layern aufgeteilt wären
Die ich dann ausblenden, einfrieren… usw. kann. Würde die Bearbeitung sehr erleichtern… auch für Einsteiger. JOSM bietet nur die Filter Möglichkeit… kompliziert, umständlich… langsam.
Flächen: In der Realität gibt es keine Linien, sondern nur Flächen. Hier sehe ich ein großes Betätigungsfeld für die nächsten Jahre. Einen Datentyp ‘Fläche’ sehe ich zunächst für neue Objekte. Zum Beispiel für Straßenflächen.
Tags: Bei den Tags würde ich mir die Definition eines “Goldstandards” wünschen, erstellt von einer OSM-Arbeitsgruppe. Der Standard umfasst nur einen kleinen Teil aller Tags, ist dann aber verbindlich. Die Auswahl der Tags könnte zum Beispiel nach der 80:20-Regel erfolgen.
Im Moment sehe ich aber nicht, dass auch nur eines der Themen eine Chance auf Umsetzung hat.
Ja, das ist klar. Ich denke, das wichtigste ist, dass man verlustfreie Konverter schreibt, mit denen man vom alten Datenformat ins neue und zurück wechseln kann. Dann kann sich der Änderungsprozess über mehrere Jahre hinziehen. Wer seine Software nicht anpassen will, konvertiert halt ins alte Format und kann dann wie gewohnt weitermachen. Andere können schon mit dem neuen Format experimentieren, bevor der Server offiziell wechselt…
Wobei bei Overpass irgendwo in der Anleitung steht, dass das ursprünglich mal für Flächen ausgelegt war (in der Hoffnung, dass OSM nachzieht) und dass das teilweise derzeit zurückgebaut wird, weil man dort die Hoffnung aufgegeben hat.
Die Frage wäre dann für mich, wie sieht sowas aus. Werden dann 20 (oder wieviele auch immer) gültige Werte für highway vorgegeben unter denen man nur noch wählen darf? Ich glaube, es ist sehr schwierig, so einen Goldstandard herzustellen. Ich würde mir viel eher möglichst klare Formulierungen wünschen. Wenn (idealerweise) bei jedem realen Objekt ganz klar ist, wie das zu mappen ist, dann kann man in falsch und richtig unterscheiden und die Fehler korrigieren. Solang unklar ist, was falsch oder richtig ist, ist das viel schwieriger.
Ich hab’ da keinen wirklichen Einblick. Aber sowas, wie den type-Tag auf alle Datentypen auszuweiten wäre meiner Meinung nach schon denkbar. Besser wäre es allerdings, mit dem Area-Typ anzufangen. Vieles würde danach dominoartig nachziehen, denke ich…
Ich als alter CAD/GIS Hase… würde mir ja wünschen wenn die Daten in verschiedenen Layern aufgeteilt wären
Die ich dann ausblenden, einfrieren… usw. kann. Würde die Bearbeitung sehr erleichtern… auch für Einsteiger.
damit wirft man aber einiges an Topologie weg, und muss dann je nachdem mehrere Layer gleichzeitig bearbeiten oder sie werden inkonsistent zueinander. Auf der Welt hängt vieles mit vielem zusammen, dass wir das abbilden können ist aus meiner Sicht ein Vorteil. Das Layermodell funktioniert m.E. nur wenn man sehr konsequent arbeitet weil man die Bezüge jeweils mitdenkt, geht gut alleine oder mit einem eingespielten Team eher nicht so mit vielen Dilettanten die alle kleine Änderungen machen (jetzt mag es manchem komplex erscheinen dass an einem Knoten oder way so viel dranhängen kann, wenn es trotzdem dranhängt aber auf mehrere Layer verteilt ist und die Bezüge implizit sind, dann ist das noch viel komplexer und schwieriger einzusteigen bzw. zu editieren ohne was kaputt zu machen)
Um sicher zu gehen, müssten immer alle Layer im Hintergrund geladen werden und nur interessierende angezeigt werden.
Das ist ähnlich wie beim Filtern: Wenn man nur gefiltert lädt, kann unabsichtlich nicht Geladenes beeinträchtigt werden.
Ich lade deshalb zunächst komplett und filtere ggf. danach und lasse auch die Anzeige der ausgefilterten Objekte nicht komplett unterdrücken (d.h. sie sind nur ausgegraut). So sehe ich wenigstens, wenn sich beim Bewegen eines Nodes eine graue Linie mit bewegt.
Das Inkonsistenzproblem haben wir aber auch jetzt schon: Es ist ziemlich leicht, Relationen durch “harmloses” Aufteilen oder Zusammenfügen von Ways zu “zerschießen”.
Z.b die Admin Grenzen wenn diese in einem eigenen layer liegen würden würde das versehentliche bearbeiten oder löschen schon mal größtenteils vermieden.
Weiter landuse and natural werden meist als Flächen erfasst… Straßen dagegen werden ja grundsätzlich nicht das Flächen erfasst. Straßen werden als Achsen erfasst und hier macht eine Verbindung eigentlich keinen Sinn… Ja das Problem schon einen Namen “verkleben”
Weiter lassen sich viele Objekte oder Sachverhalte auf einen Way, Note… bringen… was allein hier schon viele Inkonsistenz sind da man die einzelnen Tags oft nicht scharf trennen kann voneinander. Beispiel “name” wenn hier ein Geschäft getaggt ist auf einem Gebäude dann kann man nicht sagen wofür der Name eigentlich steht. Ist der Name der Name des Gebäudes oder ist der Name der Name des Geschäfts. Das sieht man ganz deutlich am renderer der das auch nicht auseinanderhalten kann will man einen Namen sehen so trägt man einem Geschäft einfach aufs Gebäude ein.
So gibt es jede Menge ähnliche Beispiele eins fand ich auch sehr lustig ein weihnachtsbaumverkauf der auf einer packstation getaggt war… nicht sinnvoll aber möglich…
bei den gut ausgereiften Editoren (Josm und ggf. andere) ist es allerdings so, dass man in diesem Fall gewarnt wird. Klar, wenn man nicht aufpasst kann man viel kaputtmachen, das ist halt der Kehrseite der Freiheit viel tun zu dürfen.
Mach dir da keine Sorgen, die Diskussion zeigt, niemand hat AUA geschrien.
Ich hab ja ein wenig geschmökert in Deiner Studie. Es geht da meiner Ansicht nach weniger ums “Datenmodell” – also sicher nicht in dem Sinn wie im Topf Link – sondern eher um Semantik oder Ontologie. Eventuell spielt auch auf OGC an.
Zur Wiederholung: OSM Auskenner:in kann für einen Lebensunterhalt ausreichen – Keine Kleinigkeit das, aber geschenkt ist wohl nix. Einige consumer wären sicher gut beraten damit so wen einzustellen. Und das ist ganz im Sinn der Sache – Die Mapper erheben die Daten, die Auswerter backen draus Kuchen.
PS:
InDesign hat das gemacht, zumindest beim Ausschießen von Absätzen, so viel ich weiß, keine Ahnung warum Word da immer noch nicht nachzieht
Das Problem mit nur einer Spalte ist, dass dann die Zeilen zu lange werden und das Auge bei den Zeilensprüngen ermüdet. Man müsste deswegen dann eine größere Schrift verwenden, was wiederum bedeuten würde, dass die Studie etwa viermal so viele Seiten hätte. Meiner Ansicht nach ist das nicht sinnvoll. (Aber das Ganze ist ohnehin etwas off-topic, genau wie die LaTeX vs. Word Diskussion oben, ich werde darauf deswegen nicht mehr weiter eingehen.)
Vielen dank für diesen Link. Ich war jetzt ein paar Tage offline, habe die Zeit aber nutzen können, um mir die Studie von @Jochen_Topf mal genauer ansehen zu können. Jochen spricht, soweit ich das sehe, im Wesentlichen drei Punkte an:
Die Stützpunkte für Wege, die in OSM wie echte Punkte mit Tags gespeichert werden. Dadurch befinden sie sich für die algorithmische Verarbeitung an der falschen Stelle und produzieren kaum nutzbaren Metadatenmüll.
Das fehlende Area-Element.
Im Zusammenhang mit dem Area-Element auch die Einführung von erzwungenen Eigenschaften dieses Elements (Richtung der benutzten Wege, selbstkreuzungsfrei).
Mit meinen Überlegungen überlappt nur der zweite Punkt. Der erste und dritte dieser Punkte behandelt Dinge, die derzeit schon algorithmisch korrekt behandelt werden können, wo die Verarbeitung allerdings (sehr) aufwendig ist und die Veränderung darauf abziehlt, diesen Aufwand zu reduzieren.
Bei mir ist der Schwerpunkt mehr auf Dingen, die überhaupt nicht algorithmisch korrekt lösbar sind. Beispielsweise kann man derzeit Linien und Flächen nicht scharf trennen. Man kann auf Heuristiken zurückgreifen, die in vielen Fällen funktionieren. Jochen selbst hat da eine Regelmenge mit 181 Einträgen für vorgeschlagen. Aber selbst mit diesem enormen Aufwand wird man an einigen Stellen fehlerhaft entscheiden. Mein Wunsch wäre eine Datenstruktur, bei der der Mapper diese Entscheidung übernimmt, nicht ein mehr oder minder guter Algorithmus.
Erst einmal das Wichtigste: Deinen Verbesserungsvorschlägen stimme ich im Wesentlichen zu – insbesondere dem Area-Datentyp, einem eindeutigen Haupt-Tag für jedes Objekt und der konsequenten Trennung von Objekten.
Ja, die OSM-Community tut sich extrem schwer mit allem, was nicht dezentral und inkrementell funktioniert. Ich würde mir wünschen, dass die OSM-Community die Fähigkeit entwickelt, auch solche großen Veränderungen zu koordinieren und anzugehen.
Am greifbarsten ist wohl tatsächlich die Einführung des Area-Datentyps. Zum einen, weil es dafür zumindest in Grundzügen einen breiten Konsens gibt und u.a. Jochen da schon gute Grundlagen gelegt hat, um das Thema in die Köpfe zu bekommen. Zum anderen, weil es dort anders als beim Tagging eine vergleichsweise klare Zuständigkeit gibt: Die API-Maintainer und die OSMF als Betreiberin der API haben das Heft in der Hand. (Wobei es natürlich trotzdem entscheidend ist, die Entwickler- und Mappercommunity einzubinden, vorzubereiten und mitzunehmen.)
Noch ein bisschen Detailkritik:
Die statistischen Werte unterscheiden sich deutlich von denen auf Taginfo (z.B. Relationstypen). Hast du einen Extrakt verwendet?
Die Kritik an Conditional Restrictions und Lanes finde ich unzutreffend (nein, die Reihenfolge der Sub-Schlüssel ist nicht beliebig – die beiden von dir genannten Beispiele sind unterschiedliche Schlüssel mit jeweils eindeutiger Bedeutung und unterschiedlichem Wertetyp). Dass diese Schlüssel nicht intuitiv verständlich und potentiell verwirrend sind, ist natürlich richtig. Allerdings ist mir kein Alternativvorschlag bekannt, der diese auch in der Realität komplexen Sachverhalte einfacher abbildet.
HTML-Entitäten wie & sind aus meiner Sicht kein Datemodell-Problem. Mir ist kein Schlüssel bekannt, in dem deren Verwendung erwünscht ist, und da Werte Unicode-Strings sind, ist das auch nicht nötig. Wenn sie vorkommen, ist das eher ein kaputter Import oder eben ein Mapping-Fehler.
fire_hydrant:diameter ist kein gutes Beispiel. Das fire_hydrant: dient hier nicht der eindeutigen Zuordnung zu einem Haupttag, sondern es handelt sich bei fire_hydrant:diameter um ein eigenes Attribut mit einer von diameter abweichenden Definition. (Es beschreibt den Durchmesser des unterirdischen Rohrs, das den Hydranten speist.)
Taginfo bezieht sich auf den ganzen Planeten, meine Werte beziehen sich nur auf Deutschland, Dump vom 1.1.2024. (Siehe Zusammenfassung und Fußnote 4.)
Meinst du bus:lanes:backward und lanes:bus:backward? Da ich mit Lanes bislang nicht intensiv gearbeitet habe, kann es sein, dass da was an mir vorbeigegangen ist. Mir ist der Unterschied jedenfalls nicht bekannt.
Mein Fehler. Im XML-Format der OSM-Dateien werden diese verwendet um Unicode-Zeichen darzustellen. Das hatte ich beim Auswerten nicht berücksichtigt.
Wenn jedes Element nur ein Objekt beschreiben würde, hätte ich keine Probleme damit, wenn die Definition von diameter bei Hydranten eine andere ist, als bei Bäumen. Dann wäre klar, dass es sich bei den Hydranten um eine Norm handelt, während es bei Bäumen der echte Außendurchmesser ist. Und auch, dass einmal in Millimeter und einmal in Metern gemessen wird.
Wenn man es so auffasst, wie du, dann ist es eher ein abgeleiteter Schlüssel, (wie area:highway). Muss ich wohl nochmal drüber nachdenken…
Ja. lanes:bus ist die Anzahl der Busspuren, bus:lanes ist der Wert des Attributs bus=* für die einzelnen Spuren (als Liste im Wert). Analog mit zusätzlichem :backward.
Dementsprechend finden sich auch in der Datenbank die passenden Werte (mit ein paar Fehlern im einstelligen Bereich):
Aber von meiner Seite ist das genug zu dem Exkurs, ändert wenig an den Schlussfolgerungen und verwirrend ist es allemal.
Ich weiß nicht, ob ich es überhaupt als Teil einer bestimmten Systematik sehe. Für mich ist das eher so etwas wie crown_diameter. Es könnte auch fire_hydrant_diameter (mit Unterstrich) heißen, ohne dass sich etwas Wesentliches ändern würde. Im Gegensatz zu anderen Verwendungen des Doppelpunkts ist das jedenfalls kein Fall, wo ich als Auswerter den Schlüssel auftrennen und die Teile weiter prozessieren würde.
Ah, danke für die Klarstellung. Das hatte ich wohl überlesen bzw. bis zum Abschnitt mit den Statistiken schon wieder vergessen. Mit den Taginfo-Werten für Deutschland passen deine Resultate auf den ersten Blick gut zusammen.
Umgekehrt ist das aber auch gleichzeitig ein Nachteil. Beim Tagging kann jeder vorangehen und Änderungen vorschlagen, in kleinen Bereichen versuchsweise auch schon mal in der Datenbank umsetzen. Beim Area-Datentyp ist es nur eine kleine Gruppe von Leuten, die wirklich was machen können.
Man kann von außen her natürlich zuarbeiten, Vorschläge machen, Konverter schreiben, etc. Aber letzten Endes gibt es zwei Dinge, die an diesen wenigen Leuten hängen bleiben, und solange sie sich nicht rühren, passiert nichts: Die zwei Dinge sind: a) Einen klaren Entschluss fassen, dass ein Area-Datentyp kommen soll (idealerweise mit Deadline), b) den Wechsel beim Server durchführen.
Im Moment habe ich ein wenig das Gefühl, dass hier “the best is the worst enemy of the better” zutrifft: Es ist klar, dass man nicht all zu oft an der API rumschrauben will und so möchte man möglichst alles in so eine Änderung reinpacken und es perfekt machen. Vielleicht ist das zuviel gewollt. (Vielleicht aber trotzdem sinnvoll, ich kann das nicht abschließend beurteilen.)
Mein Ansatz wäre jedenfalls, zuerst mal nur den Area-Datentyp einzuführen. So etwa:
Die Attribute “outer” und “inner” referenzieren Wege, mindestens ein “outer” muss dabei sein, weitere Beschränkungen gibt es nicht. Das wäre zumindest sehr konsistent mit den vorhandenen Datentypen, erbt aber dadurch natürlich auch die Probleme.
