FOSSGIS 2024/OSM-Samstag/Ergebnisse/Was gehört nach OSM?

Bericht von der Session "Welche Daten gehören nach OSM und welche nicht?"

Ausgangsfrage: OpenStreetMap ist nicht nur eine lose Sammlung von Daten, wir arbeiten gemeinsam an einer gemeinsamen Datenbasis. Wir können nicht alle Daten sammeln, nicht mal alle Geo-Daten. Manche Daten dürfen wir vielleicht nicht haben, andere wollen wir nicht haben. Aber welche Daten wollen wir denn? Was macht OSM überhaupt aus?

Als Beginn einer Diskussion, welche Daten eigentlich nach OSM gehören und welche nicht, haben wir während der Session eine lange Liste von Kriterien gesammelt, nach denen wir so eine Entscheidung treffen würden. Dabei ging es erstmal darum eine möglichst breite Liste von möglichen Entscheidungsfaktoren zu sammeln, nicht darum die einzelnen Faktoren zu bewerten oder zu gewichten, das soll dann in weiteren Schritten passieren. Die Diskussion zu dieser Frage beschäftigt uns schon so lange, wie es OSM gibt. Daher ist es auch kein Wunder, dass ganz viele Aspekte genannt wurden. Hier soll der Versuch gemacht werden, die während der Session teilweise "durcheinander" vorgebrachten Kriterien, in eine halbwegs sinnvolle Ordnung zu bringen. Ich hoffe ich habe dabei keine wichtigen Aspekte übersehen.

Rechtliche Fragen

Natürlich müssen wir beim Mappen rechtliche Gegebenheiten berücksichtigen. Grenzen zu dem, was wir eintragen dürfen, liegen vor allem beim Schutz persönlicher Daten und beim Schutz der "nationalen Sicherheit", zum Beispiel bei militärischen Einrichtungen.

Das Thema ist natürlich sehr kompliziert, weil bei einem internationalen Projekt, ggf. die Gesetze von vielen Ländern zu berücksichtigen sind. Gerade auch beim Zeichnen von Ländergrenzen gibt es in einigen Ländern rechtliche Vorschriften, die denen anderer Länder widersprechen.

"Moralische" Fragen

Nicht alles, was wir rechtlich gesehen eintragen dürfen, sollten wir auch eintragen. Wir müssen uns immer wieder fragen, ob der Eintrag möglicherweise mehr Schaden anrichtet als Nutzen bringt. Da natürlich Nutznießer und Geschädigte verschiedene Leute sein können entsteht hier ggf. ein Konflikt. Hierbei sollten wir dann auch an den gesellschaftlichen Nutzen und nicht nur an den Nutzen für den Einzelnen denken.

Paradebeispiel ist der Horst eines seltenen Raubvogels. Der potentielle Schaden, z.B. durch Eierdiebe, ist enorm. Ein möglicher Nutzen, zum Beispiel für Naturbeobachter, steht hier in keinem Verhältnis. Ein positiver Nutzen könnte sein, beim Routen Wege in der Nähe des Horstes zu vermeiden, aber das ließe sich vielleicht besser durch die Ausweisung eines Sperrgebietes erreichen, das keinen direkten Hinweis auf die Position des Horstes gibt.

Hierbei zu berücksichten ist auch die Frage, ob ein Eintrag eines grundsätzlich nicht "geheimen" Faktums in einer Datenbank zu einer anderen "Qualität" der Information führt, wenn solche Daten massenweise erfaßt werden. "Blitzer" am Straßenrand können in der Regel gesehen werden, es ist kein Geheimnis, dass sie da sind. Aber wenn man alle "Blitzer" in einer Datenbank hat, dann kann man sein Risiko beim Zu-Schnell-Fahren erwischt zu werden deutlich reduzieren, was vielleicht nicht im Sinne der Allgemeinheit ist.

Zu diesem Thema passt vielleicht auch die Frage, in wie fern wir "kritische Infrastruktur" mappen, zum Beispiel Pipelines. Hier gibt es immer wieder Angst vor terroristischen Angriffen oder dergleichen. Allerdings sind solche Daten inzwischen vielfach eh als offizielle Daten verfügbar und der Nutzen für die Allgemeinheit, Zugriff auf diese Daten zu haben, ist zu berücksichtigen.

Grundsatzfragen

Bei OSM geht es in erster Linie um "Geodaten", also Daten, die einen Raumbezug haben. Hat etwas keinen Bezug zum Raum, so gehört es wohl nicht nach OSM. Aber sehr viele Daten haben ja irgendwo den Raumbezug. Es ist klar, dass ein Restaurant in der Regel an einen festen Ort gebunden ist. Aber schon die Telefonnummer des Restaurants hat ja nur indirekt diesen Raumbezug. Dinge, die bei OSM eingetragen werden, sollten diesen Raumbezug haben, aber nicht alle Attribute eines solchen Dings haben unbedingt den Raumbezug. (Beispiel: Etymologie von Straßennamen.) Wo ist hier die Grenze?

Ist der Geobezug gegeben, stellt sich als nächstes die Frage nach der "Wichtigkeit" von den Daten. Anders als in der Wikipedia, bei der die "Relevanz" eine große Rolle spielt, erlauben wir eine Menge Daten in OSM, von denen erstmal nicht klar ist, wie "wichtig" sie sind und für wen oder was. Trotzdem kann die "Wichtigkeit" der Daten für die Allgemeinheit eben doch ein Kriterium sein. Daß da irgendwo eine Straße ist und kein See ist allgemein doch wichtiger als die Frage, ob man auf der Straße 50 oder 80 fahren darf. Und das wiederum ist für die meisten User doch wichtiger, als die Höhe des Baumes neben der Straße. Nicht jeder User wird die Einordnung der "Wichtigkeit" gleich vornehmen, aber vielleicht spielt sie ja schon eine Rolle für das Projekt.

Auf jeden Fall wird es immer Grenzen dessen geben was in OSM erfaßt werden kann. Wann ist etwas noch allgemein wichtig und wann zu (fach-)spezifisch? (Beispiel: alle Bäume eines Waldes mit je 200 Attribute erfassen, wie es ein Förster vielleicht braucht?). Sollen wir uns auf eine "Kernkompetenz" beschränken (nur Daten, die von "öffentlichem Interesse" sind?) oder alles zulassen? Gibt es eine Liste von Daten, die wir gemeinsam für besonders wichtig erachten? Wird die Pflege "wichtiger" Daten schwieriger, weil mehr und mehr "unwichtige" Daten beigetragen werden? Wie wichtig ist die "Wichtigkeit"?

Die Detailfrage

Nirgends klar definiert ist auch die Frage, mit welchem Detail wir Daten erfassen wollen. Bei manchen Dingen, die sich zum Beispiel schnell ändern, macht eine Detailerfassung weniger Sinn, man denke an die Flußmündung, deren Verlauf sich ständig ändert, je nachdem wo Ebbe und Flut und die Strömung des Flusses die Sandbänke hin- und herschiebt. Wir sehen aber auch einen Trend zu immer mehr Detailmapping, das neue Nutzungen ermöglicht (Fußgängerrouting) und andere dafür aber möglicherweise schwieriger macht. Hier werden Abwägungen nötig sein. Dürfen neue Daten alte Daten nicht nur ergänzen, sondern auch mal "kaputt machen", um ein besseres (?) System umzusetzen?

Häufig aber nicht notwendigerweise verbunden mit der Detailfrage ist auch die Frage der Pflegbarkeit der Daten. Wie wird man die Änderung der mittleren Packeisgrenze erkennen und die Daten nachführen? Sind es vielleicht zu viele Daten, dass die OSM-Community eh nicht hinterher kommt sie zu pflegen? Wie wirkt sich die Komplexität der Daten auf die Pflegbarkeit aus?

Hierzu auch: Auseinanderhaltung von "Randschärfe und Kernprägnanz".

Fakten / on the ground rule

Viele Portale im Web erlauben es jedem irgendwelche Kartendaten einzutragen oder hochzuladen, z.B. das auch vom FOSSGIS betriebene umap. Sowas ist großartig für den Anfahrtsplan einer Veranstaltung oder sowas. Und jeder kann in seiner Karte das eintragen was er will. Aber OSM ist etwas anderes als diese Dienste. Bei OSM geht es darum, dass wir gemeinsam an EINER Datenbasis arbeiten und nicht jeder seine Sicht der Dinge hat.

Letztlich müssen sich die verschiedenen Mitglieder der Community, die in einem Bereich mappen auf eine Sicht der Welt "einigen". Das braucht manchmal etwas Zeit und die Sicht kann auch in der Zukunft wieder geändert werden. Aber es braucht doch eine gemeinsame Sicht. Die wird über die "on the ground rule" vermittelt: "Wenn wir vor Ort stehen würden, was würden wir sehen und was draus machen? Es geht also um einen (meist) fiktiven Vorgang, der sich aufdie lokal vorhandene Realität bezieht. Die geht vor "offiziellen" Quellen und vor der Sicht "aus der Ferne" (wie sie zum Beispiel ein Luftbild vermittelt) und bezieht auch die Sicht lokaler Mapper mit ein.

