Das Problem mit der Komplexität

Natürlich besteht zumindest für mich ein Bedarf, weil sonst würde ich es ja nicht eintragen wollen! Das löst das Problem, wie mnan die Daten nun erfaßt, also leider nicht. Wie willst du denn sicherstellen, das der unerfahrene Mapper dein neues Modell, was natürlich nichts kaputt macht, von dem was schon da ist, auch versteht? Beziehungsweise wie soll er trotz der Existenz der Daten ungestört mappen können?

Kriterien im Sinne von Vorschriften helfen da absolut nicht (z.B. können die Abbiegebeschränkungen und das Spurmapping mich mal kreuzweise, trotdem toleriere ich das diese Daten erfasst werden, kommt also immer auf die Sichtweise an), das wäre nur der Tod für die Weiterentwicklung, da braucht man eine abgestufte Lösung, wo der Mapper sein Schwirigkeitslevel wählen kann.

Nur weil mich das Sortiment vom Aldi interessiert, trage ich es noch lange nicht in die OSM-DB ein. Ebenso möchte ich Routen, die ich mit dem Rad gefahren bin auf einer OSM-Karte visualisieren. Ich trage sie trotzdem nicht in die OSM-DB ein. Warum tue ich das nicht? Nun weil ich der Meinung bin, dass diese Infos nicht in die DB gehören, sondern man diese Infos ruhig extern verwalten kann.

Bevor ich anfange, jeden Pflasterstein als Fläche zu mappen, sollte ich zumindest mal drüber nachgedacht haben, ob dies sinnvoll ist und ob dies OSM weiterbringt oder ob ich nicht lieber eine eigene Datensammlung dafür starte.

Ich möchte ungern zu sehr auf das Spurmapping eingehen, eignet sich aber als Beispiel sehr gut. Wenn ich eine eher harmlose Kreuzung, die man sehr gut mit zwei sich kreuzenden Ways und einem gemeinsamen Node so sehr verkompliziert, dass am Ende zig Abbiegerelationen und ein Wust aus Ways nötig ist, dann sollte ich mich als Mapper schon fragen, ob das OSM nun vorangebracht hat oder eher zurückgeworfen hat. Ein Neuling wird an dieser Kreuzung jedenfalls keine Aktualisierungen mehr vornehmen. Ähnliches auch bei übertriebenen Multipolygonen.

Die Stärken von OpenStreetMap sind meiner Meinung nach die Aktualität durch eine einfache Datenstruktur, die es jedem ermöglicht dort Änderungen vorzunehmen, wo einem ein Fehler auffällt. Wird das Datenmodell irgendwann so komplex, dass viele Mapper dieses nicht mehr verstehen, dann ist OSM in dieser Form erledigt. Weil dann kann man die Aktualität vergessen.

Ob Vorschriften Helfen oder nicht sei mal dahingestellt. Wenn die Toleranz aber dahin führt, dass man die Daten nicht mehr sinnvoll auswerten kann ( das meint neben der Konsistenz auch die benötigte Rechenpower), dann sollte man sich schon fragen ob das noch der richtige Weg ist. Denn was nutzt eine super dolle DB, in der jeder Pflasterstein gemappt ist, wenn man ein ganzes Rechenzentrum braucht, um mit den Daten etwas anzufangen.

Ja, das geht aber nicht in allen Fällen, da braucht man zumindest eien ID in die externe Datenbank und prinzipiell kann man aber alle Lageinformationen von realen Objekten erfassen, und sei es der Ort, wo die Waren in deinem Lieblingsaldi gerade liegen. Ist nur nicht sinnvoll bei einem festen bekannten Sortiment (Nutzwert der Info am konkreten Objekt ist nur für Ausländer und Leute die noch nie in min. 2 verschiedenen Aldi’s waren gegeben) und außerdem wird morgen da vielleicht eh mal wieder umgeräumt und man müßte dann neu mappen. Die persönliche Lieblingsradroute ist ja nicht von Allgemeininteresse, also nutzt die niemandem was in den Ursprungsdaten.

Klar bringt es OSM weiter, weil vorher waren die Pflastersteine ja noch nicht erfasst gewesen und es sind ja in der Realität vorhandenen Objekte, wenn auch nicht unbedingt von größerem Allgemeininteresse, aber so etwas ist eben etwas für Nischenmapper! Schließlich ist ja maxspeed=* auch keine Straßeneigenschaft die mich als Fahrradfahrer interessiert, da sehe ich bestenfalls ein entsprechendes Schild in der Realität heraumstehen, was aber nicht gemappt wird, sondern man richtet allgemeiner nutzbare Daten wie die Straße als weg als solches zu sehr auf den Autofahrer-Anwendungsfall aus, was dann dazu führt, das sie jedesmal gesplittet werden muß, wenn sich gerade mal wieder eine der für Kraftfahrer relevanten Eigenschaften geändert hat.

