x

Das Problem mit der Komplexität


Geschrieben von Fabi2 (Gast) am 06. März 2012 21:30:57: [flux]

Wie geht man mit Komplexität in OSM um?

OSM hat ja den Anspruch eine Datenbank über die Realität zu sein. Dazu ist es zunehmend erforderlich, zumindest in Teilbereichen, auch komplexere Zusammenhänge erfassen zu können. Denn früher oder später reicht für einen Anwendungsfall das bisherige Modell garantiert nicht mehr aus, oder jemand möchte einfach zusätzliche Daten erfassen, die er für wichtig hält, und was natürlich möglich sein sollte. Da regliche Relevanzkriterien nur die mögliche Nutzung und Erfassung von Daten einschränken. Soll heißen, wenn sich Leute die Arbeit machen jeden Baum, Gullideckel oder den Betreiber der Hundekottütenspenders zu erfassen, dann ist das auch relevant (Weil wer will das denn sonst wie genau entscheiden?) und wichtig. Den Grad der allgemeinen Nutzbarkeit regelt dann eh die Anzahl der Leute, die das Erfassen und irgendwann wurde immer mal die erste Straße oder der erste Hydrant eingezeichnet.

Das Problem dabei ist nur, das je komplexer das Schema bzw. je schwerer es dadurch ist, weitere Daten hinzufügen bzw. zu korrigieren, um so weniger Mapper werden die Objekte bearbeiten/überprüfen und um so schlechter und älter sind die Daten, sofern sie überhaupt erfaßt wurden. Aus dieser Sicht ist es also sinnvoll, das Erfassen so einfach wie möglich zu machen, wobei es aber auch nicht der Weg sein kann, ein halbgares (wenn nicht heute, dann eben morgen) Schema oder Modell mittels speziellen Editoren durchzudrücken, wo sich später heraustellt, daß man da nciht wirklich drauf aufbauen kann (z.B. Spurerfassung mittels Zusatzstags an einem Weg) bzw. man das Schema eh nur mit Hilfe von Editoren sinnvoll verstehen oder bearbeiten kann und es dann an der Nichtverfügbarkeit der Software für bestimmte Plattformen scheitert. Ich bin der Meinung, das kann eine Hilfe und Arbeitserleichterung sein, aber das sollte nicht die einfache Verständlichkeit und Überprüfbarkeit durch den Menschen ersetzen!

Die andere Sichtweise ist dann, das man einfach bestimmte Informationen erfassen möchte, seinen es nun Fahrspuren, Weichen und Signale, Bürgersteighöhen, die genaue Ausgestaltung von Bojen oder Hydranten oder das tatsächlich vorhandene Fachpersonal von medizinischen Einrichtungen. Dafür braucht man dann ber ein erweitertes Schema und das macht dann unter Umständen auch die ganze Erfassung für den Mapper ohne Hintergrundwissen bzw. ohne Kapazitäten für die Einarbeitung in das verwendete Schema viel zu kompliziert, was dazu führt, das diese und wohlmöglich wichtige Grundinformationen dann üebrhaupt nicht mehr erfasst werden. Andererseits wollen die einen endlich ein Modell auf Spurbasis, statt wie bisher auf Straßenbasis (weil nur so kann man dann perspektivisch an das Erfassen der Bürgesteighöhen und Verläufe denken) und ich z.B. will endlich einen vernüftigen Ersatz für amenity=doctors. So hat jeder seine Ansprüche und fängt an ein Modell dafür zu stricken.

Da kommen dann die nächsten Probleme: Da es ein Modell ist, ist bzw. muß es ja irgendwo begrenzt sein, auch wenn es so genau wie möglich sein sollte, gibt es da durchaus Grenzfälle, spätestens dann wenn sich bestimmte Ereignisse nur schwer vorhersagen lassen, einfach weil sie zum teil auch abhängig vom Zufall sind, sofern man überhaupt eine gute maschinengerechte Darstellung dafür findet. Tendenziell ist aber eine möglichst gutes und genauer Modell aus meiner Sicht zu bevorzugen. Dieses sollte sich dann in der Komplexität frei herunter skalieren lassen, damit der nicht eigearbeitete Mapper zumindest die Grundeigenschaften erfassen kann. Das ist momentan insofern schwierig, als das man für die vernüftige, also erweiterbare und fexibele Darstellung von Zusammenhängen einfach z.B. um Relationen nicht herau kommt. Wie löst man dieses Problem also am besten? Wie macht man das Tagging bzw. Erfassungschema in dieser Hinsicht frei skalierbar, ohne all zu viel Redundanz bzw. Seitenzweige für Sonderfallbehandlungen einführen zu müssen?


Antworten: