On Wed, Oct 22, 2008 at 06:03:19PM +0200, Dirk Stöcker wrote: > On Wed, 22 Oct 2008, Florian Lohoff wrote: > > >>Und wie gesagt, das Rendering verbessern. Wenn ich x Wege habe, die alle > >>den gleichen Namen/Ref tragen und sich jeweils einen gemeinsamen Endpunkt > >>teilen, dann kann ich diese zum Zwecke der Namensvergabe auch als einen > >>Weg betrachten. An Kachelgrenzen muss man dann ein wenig aufpassen, aber > >>sonst ist das eigentlich trivial, da ich in Zweifelsfällen ja immer auf > >>die Methode einfach alles auszugeben zurückfallen kann. > > > >Es geht mir ueberhaupt nicht ueber das rendering sondern darum das > >bestimmte attribute im moment nicht zu modellieren sind. So sind > >vorschlaege zu fahrradwegen, gefaellen/steigungen, einseitige > >geschwindigkeitsbeschraenkungen, einseitige zufahrtsbeschraenkungen alle > >bisher dran gescheitert das es eben keine moeglichkeit der modellierung > >gibt. > > Gehen wir mal auf die Basis zurück. Wir haben momentan drei Datentypen: > a) einfache Knoten > b) Wege, die aus diesen Aufgebaut sind > c) Relationen, welche aus Wegen oder Knoten aufgebaut sind. > > Was Du vorschlägst ist das Durchbrechen dieser einfachen Struktur - Du > willst "Relationen, welche Abschnitte von Wegen beschreiben".
- Abschnitte
- Richtung
- Ueberlappende Abschnitte
- Unterschiedliche richtungen auf den unterschiedlichen abschnitten
> Jeder der objektorientierte Programmierung verstanden hat wird Dir sagen,
> dass Zugriff auf Innereien eines Objekts nichts in anderen Objekten zu
> suchen haben, da dadurch eine sehr hohe Komplexizität entsteht. Und die
> Knoten sind interne Informationen eines Weges. Ich verstehe, dass es nicht
> sofort einsichtig ist, dass diese Herangehensweise zu Chaos führt, aber
> ich kann Dir nach mehr als 15 Jahren Programmierpraxis beteuern, dass es
> so ist. Ich habe zu oft gesehen, dass Software gescheitert ist, welche
> sich nicht an diese Regeln hielt.
Wir haben dieses defakto schon by turn relations. Ich gebe dir recht das
das nicht die schoenste loesung ist - aber sie ist etabliert.
> Wenn Dich die Doppelinformationen stören, dann baue das ganze andersherum
> auf. In Deinem Beispiel:
> Teile den Weg in 5 Abschnitte und packe die Informationen in Relationen.
> Name und Ref bleiben sehr wahrscheinlich lange konstant, also kommen
> diese in eine Relation. Maxspeed und ähnliches ändert sich schnell, wird
> also direkt an den Weg geklebt.
Ja - gebe ich dir recht - ist schoener - problem ist halt das dinge die
OFT benutzt werden d.h. name, ref, highway dann mit der relation
abgefruehstueckt werden - und dinge die "selten" benutzt werden direkt
auf dem weg. Also irgendwie ziemlich unschoen. Natuerlich koennte man
die modelle parallel existieren lassen - was aber das ganze nur noch
komplexer macht.
> Bei dieser Herangehensweise bleibt eine Stack-artige Strukt bestehen.
> Jede Objektgruppe baut auf Objekten niederer Gruppen auf ohne durch eine
> Objekt hindurch auf dessen interne Informationen zuzugreifen.
Damit ist das richtungsproblem aber nicht geloest. Natuerlich ist dieses
stacking schoen - aber es loest das imho groesste problem des
datenmodells - der richtungsabhaengigkeit - nicht.
Und richtungsabhaengigkeit ist halt zwischen punkten eines weges. Und
leider muessen wir auf dem selben weg mehrere attribute abfruehstuecken
die unterschiedliche richtungen haben - und ich denke du gibst mir recht
das oneway=-1 ein ziemlich ekelhaftes hilfskonstrukt ist. D.h. die eine
existente richtung des weges mehrfach zu missbrauchen um
unterschiedliches zu modellieren ist grosser bullshit.
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