Da gibts als Beispiel z.B. auch noch den ÖPNV, da ist die Realität auch sehr komplex und vor allem zeigt das Beispiel, das man nicht alles auf ein paar vermeintlich einfache Zusatztags reduzieren kann. Frei nach dem Motto: Hauptsache es funktioniert für Kraftfahrer ausreichend gut, die restlichen Anwendungen müssen dann mit dem für sie nicht passenden Schema bzw. den nicht gemappten, obwohl in der Realität vorhandenen, Objekten leben, deren Eigenschaften sich somit nicht erweitern lassen. Wenn an einer Kreuzung sich z.B. 3x3 Wege in einem Gitter mit passendem Befahrbahrkeitseigenschften schneiden, ist das vielleicht etwas unüberlichtlich, aber leicht nahzuvollziehen und zu ergänzen. Abbbiegerelationen bracuht man dann im Normalfall nicht, denn Wenn man beide Wege am Schnittpunkt nur vorwärts befahren kann, ist doch klar, das man da dann nur entweder rechts bzw. nur links abbiegen kann. Diese sichtbaren und existenten Objekte versteht ein nicht eingearbeiter Mapper eher, als den kunstvoll gestrickten Modellcode für den Parser/Spezialeditor.

Das würde ja heißen man erfasst so komplizierte Sachen wie die Fahrspuren gar nicht erst, weil die Kraftfahrer können ja schließlich aus dem Fenster sehen, die sind also eher für das explizite Mapper der Bordsteinkante für den Rollirouter interessant, für den das ja überhaupt erst die möglichen Strecken im Sinne von highway=* ergibt.

Man müßte über die API oder sonstige Mechanismen eben noch die Detailstufe die man bearbeiten oder abrufen möchte festlegen können. Oder die Editoren müssen das passend aufbereiten bzw. ausblenden, Poitlatch 2 ist da echt ein erster guter Ansatz in die richtige Richtung, da kann jeder Anfänger einen der dort vorhandenen POIs eintragen, ohne das dem erfahreneren Mappern die Möglickeiten durch ein beschränktes Datenmodell genommen werden. Gerade die Rechenpower ist ja auch ein Argument gegen nur abstrakt definierte Wege, ob nun cyclewy=track oder Abbiegespuren am Weg. Da muß man nämlich erst mal das Wegmodell im Rechner generieren, das man sonst fertig vorfinden würde, nur um dann die eigentliche verarbeitung im Anschluß mahen zu könen, und dazu ist es noch nicht mal genau genug, verglichen mit den direkt abgebilderen Objekten aus der Realität. Da erkauft man sich also das vermeitliuche einfachere Mappen durch erhöhten Rechenaufwand.

Losgelöst von dem konkreten Beispiel würde ich das so nicht unbedingt unterschreiben. Was ein Neuling (Gelegenheitsmapper, …) ändern kann, hängt nicht nur davon ab, wie komplizert das Datenmodell ist, sondern entscheidend von den zur Verfügung stehenden Editoren. Dabei muß man dann zwischen einfachen und komplexen Sachverhalten unterscheiden. Es gibt bestimmt viele Beispiele für sachlich einfache Änderungen innerhalb komplexer Sachverhalte. Ein guter Editor könnte hier bestimmt von dem notwendigerweise komplexen Datenmodell abschirmen. Vielleicht wird es in der Zukunft eine ganze Reihe von mobilen Apps geben, die genau das leisten werden – wer weiß?

P.S: In diesem Sinne wäre ein guter Editor, der maximal das Verständnis eines mehr oder weniger komplexen Sachverhaltes erfordert, und nicht auch das Verständnis des möglichweise komplexeren zugrundeliegenden Datenmodells. Letzteres bliebe den Experten vorbehalten.

Wäre natürlich zu überlegen, ob (ähnlich wie bei den Einstellungen von JOSM), es auch für das Mappen einen Anfänger- und einen Expertenmodus geben sollte.

Das kann vielleicht besser über die Datenstrukturen die die API ausliefert gelöst werden, das hätte dann den Vorteil das alle Editoren was davon haben oder man macht eine passende Referenz-lib bzw. gelcih beides. Hauptsachen man denkt überhaupt erst mal üder dieses Problem der Kompexitätsschere nach.

