[Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags

Florian Lohoff flo at rfc822.org
Mi Okt 22 18:45:26 UTC 2008


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                  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/6a4f94da/attachment.sig>


Mehr Informationen über die Mailingliste Talk-de