[Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Sarah Hoffmann]

On Mon, Jul 09, 2012 at 11:51:13PM +0200, Christian Müller wrote:
> Am 09.07.2012 21:47, schrieb Frederik Ramm:
> > Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben
> > nicht.
> 
> Genau das ist der Punkt.  Schmeißen wir die Relationen weg, verprellen
> wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es
> Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren
> Elementen nur noch in der Relation auftauchen.

Kannst du konkrete Beispiele nennen von Anwendern, die irgendeiner Relation
ausser den drei wirklich gebrauchten (Routen, Abbiegerelation,
Multipolygon) nachweinen würden?

Wie Jochen bereits gesagt hat, muss man für die meisten Sachen den
Fall ohne Relationen ohnehin implementieren, weil es dieser Fall
immernoch der häufiger gebrauchte ist.

> Mich hat bisher kein einziges Argument gegen Relationen überzeugt. 
> Einzig evtl., dass sie schlecht gepflegt sind - das gilt aber auch für
> den restlichen OSM-Datenbestand.  Ich sehe z.B. immer wieder nicht
> verbundene Nodes, versehentlich verschobene, etc.

Relationen sind wesentlich leichter versehnlich kaputt zu machen als
Nodes, Wege und Tags, weil sie unsichtbar im Hintergrund herumlungern
und man nicht sofort sieht, dass man da etwas ändert. 

> Ich kann auch Sarah's Argumenten nicht folgen, dass OSM eine rein
> spatiale DB ist.  Es ist ein Mix - whatever works entscheidet, wer wie
> etwas modelliert.  Natürlich bedeuten diese Freiheiten Komplexität in
> der Auswertung - das ist aber imho dennoch weniger Aufwand, als alle zu
> zwingen, einheitlich zu mappen.  Ein Einwirken auf jeden der dann nach
> Überlegung "falsch" mappt, wird denjenigen die Lust am Mappen verderben.

Wenn du dir zuviel dieser "Freiheiten" herausnimmst, schränkst du
gewaltig die Freiheiten der anderen Mapper ein. Siehe oben. Relationen
sind in erster Linie ein Hindernis für deine Mitmapper. Es geht nicht
darum, 'einheitlich' zu mappen, es geht darum, das ganze so einfach wie
möglich zu halten, damit es für alle verständlich bleibt.

Ausserdem sind Relationen ein Motivationskiller, wenn es darum geht 
Fehler zu korrigieren. Wer mag schon einen Weg anfassen, der Mitglied 
in 15 Relationen ist. Ein Weg mit 15 kryptischen Tags ist zwar auch 
ein bisschen lästig, aber normalerweise kann man die Tags einfach 
ignorieren, frei nach dem Motto 'leben und leben lassen'.

> Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und
> der gleiche geografische Sachverhalt eben vielfältig modelliert werden
> kann.  Warum begreifen wir das nicht weiterhin als Chance?  Warum wird
> stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten
> gesucht, wie es Knoten und Weg nunmal sind?

Geografische Sachverhalte sollte man über Geometrie ausdrücken und
nicht durch irgendwelche künstlichen Strukturen. Natürlich könnten
wir für jede Bushaltestelle eine Relation erstellen, die besagt, ob
sie jetzt rechts von der Strasse liegt oder links. Aber was ist der
Sinn? Diese Information ist bereits in der DB, das heisst die Relation
bringt absolut nichts.

> Relationen sind auch dort, wo eigentlich alles auf dem Weg getaggt
> werden könnte, eine sinnvolle Ergänzung, z.B. um die Übersichtlichkeit
> zu bewahren und die Pflege zu vereinfachen.  Sie können evtl. 50+
> Übersetzungen halten, während die bsp.-haften, sechs zugehörigen Wege
> nur den regional üblichen Namen halten.  Auch mit Lookup-Tables/LUT
> versagt irgendwann der minimalistische Ansatz.  Je nachdem, wieviel
> Information über eine Menge von Wegen oder Knoten gehalten werden soll. 
> Auch wenn LUT evtl. in einigen Software-Projekten anzutreffen sind und
> dort eine Tag-Redundanz erfolgreich wegoptimieren, sind sie kaum
> dokumentiert und die Art ihrer Implementierung variiert.  Die Live-DB,
> die Live-Toolchain verwendet sie nicht.  Zudem wird mit der Auslagerung
> von Tags in LUT auch nichts anderes als eine Relation geschaffen, halt
> nur nicht vom Menschen.

