Hi zusammen,
dieser Thread ist zur Diskussion von Normen in OSM gedacht. Es geht darum, einerseits klare Regeln formulieren zu können und andererseits die Freiheit der Mapper nicht einzuschränken.
PS: Rechnet erstmal nicht mit Antworten von mir. Ich will nicht meine Ideen verteidigen, ich will dass sie verbessert werden und neue Gedanken bekommen. :-))
Ich denke, dass Normen eine wichtige Rolle in OSM spielen könnten, weil sie
Verbindlichkeit und Unverbindlichkeit auf eine Art ermöglichen, die zur
Funktionsweise des OSM-Projektes passen.
Eine Norm im Sinne dieses Beitrags ist eine Vorschrift, die die Bedeutung von
Tags und Roles klar definiert. Diese Vorschrift ist jedoch nur dort
verbindlich, wo sie ausdrücklich genannt wird (Vorschlag: “OSMNORM=nnnn”). Eine
solche Norm muss unveränderlich und dauernd zugreifbar sein, damit jeder
Mapper darauf Bezug nehmen kann und nicht andauernd nachsehen muss, ob sich
da etwas geändert hat. Wenn sie revidiert werden muss, dann wird eben eine
neue Norm gemacht.
Ein Beispiel (siehe jedoch die Anmerkung unten):
Rolltreppen haben meines Wissens keine klar definierte Richtung, es ist also
nicht klar, ob man den Way in Aufwärts- oder Abwärts- oder Bewegungsrichtung
mappen soll. (Wenn ich mich da irre, dann stellt Euch einfach vor, es wäre
anders 
) Der Mapper A macht sie nun immer in Aufwärtsrichtung, der Mapper
B macht sie immer in Abwärtsrichtung. Beide benutzen außerdem noch ein Tag
“movement”, das “up” oder “down” sein kann. Für uns als Leser der Daten
bedeutet das aber, dass wir nun bei keiner Rolltreppe mehr etwas über die
Richtung sagen können, obwohl beide etwas über die Richtung sagen wollten.
Wie helfen hier Normen? Mapper A könnte eine Norm (irgendwo zentral numeriert
und einsehbar) hinterlegen, in der de facto “immer aufwärts” steht. Mapper B
kann das Entsprechende tun. A bekommt die Normnummer 4711, B bekommt die
Normnummer 4712. Jetzt kann A an “seine” Rolltreppen das Tag “OSMNORM=4711”
anhängen und B kann entsprechendes tun.
Bei beiden Mappern wissen wir als Leser jetzt, in welche Richtung die
Rolltreppe geht. Zwischen 4711 und 4712 kann man auch problemlos
konvertieren. Irgendwann wird dann jemand feststellen, dass es auch noch
Rolltreppen mit unbekannter Richtung und wechselnder Bewegungsrichtung
gibt. Er wird dann eine neue Norm machen und man kann die alten Sachen bei
Bedarf problemlos konvertieren.
Editoren könnten aus den Normen entsprechende Menüpunkte bauen und vor
Normverletzungen warnen.
Programme könnten die Einhaltung angegebener Normen prüfen und OSM-Objekte als
definitiv fehlerhaft auflisten.
Renderer könnten unterschiedliche Taggingarten durch Konversionsläufe vor dem
Rendern beseitigen und würden übersichtlicher.
Anforderungen bzgl. Normen:
-
Das Tag mit der Normnummer (“OSMNORM”?) darf nicht für andere Zwecke benutzt
werden. Es darf noch nicht im Gebrauch sein und muss breit als für diesen
Zweck reserviert anerkannt sein. -
Normen dürfen sich niemals ändern und dürfen keine Verweise auf
veränderliche Dinge enthalten.Man würde bei einer Änderung ja die alten Objekte oder deren History
ändern. Allenfalls kann man dranschreiben: “Bitte nicht mehr benutzen”. Auch
wenn das letzte Objekt mit dieser Norm verschwunden ist, sollte es noch
möglich sein, an den Normtext zu kommen, da man ihn für die History
evtl. braucht. -
Normen müssen klar sein. Für jedes erwähnte Tag sollten alle zulässigen
Werte genannt werden und es sollte der Default bei vorhandenem Tag und der
Default beim kompletten Weglassen klargestellt werden. Wo Defaults
zugelassen sind, sollte der entsprechende Wert existieren und angegeben
werden. -
Wer ein OSM-Objekt ändern will und kann das nicht innerhalb der angegebenen
Norm tun, der wirft das Normtag raus und drückt die dabei verlorenen
Informationen anders aus … oder er macht eine neue Norm. -
Wenn eine Norm angegeben ist und nicht eingehalten wird, dann sollte das ein
seltener Fall sein. Daher ist es ausdrücklich erwünscht, dass Bots die
Einhaltung prüfen und ggf. “OSMNORM=nnn” durch “BADOSMNORM=nnn”
ersetzen. Renderer sollten das Objekt entweder ignorieren oder als fehlerhaft
darstellen aber nicht rumraten und das Beste draus machen. -
Eine Norm kann man nicht durch eine “note” oder Ergänzung modifizieren. Man
kann durchaus “note=wie OSMNORM nnn, aber mit …” schreiben, aber
“OSMNORM=nnn” mit “note=jedoch …” zählt nicht. Auch “OSMNORM=nnn Variante”
ist Müll. Kurz gesagt: Wenn “OSMNORM=nnn” dran steht, dann dürfen sich alle
verarbeitenden Programme und natürlich auch alle Mapper brutal daran halten. -
Die Datenbankschnittstelle erhält für Objekte mit “OSMNORM”-Eintrag das
Recht, fehlerhafte Änderungen abzulehnen, sowie explizite
Werte und Defaults gegeneinander auszuwechseln.
Anmerkung:
Das Beispiel ist etwas zu einfach und wohl auch zu einfach dargestellt, aber
ich wollte Diskussionen über Tagging-Problempunkte raushalten. (Hoffentlich
gibt es kein “Rolltreppenwespennest”, in das ich jetzt gestochen habe.)
Als reale Beispiele sehe ich etwa in sich geschlossene Ways mit
natural=water. Dort kann man in einem Fall für jeden Punkt im innern sagen,
dass er im Wasser ist. Wenn der Way jedoch in einer Relation als einziges
outer-Member vorkommt, dann kann man das nicht sagen.
Ein weiteres Beispiel wäre die Role “stop” im Gegensatz zur Role “” bei
Busliniennodes. Einige drücken damit etwas aus (Bushalt in beiden Richtungen,
bzw. in unbekannter Richtung)… andere nicht.
Auch ein solcher Fall sind die Roles der Wege bei Buslinien mit
“type=route”,“route=bus”. Da bedeutet die leere Role. dass der Way in beiden
Richtungen im Gebrauch ist. Ist es jedoch ein Bestandteil der Linie im neuen
ÖPNV-Schema, dann ergeben sich die Richtungen automatisch und werden daher von
vielen Mappern weggelassen.
Nachteile:
Der Leidensdruck durch konkurrierende Taggingarten lässt nach und das könnte
für noch mehr Taggingarten sorgen…
