Hallo, Nop wrote: >> der Relation Analyzer wertet auch nur die Ways in einer Relation aus, >> und in meiner Superrelation sind ja (momentan) nur 2 Relationen enthalten: >> http://www.openstreetmap.org/browse/relation/49759 >> Diese wiederum bestehen dann nur aus Ways. > > Da haben wir schon mal den ersten Nachteil einer solchen Relation. Otto > normaluser wird jetzt annehmen, die gibts nicht.
Wenn wir immer nur Sachen einfuehren wuerden, die existierende Software bereits kann, waeren wir noch nicht besonders weit. Das ist maximal ein Nachteil am Relation Analyzer, kein Nachteil an der Relation. > Ein Aspekt ist die Gruppierung. Da hab ich ja gar nix dagegen. Aber > versetz' Dich mal in die Lage einer Software, die nur die Daten sehen > kann. Und stell' Dir mal vor, es gibt mehrere Superrelationen, in denen > Deine Etappen drin sind. Wie erkenn' ich jetzt, welche gemeint ist, wenn > ich z.B. die ganzen Etappenstrecken aufsummieren will? Ist das denn wirklich ein so haeufiger Fall? Ich kann mir ja vorstellen, dass es z.B. in Nordrhein-Westfalen irgendwo einen "Rhein-Ruhr-Wanderweg" gibt, den wir als Relation modellieren, und dass es ferner einen "Paris-Moskau-Wanderweg" gibt, der diesen Weg als eine Etappe enthalten koennte. Das Problem, das Du hier fuerchtest, wuerde entstehen, wenn es nun mehrere internationale Wanderwege gaebe, die alle den "Rhein-Ruhr-Wanderweg" als eine Etappe enthalten. Und mit "internationale Wanderwege" ist ja nicht gemeint, dass es mehrere Wandermoeglichkeiten gibt, sondern wirklich benannte, gewartete, ausgeschilderte Wege mit einer Organisation dahinter. Ist das wirklich ein Fall, der so haeufig auftritt, dass wir unser Modell danach ausrichten muessen? > Ein anderer Aspekt ist die Vererbung. Der ist tückisch, Nein, der wird nur staendig von Dir als tueckisch dargestellt, weil Du dich weigerst, pragmatisch an die Sache ranzugehen. Anstatt eine Loesung zu bauen, die in 99% der Faelle das richtige tut und in 1% der Faelle Schrott ausgibt, willst Du lieber gar keine Loesung. Mich wundert, wie Du es mit der Einstellung ueberhaupt zu einer so guten Wanderkarte gebracht hast ;-) > denn Du kannst > beliebig viele Tags von beliebig vielen Relationen auf beliebig > unterschiedlichen Wegen erben. Zunaechst einmal haben wir das bei Ways ja jetzt schon, ohne dass irgendjemand jammert: Ein Way kann sowohl zum Wanderweg "gelbes Kreuz" als auch zum Wanderweg "roter Kringel" gehoeren. Ob es da Vererbungen gibt und welcher Art die sind, entscheidet der Nutzer der Daten, das ist im System gar nicht festgelegt. Wenn man wollte, koennte man genau die gleichen Vererbungsprobleme, die Du hier konstruierst, auch fuer diesen Fall konstruieren. Ausserdem tritt die von Dir gefuerchtete Verwirrung ja fruehestens dann auf, wenn eine Wanderweg-Relation Teil von mehreren unterschiedlichen Superrelationen ist, ein Fall, den ich, wie gesagt, fuer sehr selten halte. Ich schlage vor, Du gehst bis auf weiteres einfach mal davon aus, dass eine Routen-Relation Teil von 0 oder 1 Superrelationen ist. Dann loesen sich alle Deine Probleme in Luft auf. Und wenn wir dann so Spezialfaelle bekommen, in denen das nicht mehr reicht, dann schauen wir, wie wir die loesen. > Und ich spiel halt so lange Advocatus Diaboli, bis auch der Fall n>1 > durchdacht ist. :-) Derlei Advokaten haben wir hier im Projekt oefters. Vorangebracht haben sie indes wenig. > Also: Woran soll mein Programm erkennen, welche Superrelation die von > Dir gemeinte ist, wenn es deren mehrere gibt? Nimm die erstbeste. Wenn Du partout damit nicht zufrieden bist, dann weise Deine Wanderrouten-Erfasser an, einen Rueckwaerts-Link von der Sub-Relation zu der gewuenschten Super-Relation einzubauen, und verarbeite das Konstrukt nur, wenn die Pointer beiderseitig konsistent sind. Zirkulaere Referenzen sind erlaubt. Ich vermute zwar, dass es einige Software gibt, die dabei maechtig auf die Nase fallen wird, aber dann hast Du wenigstens was zu lachen ;-) Bye Frederik -- Frederik Ramm ## eMail [email protected] ## N49°00'09" E008°23'33" _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
