On Wed, Oct 22, 2008 at 07:08:09PM +0200, Dirk Stöcker wrote: > Das das praktisch so ist stimmt. Aber wenn Du theoretisch herangehst, dann > habe ich Weg1 - Über-Knoten - Weg2. Das kaum Fälle vorstellbar sind, wo > die Knoten nicht zu Weg1 und Weg2 gehört ist richtig, aber theoretisch > eben vorstellbar. > > >Der unterschied meiner idee zur turn restriction ist dann wohl das ich 2 > >punkte eines weges brauche und die turn restriction nur einen oder? > > Nein. Du erwartest die Garantie, das beide Knoten im Weg enthalten sind > und auch Ihre Geometrie zueinander nicht geändert haben. Dies ist ein um > Größenordnungen stärker Eingriff.
Okay - das heisst wir haben ein validator problem hinterher - aber kein syntaktisches oder semantisches. Ich meine ich kann niemanden daran hindern in einer relation mist objekte als member einzubauen. Ob nodes in einem way die reihenfolge aendern koennen ist vermutlich richtig auch wenn mit einem editor ohne loeschen/neu anlegen des weges das nicht machbar scheint. > >Also doch wieder die daten auf den weg a und b ? > > > >a > > forward:maxspeed=50 > >b > > backward:maxspeed=50 > > > >Das ist doch das krankeste modell was ich jeh gesehen habe. > > Es ist mit Deiner Überlegung identisch nur durchbricht es das Datenprinzip > nicht. Jeder Weg hat automatisch eine Richtung, die durch die Reihenfolge > der Knoten geschaffen wird. Das Tagging setzt nur darauf auf. Dein > Vorschlag läuft darauf hinaus die Richtungsherrschaft vom Weg in eine > Relation zu überführen, die Teile eines Weges abbildet, aber ansonsten > hast Du das gleiche Prinzip. Warum ist jetzt Deine Variante nicht "krank", > obwohl ich Dir versuchte die grundlegenden Probleme der > Herangehensweise aufzuzeigen? Weil die "zufaellige" reihenfolge von nodes hier mehrfach ueberladen wird. Und wenn die richtung nicht passt dann muss ich das was ich drantagge im vorzeichen aendern. Das ist wesentlich unintuitiver als explizit einen abschnitt und richtung anzugeben fuer jedes attribut was ich an einen weg haenge. Ist es auf dem weg selber gilt es fuer den gesamten weg, habe ich eine waypart relation gilt es nur fuer eben diesen abschnitt und auch evtl nur in der angegebenen richtung. Wenn man das generisch anlegt dann duerfen in der relation dieselben attribute wie auf dem weg auftauchen und jeder renderer kann den weg dann nach gusto zerlegen, zusammenfuegen oder was auch immer. Bisher koennten osmarender und mapnik jedenfalls sowas wie maxspeed ignorieren. Dennoch penetrieren wir die renderer mit den ganzen wayschnipseln nur weil sich der maxspeed aendert. Im prinzip ist es doch so das auch ein weg nur eine besondere art der relation ist. D.h. ich setze nodes zu einer relation zusammen und haenge da attribute dran. Wenn ich die richtung ignoriere ist ein way nichts anderes als eine relation - Die besonderheit des weges ist im vergleich zur relation das es ein ordering der member gibt. Ich suche einfach eine Loesung der modellierung ohne die ways in 740 schnipsel zerlegen zu muessen. Wegen jeder dummen bruecke, geschwindigkeitsbeschraenkung, cyclelane aenderung dupliziere ich alle tags des weges. Das fuehrt hier in der gegend gerne dazu das nur auf einem bruchteil der way schnipsel sowas wie ref oder name gepflegt sind. Sowas wie die bridge schnipsel werden gerne vergessen. Ausserdem suche ich einen ausweg aus dem Karlsruhe Schema. Neben jeden weg noch 2 wege zu pflanzen nur weil ich dem weg ein paar interpolierte hausnummern geben will ist overkill. Dazu kommt ja noch das Dogma das nur physisch existentes gemappt werden soll. Dieser interpolation weg ist aber eben nichts existentes sondern nur etwas virtuelles. Also ist mein ansatz eben dem weg noch eine zusaetzliche richtung zu geben die unabhaengig von der richtung des ways ist, und auch unabhaengig von den nodes in der mitte. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin
signature.asc
Description: Digital signature
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de