Jetzt wirfst du irgendwelche technischen Begriffe in den Raum ohne
dir wirklich mal einen Kopf gemacht zu haben, wie das ganze eigentlich
funktioniert. Redundanz in den Tags ist bisher einfach kein grosses Problem 
gewesen. Die Art und Weise wie Datenbanken das handhaben, ist effizient 
genug. Wir haben ganz andere Ecken, wo wir ernsthafte Probleme mit der
Effizienz bekommen. In erster Linie bei der Berechnung der Weggeometrien
und dem Node-Lookup. 

> Da die Daten, wie die Softwareprojekte drumrum vermutlich nie perfekt
> sind, ist das mehr an Information und evtl. auch Redundanz eine Chance,
> gute QM-Tools zu bauen.  Am Beispiel der Bundesstraßen z.B. könnte man
> die Argumente derjenigen aufgreifen, die meinen
> 
>     "man könne den Verlauf der Bundesstraße auch programmatisch anhand
> des ref= zusammenbauen und braucht die Relation gar nicht"
> 
> und gegen das prüfen, was manuell gepflegt wird.  In der Summe ergibt
> das eine gewisse Robustness gegen die Fehler, die man beim Mappen machen
> kann:
> 
>     - versehentlich Relation beschädigen
>     - versehentlich ref löschen

Du argumentierst hier gerade gleichzeitig, dass wir Relationen brauchen,
um Redundanz zu vermeiden und um Redundanz zu haben. Was nun?

Aber nur um des Argumentes willen: dein QA-Tool würde genau die gleichen
Algorithmen verwenden, um die Bundesstassen zu prüfen, wenn diese in
Relationen stecken, wie wenn sie ein ref-Tag haben. Der einzige
Unterschied ist, wie man die Wege ermittelt, die zur Bundesstrasse
gehören: entweder alle Member der Relation oder alle Wege in 
Deutschland mit ref=was-weiss-ich. Beides simple Abfrage und das
kleinste Problem für dein QA-Tool. Nutzen der Relation: null.

Der einzige Grund, Bundesstrassen in eine Relation zu stecken wäre,
dass es Wege gibt über die mehrere Bundesstrassen gleichzeitig
verlaufen. Dann müsste man bei Tags auf unschöne Listen zurückgreifen.
Soetwas hat es in der Schweiz und den USA, aber in Dt. gibt es das, soweit 
ich weiss, nicht.

> Es ist unwahrscheinlich, das beides zeitgleich passiert.  Gäbe es
> hingegen eine explizite Relation nicht, würde ein Fehler durch ein
> fehlendes "ref" Tag am way nicht auffallen - allein auf die Heuristik
> "alle Wege, die sich einen Knoten teilen" zu bauen, ist weltfremd und
> idealisiert imho viel zu stark.  Hier wünscht sich der Informatiker die
> Welt herbei, wie sie sein sollte.  Beispielsweise ist der Verlauf von
> Landesstraßen heute vielfach in Teilabschnitten durch Bundesstraßen
> ersetzt worden und dadurch fragmentiert.  Weiterhin sehe ich nicht ein,
> weshalb, nur weil es für Routing und Rendering abkömmlich ist, auf den
> exotischeren Anwendungsfall "wieviele Goethestraßen gibt es in X"
> verzichtet werden sollte, wenn er mit etwas Grips und gutem Willen in
> der DB ohne viel Zauber und Zusatzarbeit modellierbar ist.  

Weil er mit noch viel weniger Zauber und Zusatzarbeit aus der DB zu
holen ist. Nehmen wir mal eine osm2pgsql-DB. Dann würde das etwa so
aussehen:

SELECT ST_NumGeometries(ST_LineMerge(w.way))
	FROM planet_osm_way w, planet_osm_polygon p
 WHERE p.name = 'Deutschland' AND w.name = 'Goethestrasse'
   AND w.highway is not null
	 AND ST_Within(w.way, p.way);

Das war ein 5-Zeiler, den ich in drei Minuten zusammengeschrieben
habe und der dir eine recht gute Approximation deiner Anfrage geben
sollte. Ein Stündchen mehr Arbeit und man kann auch noch eine Reihe
Spezialfälle abdecken. Warum also sollte man hunderte Mapper sinnlos
Zeit mit Relationen verschwenden lassen, wenn man die gleiche Info
mit ein bisschen Warten aus der DB bekommt?

Relationen sind eine feine Sache, aber nur, wenn man sie mit viel
Mass und Verstand einsetzt. Etwas mehr Mass wäre wünschenwert bei
OSM.

Gruss

Sarah