Es geht also erstmal darum, Fakten über die Welt einzutragen, die objektiv vorhanden sind. Natürlich gibt es hier einen Graubereich und Interpretationsspielraum, nicht nur bei Tags wie "smoothness".

(Hier spielt auch die Frage des "Tagging for the renderer" mit hinein, also die Frage, in wie weit wir theoretische Konzepte mappen und in wie weit wir etwas für spezifische Nutzungen eintragen. Das ist zwar recht verpönt im Projekt, wird aber doch häufig getan, weil wir uns ja auch an den Nutzungen orientieren und mit neuen Nutzungsarten uns auch weiterentwickeln. OSM ist ja gerade nicht als geplante, durchdachte Datenbank entstanden, sondern entwickelt sich anhand der in der Praxis auftauchenden Probleme immer weiter und das führt dann auch schonmal zu technischen und organisatorischen Krücken, die halt das "im Moment Machbare" dem theoretisch Überlegenen vorziehen.)

Dieses faktenbasierte Mapping ist auch ganz wichtig für die Lösung bzw. das Vermeiden von Konflikten und allgemein um das Projekt zusammenzuhalten.

Weitere Frage in diesem Bereicht:

• Lokale Sicht vs. globale Einheitlichkeit
• Was ist mit strittigen Grenzen?
• Klassifizierung ist immer auch mit der Sicht des Nutzers verbunden (ob eine Strecke für Radfahrer geeignet ist, hängt davon ab, ob das ein Rennradler ist, ein Moutain Biker oder ein Rad mit Kinderanhänger, ...)
• In wie weit geht "Allgemeinwissen" in die Karte ein. Vieles "da draußen" hat zum Beispiel einen Namen, aber der steht nirgends an einem Schild.
• Welche Quellen werden als "korrekt" anerkannt, wo Fakten lokal nicht erkennbar sind (z.B. Grenzen)? Oft ist die Quelle einer bestimmten Information nicht zu erkennen, sodass eine Einschätzung der Richtigkeit durch andere Mapper erschwert wird.
• Sind "offizielle" Quellen etwas besonderes für uns? (Beispiel: Nicht vor Ort ausgewiesene Wanderrouten, wie es sie in einigen Ländern gibt.)
• Wie lassen sich Kriterien für überprüfbare Informationen definieren, wenn vor Ort nichts zu sehen ist (Gesetze, Verordnungen, lokaler Gebrauch ...)?

Technische Fragen

OSM erfaßt derzeit zwei Arten von Daten: GPS-Tracks als "Rohdaten" und die eigentliche OSM-Datenbank mit Nodes, Ways, und Relations. Technisch gesehen gibt es viele Einschränkungen, welche Daten mit der derzeitigen Technologie sinnvoll erfaßt werden können.

Derzeit nicht für die OSM-Datenbank geeignet sind zum Beispiel:

• Höhenmodelle
• Luftbilder
• "Street View" Photos
• Lidar-Daten
• Meßdaten, ggf. mit Zeitachse (Lufttemparatur, Autos pro Stunde auf einem Straßenabschnitt, ...)
• Fahrplandaten
• Life-Daten (Staumeldung)
• Historische Daten

Es ist durchaus denkbar, dass das OSM-Projekt in Zukunft auch andere Daten erfaßt und dafür entweder das Datenmodell ändert oder weitere Datenbanken mit anderen Datenmodellen bereitstellt. Aber diese Überlegung sprengt den Rahmen hier. Hier soll es um die derzeit existierende OSM-Datenbank gehen.

Zu den eher technischen Themen gehört auch die Frage, wie Dinge so erfaßt werden können, dass zusätzliche Details die Nutzung "gröberer Daten" nicht beeinträchtigt. Würden wir die Straßen beispielsweise nicht als Linien erfassen sondern als Flächen, würde das manche Nutzungen der Daten vereinfachen oder erst möglich machen, aber viele andere Nutzungen (Routing, ...) erheblich schwieriger machen. Gibt es keine Möglichkeit mehrere Ansichten zu vereinigen, so muss ggf. eine Nutzungsmöglichkeit zurückstehen. Wie kann man sowas Priorisieren?