Es gibt doch schon jetzt diesen expertenmodus. Zugang nur für jene welche das Wiki lesen können. Denn das Wissen darüber ist die Vorraussetzung für die Anwendung.
Es gibt nur leider zwei andere Probleme. Unwissenheit schützt die Daten leider nicht.
Und sicher gibt es auch Menschen, welche es zwar gefunden haben, aber ohne es richtig zu verstehen anwenden.

Bei dem Durcheinander sind grundlegende und natürlich nicht zementierte Regeln absolut notwendig.

Das Wiki lesen lesen können, ist eine Sache, der derzeitige Zustand eine andere:

  • Infos zu einem Thema an unterschiedlichen Orten
  • teilweise widersprüchlich / nicht eindeutig
  • Proposals nicht klar genug abgesetzt. Haben IMHO im Wiki für die OSM Bearbeitung nichts zu suchen.

Will da auch mal etwas Senf dazugeben.
Was mich persönlich an unserer Datenstruktur stört und vermutlich auch Anfänger abschreckt, ist das zerhackstückeln von Wegen, aufgrund abstrakter Dinge wie z. B. eine Radroute, die ein Stückchen auf der Straße lang geht, oder Geschwindigkeitsbegrenzungen und Brücken.

Dies könnte durch intelligente Relationen besser gelöst werden. z. B.
relation
type=maxspeed
maxspeed=50
From node 2345
Via way 45678
To node 7654

Wäre sogar abwärtskompatibel, falls ein preprocessor (“butcher.jar” ;)) vor der Weiterverarbeitung die Wege entsprechend zerhackt. Somit könnte jeder nur die für ihn relevanten Relationen auswerten ohne Unmengen an teilweise schwer händelbaren Unmengen an ways in der DB zu haben.
Siehe auch Parallelthreads über Brücken und Spurmapping

Ich fürchte, jetzt hab’ ich ein Fass aufgerissen…

Dafür wird aber das anbringen der entsprechenden Informationen ungleich schwieriger. Was macht denn der Anfänger, der feststellt, dass in der Maxspeed=50 Straße ein Stück 30 ist? Aktuell muss er ‘nur’ den Weg an zwei Punkten spalten (wofür die Editoren doch ganz gut gerüstet sind) und im mittleren Stück den Wert ändern. So wie von dir beschrieben, müsste aber die Relation in zwei Teilrelationen aufgeteilt werden (was nicht nur mit unseren aktuellen Editoren schwer ist, sondern auch theoretisch kein ganz leichtes Problem für den Computer ist) sowie eine weitere Relation anlegen im gewünschten Bereich (gut, dafür wären wären die Editoren dann hoffentlich gerüstet, jetzt sind sie’s nicht) und die Eigenschaften da antragen. Und was ist, wenn Knoten ausgetauscht werden? Oder der Weg aus irgendeinem wichtigen Grund gespalten werden muss? Nein, die Hackstückelei mag nicht immer schön sein, aber ich glaube nicht, dass das wirklich ein Problem für Anfänger ist. Mich hat’s jedenfalls nicht abgeschreckt. Dann lieber den umgedrehten Weg gehen und die kleinen Stücke mit Relationen aneinander ketten. Das ist immer abwärtskompatibel, könnte aber von den Editoren so dargestellt werden, als gäbe es nur ein Objekt, wenn das gewünscht wäre.

Ich denke auch das stört weniger, sollte aber nach Möglichkeit konzeptionell vermieden werden, und ist für Anfänger immer noch besser als sich gleich mit Relationen beschäftigen zu müssen.

Besser und mehr an der Realität ist es aus nmeiner Sicht, gerade bei den ganzen Verkehrszeichen, doch das Schild an sich als Knoten zu mappen und dann dessen Richtung anzugeben. Zum Beispiel mit:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Directional_node

Das ist eine Frage der Unterstützung durch den Editor.

Ich denke, das wird schwierig. Die Zuordnung zum Weg stelle ich mir schwer vor. Und wenn einer das aufhebende Schid nicht einträgt, ist der ganze Planet plötzlich Tempo-30-Zone… Das Modell müsste die Möglichkeit bieten, von… bis … darzustellen. Daher meine Idee mit den nodes in einer Relation.

