[Talk-de] Alte Straßenbezeichnungen für die Zeit des 3. Reiches

[Tobias Knerr]

Andre Hinrichs schrieb:
> Am Donnerstag, den 19.11.2009, 17:57 +0100 schrieb Tobias Knerr:
>> Andre Hinrichs:
>>> Wie wäre es mit einer Relation?
>>>
>>> type=historic_name
>>> name=Kaiser-Wilhelm-Platz
>>> start_date=yyyy-mm-dd
>>> end_date=yyyy-mm-dd
>>>
>>> Auf diese Weise würde die Anzahl Schlüsselworte nicht ins unermessliche
>>> wachsen.
>> Dafür ist es viel schwieriger einzutragen und kein Mapper, der nicht mit
>> Relationen umgehen kann (häufig genug), ist in der Lage, irgendwas an
>> den betroffenen Straßen und Plätzen zu ändern. Dazu kommen natürlich
>> noch weniger anschauliche Versionsgeschichten und dergleichen
>> Unannehmlichkeiten.
> 
> Das sehe ich etwas anders. Sicher ist die Eingabe und die Verwaltung von
> Relationen schwieriger als die Eingabe von Tags. Dennoch wird jemand,
> der die dann doch komplizierten Tags wie
> old_name:startyeart-endyear=blabla versteht auch in der Lage sein,
> Relationen anzulegen.

Es geht nicht nur ums Anlegen, sondern vor allem ums Lesen. Ein
old_name:1935-1945 versteht meiner Ansicht nach nahezu jeder. Zumindest
jeder, der "old_name" versteht.

Die Relation hingegen ist nur solange "unsichtbar", wie der Benutzer
* einen Editor verwendet, der keine Mitgliedschaften in Relationen
anzeigt und
* nicht auf die Idee kommt, die Straße auch tatsächlich in größerem
Umfang zu bearbeiten. Ein Klick auf z.B. "Weg teilen" reicht, um mit der
Existenz der Relation konfrontiert zu werden - und zudem noch mit der
Entscheidung über deren künftiges Schicksal.

> Sicher ist die Einführung von Gruppen eine interessante Sache. Jedoch
> ist eine Relation im Grunde nichts anderes als eine Gruppe. Wieso also
> etwas Neues einführen, was es in anderer Form bereits gibt?

Weil es oft besser ist, ein Konstrukt zu haben, das *weniger* kann als
ein anderes. Aus ähnlichen Gründen, aus denen ein Nutzer oft ein
Programm mit weniger Knöpfen und Funktionen, das speziell auf seinen
Anwendungsfall passt, einem komplexen Alleskönner vorziehen wird.

Prinzipiell könnten wir auf Ways beispielsweise verzichten. Ein Way kann
schließlich nichts, was eine Relation nicht auch kann: Tags tragen und
eine geordnete Folge von Nodes enthalten - kein Problem. Trotzdem sind
Ways sinnvoll: Man kann sie wegen ihrer Einschränkungen nämlich
anschaulich darstellen, als Linie auf einer 2D-Oberfläche. Mit
allgemeinen Relationen geht das nicht. Allgemeine Relationen kann man
nur mit einem Monster wie dem JOSM-Relation-Editor vollständig wiedergeben.

Man sollte nebenbei bemerkt auch nicht unterschätzen, dass man ein
einfaches Konstrukt wesentlich verständlicher beschreiben kann.
Relationen werden ja oft als "Beziehung zwischen Objekten" erklärt -
trifft es aber leider überhaupt nicht mehr, wenn damit jetzt Tags von
einem Einzelobjekt ausgelagert werden sollen.

> Oder gibt es
> irgendeine Anwendung eine Gruppe, die nicht mit Relationen gemeistert
> werden kann?

Nein. Relationen sind mächtig genug, um eine komplette relationale
Datenbank, ein objektbasiertes Datenmodell oder so ziemlich alles andere
abzubilden. Du kannst du mit Relationen *alles* machen, so lange es
nicht benutzbar sein braucht.

>> Allerhöchste Priorität
>> hat die einfache Handhabbarkeit durch Mapper. Und die ist bei Relationen
>> einfach nicht gegeben.
> 
> Stimmt nur zum Teil. Wenn wir jetzt sagen, dass Relationen zu
> kompliziert sind für die Nutzer, dann müssten wir auch alle anderen
> Anwendungsbereiche für Relationen durch normale Tags ersetzen.

Könnte man nicht einfach Relationen überall dort durch Tags ersetzen, wo
das sinnvoll möglich ist? Es muss ja nicht gleich auf
Alles-oder-nichts-Entscheidungen hinauslaufen.

Übrigens glaube ich sogar, dass die drei Konstrukte
* Tag-Gruppe
* Tag mit anderem Objekt als Wert (letztlich Member für Ways und Nodes)
* Route (= zusammenhängende Folge von Wegstücken)
so ziemlich alle Anforderungen abdecken könnten und für sich jeweils
weitaus anschaulicher darzustellen wären als eine allgemeine Relation.

Tobias Knerr