Auch die Komplexität der Daten überhaupt ist mehr und mehr ein Problem. Wenn alles mit allem zusammenhängt und jede kleine Änderung zu vielen weiteren Änderungen führt, dann wird es immer schwieriger mit den Daten zu arbeiten. Welche Daten wir in OSM haben wollen hängt auch mit dem Datenmodell und den Tools zusammen.

Verbindung zu anderen Daten

Eng verbunden mit der Frage, ob Daten grundsätzlich und technisch für OSM geeignet sind, ist die Frage, ob man die Daten ggf. mit anderen Daten verbinden kann. Nicht alles muss in OSM sein, wenn es schon woanders eine Datenquelle gibt, die man ggf. mit anzapfen kann.

Das verknüpfen von Daten ist aber in der Praxis häufig recht kompliziert. Wie wird verknüpft? Über eindeutige Ids? Was ist bei Änderungen? Was ist wenn die Daten nicht zusammenpassen? Sind Tools vorhanden, die die Verknüpfung erlauben?

Bei einer Entscheidung, ob Daten eher in OSM erfaßt oder extern gehalten werden sollen muß auch eine Abwägung getroffen werden, wie kompliziert es ist die externe Quelle einzubinden und wie viele User dadurch einen höheren Aufwand haben. OSM soll als Datengrundlage auch alleine stehen können, zumindest für die wichtigsten Anwendungen. Diskussionen gab es dazu zum Beispiel schon bei der Frage, ob man Übersetzungen von Ortsnamen nicht besser aus Wikidata zieht. Gerade für neue Projekte soll es keine zu hohe Schwelle bei der Datennutzung geben. Wie wichtig ist es, dass OSM für sich alleine stehen kann?

Und schließlich stellt sich auch die ganz praktische Frage, wo denn der andere Ort ist, an dem die Daten erfaßt werden können. Wenn es einen solchen Ort nicht gibt, dann ist der Druck hoch, die Daten bei OSM zu erfassen, selbst wenn eine Spezialdatenbank dafür theoretisch besser wäre.

Die Zeitachse

Die Welt da draußen verändert sich ständig. OSM soll die Welt so wiedergeben, wie sie "derzeit" aussieht. Dazu stellen sich aber verschiedene Fragen:

• In wie weit sollen historische Daten erfaßt werden? Hierbei muss man unterscheiden zwischen Dingen, die mal waren und nicht mehr sind und Dingen, die mal waren und von denen noch Reste erkennbar sind. Eine ehemalige Römerstraße, von der nichts mehr zu sehen ist, ist vielleicht etwas anderes als eine, die zwar keine Straße mehr ist, aber wo man vor Ort noch Aufschüttungen und Einschnitte im Gelände erkennen kann. Eine ehemalige Burg wird ggf. nicht als solche erfaßt, sondern als Ruine, weil sie das eben heute ist.
• In wie weit soll die Zukunft berücksichtigt werden? Wie gehen wir mit geplanten Änderungen der Welt um oder mit Änderungen, die gerade passieren (Baustellen)?
• Wie gehen wir mit vorübergehenden Änderungen (Sperrung einer Straße wegen Bauarbeiten, Jahrmarkt und dergl.) um? Abzuwägen sind hier ggf. der Aufwand beim Ändern und Wiederherstellen der Daten und die Frage wieviele Nutzer letztlich von den Änderungen profitieren, wenn sie nicht immer aktuelle Daten nutzen.
• In aller Regel tragen wir bei OSM nur statische Dinge ein: Häuser ja, Autos nein. Das Auto kann ja jeden Moment wegfahren. Aber es gibt einen Graubereich: Was ist mit dem Museumschiff, dass zwar theoretisch bewegt werden kann, aber eigentlich immer an der gleichen Stellen im Museumshafen liegt? Was ist mit einem Fluß der ständig seinen Lauf ändert?

Fazit

Wie geht es jetzt weiter? Der Plan ist bei einer Folgeveranstaltung das Thema weiter zu diskutieren und schrittweise einer gemeinsamen Darstellung näher zu kommen. Wann das passieren wird, ist noch nicht klar. Einstweilen wäre es hilfreich, wenn wir Diskussionen zu diesen Themen hier verlinken und auch Beispiele hier sammeln, wo schonmal in konkreten Fällen diskutiert wurde, ob etwas zu OSM passt oder nicht.

Vielen Dank an Sarah Hoffmann für den Mitschrieb dieser Session, auf dem dieser Text basiert.

Links

Hier bitte Links zu Diskussionen oder Beispielfällen ergänzen:

• ...