Dieser Vorschlag ist mir sehr sympatisch. Ich hatte ihn in ähnlicher Weise auch schon geäußert. Allerdings wollte ich nur Relationen von Punkten. Wege sind ja auch nichts anderes. Das hatte aber damals keinen Anklang gefunden, weil es die Datenmenge aufblähen würde. Außerdem würde es die Keys von den Objekten trennen, was sehr viel Vor/Nacharbeit von den Editoren verlangt. Wenn das aber im Zuge von Spurmpping sowieso gemacht werden müsste, warum nicht?
Deine Beispiele könnte man übrigens noch weiter fortsetzen. Wenn sich zum Beispiel die Kategorie der Straße ändert.

Intelligente Realtionen sind ein sehr guter Vorschlag! Ich würde an dieser Stelle gleich eine Wiki Seite in der man diese Idee ausbaut und weiter spezifiziert anlegen.

Was die Idee “da braucht man eine abgestufte Lösung, wo der Mapper sein Schwirigkeitslevel wählen kann” angeht, wollte ich in Garching das Konzept der Level of Details vorstellen, bei der es fünf verschiedene Levels gibt. Wie man´s integriert bekommt ist eine andere Geschichte…

:confused: Das funktioniert sicher, wenn ein way betroffen ist. Wenn aber mehrere ways zusammengefasst z.B. diese maxspeed erhalten sollen, was z.B. bei Spurmapping sinnvoll ist, funktioniert das nicht mehr, weil mehrere from/to/via anfallen. Komma-separated ist sicher keine Lösung.

Das ist eine Relation. Man muss hier nicht bei einem via Weg aufhören. Vielleicht verwechselst du das mit den Abbiegebeschränkungen.

Das Problem was ich aber sehe ist, das der Präprozess künstlich aufgebläht wird. Denn wenn man einfach einen “Weg” über den Weg zeichnet an dem die Eigenschaften gelten, dann weiß der nachfolgende Prozess gleich welche Knoten betroffen sind und braucht sie nicht über ein “Routing” herausfinden.
Denn es wäre ja auch möglich die from to in verkehrter Richtung anzugeben. (engegen der Wegrichtung)

+1

Wie sieht es da eigentlich mit der 3D Geschichte aus?
http://www.openstreetmap.org/?lat=53.9639&lon=11.0601&zoom=14.

Wäre es nicht möglich, die 3D Geschichte in einer getrennten Datenbank, die auf die ‘normalen’ OSM Daten zurückgreift, zu führen, um das Datenvolumen in Grenzen zu halten.

BTW, bin absoluter Datenbanklaie

Bei manchen 3D-Informationen ist das tatsächlich ein vielversprechender Ansatz und einige 3D-Entwickler überlegen auch schon, so etwas in Gang zu bringen. Das wäre dann aber für z.B. detaillierte texturierte 3D-Gebäudemodelle gedacht. Wenn es nur um einige zusätzliche Tags - z.B. height und roof shape - an einem ohnehin eingezeichneten Gebäudeumriss geht, dann steht der Aufwand für eine gesonderte Datenbank und die Verknüpfung zwischen OSM und dieser Datenbank in keinem vernünftigen Verhältnis zu Art und Umfang der Daten.

Speziell die in deinem Beispiel verwendeten 3dr:* Tags sind natürlich sehr fragwürdig, weil sie kryptische Nummern verwenden, die keiner ohne Wiki-Studium versteht. Das kann man aber leicht beheben, indem man stattdessen einen der alternativen 3D-Taggingvorschläge mit menschenlesbaren Werten verwendet. Mit einem mapperfreundlich gestalteten Proposal kann man generell schon viel zur Reduzierung der Komplexität tun.

Man könnte vieles. Es ist nur eine Frage der Sicherheit. In der OSM Datenbank ist jedes Objekt eindeutig mit einer ID versehen. Über diese ID kann man jetzt die Objekte zweifelsfrei zu ordnen. Soweit so schön.
Wenn aber jemand des Weges kommt und meint der Gebäudegrundris gefällt mir nicht, ihn löscht und neu erstellt, dann gibt es eine neue ID. Schade um die Arbeit.
Das gleiche trifft auf zusätzliche Geometrien zu. Wenn in der OSM Datenbank wirklich nur der Grudriss ist, dann zerstört schon eine Verschiebung oder anderweitige Veränderung daran zu einem völligen zerstören des 3D Objektes.
Das ist ungefair genauso, wie wenn du straßen/Punkte in Bereichen löschst die nicht vollständig runtergeladen sind. Du siehst nicht ob weitere Objekte davon abhängig sind. Relationen und Überrelationen sind genau solche Probleme und die sind schon in der selben Datenbank. Es ist also alles eine Frage des Editors dich davor zu bewahren/warnen.