[Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur

Florian Lohoff flo at rfc822.org
Mi Okt 22 16:16:11 UTC 2008


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                  flo at rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20081022/d66e6cb4/attachment.sig>


Mehr Informationen über die Mailingliste Talk-de